Follow the steps below to adopt the new MDMS -

1. Define the schema for the master that you want to promote to MDMS v2.

2. Ensure that the schema has a unique field (a unique field can also be composite) to enforce data integrity.

3. In case the data does not have unique identifiers e.g. complex masters like the one mentioned here, consider adding a redundant field which can serve as the unique identifier.

4. Use the following API endpoint to create a schema - /mdms-v2/schema/v1/_create

5. Search and verify the created schema using the following API endpoint - /mdms-v2/schema/v1/_search

6. Once the schema is in place, add the data using the following API endpoint - /mdms-v2/v2/_create/{schemaCode}

7. Verify the data by using the following API endpoint - /mdms-v2/v2/_search

Overview

For creating a new master in MDMS, create the JSON file with the master data and configure the newly created master in the master config file.

Pre-requisites

Before proceeding with the configuration, make sure the following pre-requisites are met -

• User with permission to edit the git repository where MDMS data is configured.

Deployment Details

After adding the new master, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Creating Master JSON

The new JSON file needs to contain 3 keys as shown in the below code snippet. The new master can be created either State-wise or ULB-wise. Tenant ID and config in the master config file determine this.

Configuring Master Config File

The master config file is structured as below. Each key in the master config is a module and each key in the module is a master.

Each master contains the following data and the keys are self-explanatory

Reference Docs

Doc Links

Overview

MDMS stands for Master Data Management Service. MDMS is one of the applications in the eGov DIGIT core group of services. This service aims to reduce the time spent by developers on writing codes to store and fetch master data (primary data needed for module functionality ) which doesn’t have any business logic associated with them.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• Prior knowledge of Java/J2EE.

• Prior knowledge of Spring Boot.

• Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.

• Prior knowledge of Git.

• Advanced knowledge of how to operate JSON data would be an added advantage to understanding the service.

Key Functionalities

• The MDMS service reads the data from a set of JSON files from a pre-specified location.

• It can either be an online location (readable JSON files from online) or offline (JSON files stored in local memory).

• The JSON files are in a prescribed format and store the data on a map. The tenantID of the file serves as a key and a map of master data details as values.

• Once the data is stored in the map the same can be retrieved by making an API request to the MDMS service. Filters can be applied in the request to retrieve data based on the existing fields of JSON.

Deployment Details

• For deploying the changes in MDMS data, the service needs to be restarted.

• The changes in MDMS data could be adding new data, updating existing data, or deleting it.

Configuration Details

The config JSON files to be written should follow the listed rules

• The config files should have JSON extension

• The file should mention the tenantId, module name, and master name first before defining the data

{
  "tenantId": "uk",
  "moduleName": "BillingService",
  "{$MasterName}":[ ]
}

Example config JSON for “Billing Service”

{
  "tenantId": "pb",
  "moduleName": "BillingService",
 "BusinessService": 
 [
    {
      "businessService": "PropertyTax",
      "code": "PT",
      "collectionModesNotAllowed": [ "DD" ],
      "partPaymentAllowed": true,
      "isAdvanceAllowed": true,
      "isVoucherCreationEnabled": true
    }
]
}

Reference Docs

Doc Links

API List

Overview

The MDMS service aims to reduce the time spent by developers on writing codes to store and fetch master data (primary data needed for module functionality) which doesn’t have any business logic associated with them. Instead of writing APIs and creating tables in different services to store and retrieve data that is seldom changed, the MDMS service keeps them in a single location for all modules and provides data on demand with the help of no more than three lines of configuration.

Pre-requisites

1. Prior knowledge of Java/J2EE

2. Prior knowledge of Spring Boot

3. Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.

4. Prior knowledge of Git

5. Advanced knowledge of how to operate JSON data would be an added advantage to understanding the service

Key Functionalities

• Adds master data for usage without the need to create master data APIs in every module.

• Reads data from GIT directly with no dependency on any database services.

Deployment Details

Integration Details

Integration Scope

The MDMS service provides ease of access to master data for any service.

Integration Benefits

• No time spent writing repetitive codes with no business logic.

Integration Steps

1. To integrate, the host of egov-mdms-service should be overwritten in the helm chart

2. egov-mdms-service/v1/_search should be added as the search endpoint for searching master data.

3. MDMS client from eGov snapshots should be added as mvn entity in pom.xml for ease of access since it provides MDMS request pojos.

Reference Docs

Doc Links

API List

Learn how to setup DIGIT master data.

Overview

MDMS v2 provides APIs for defining schemas, searching schemas, and adding master data against these defined schemas. All data is now stored in PostgreSQL tables instead of GitHub. MDMS v2 currently also includes v1 search API for fetching data from the database in the same format as MDMS v1 search API to ensure backward compatibility.

Pre-requisites

1. Prior knowledge of Java/J2EE.

2. Prior knowledge of Spring Boot.

3. Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.

4. Prior knowledge of Git.

5. Advanced knowledge of operating JSON data would be an added advantage to understanding the service.

Functionalities

1. Create schema: MDMS v2 introduces functionality to define your schema with all validations and properties supported by JSON schema draft 07. Below is a sample schema definition for your reference -

To create a basic schema definition, use the following keywords:

• $schema: specifies which draft of the JSON Schema standard the schema adheres to.

• title and description: state the intent of the schema. These keywords don’t add any constraints to the data being validated.

• type: defines the first constraint on the JSON data.

Additionally, we have two keys which are not part of standard JSON schema attributes -

• x-unique: specifies the fields in the schema utilizing which a unique identifier for each master data will be created.

• x-ref-schema: specifies referenced data. This is useful in scenarios where the parent-child relationship needs to be established in master data. For example, Trade Type can be a parent master data to Trade Sub Type. In the example above, the field path represents the JsonPath of the attribute in the master data which contains the unique identifier of the parent which is being referenced. Schema code represents the schema under which the referenced master data needs to be validated for existence.

1. Search schema: MDMS v2 has API to search schema based on the tenantid, schema code, and unique identifier.

2. Create data: MDMS v2 enables data creation according to the defined schema. Below is an example of data based on the mentioned schema:

1. Search data: MDMS v2 exposes two search APIs - v1 and v2 search where v1 search API is completely backward compatible.

2. Update data: MDMS v2 allows the updation of master data fields.

3. Fallback functionality: Both the search APIs have fallback implemented where if data is not found for a particular tenant, the services fall back to the parent tenant(s) and return the response. If data is not found even for the parent tenant, an empty response is sent to the user.

API Details

1. /mdms-v2/schema/v1/_create - Takes RequestInfo and SchemaDefinition in the request body. SchemaDefinition has all attributes which define the schema.

2. /mdms-v2/schema/v1/_search - Takes RequestInfo and SchemaDefSearchCriteria in the request body and returns schemas based on the provided search criteria.

3. /mdms-v2/v2/_create/{schemaCode} - Takes RequestInfo and Mdms in the request body where the MDMS object has all the information for the master being created and it takes schemaCode as path param to identify the schema against which data is being created.

4. /mdms-v2/v2/_search - Takes RequestInfo and MdmsCriteria in the request body to return master data based on the provided search criteria. It also has a fallback functionality where if data is not found for the tenant which is sent, the services fall back to the parent tenant(s) to look for the data and return it.

5. /mdms-v2/v2/_update/{schemaCode} - Takes RequestInfo and Mdms in the request body where the MDMS object has all the information for the master being updated and it takes schemaCode as path param to identify the schema against which data is being updated.

6. /mdms-v2/v1/_search - This is a backwards-compatible API which takes RequestInfo and MdmsCriteria in the request body to return master data based on the provided search criteria and returns the response in MDMS v1 format. It also has fallback functionality where if data is not found for the tenant which is sent, the services fall back to the parent tenant(s) to look for the data and return it.

Postman Collection

Overview

Follow the steps below to migrate the MDMS data to enable the use of Workbench UI v1.0.

Steps

1. Generate Schema

Follow the steps below to generate the schema for Workbench UI v1.0:

1. Clone the migration utility: Start by cloning the migration utility from this link.

2. Clone the MDMS Repository: Start by cloning the MDMS repository on your local machine.

3. Configure application.properties: Open the application.properties file in the workbench utility and configure it as follows:

   • Add the hostname of the environment.

   • Add the MDMS cloned folder path in the egov.mdms.conf.path.

   • Add master-config.json in masters.config.url.

   • Specify the output folder path for the created schema in master.schema.files.dir.

4. Port-forward MDMSv2 Service: Port-forward the MDMSv2 service to port 8094.

5. Run the Curl Command:

   Copy

   shCopy codecurl -L -X POST 'localhost:8080/mdms-migration-toolkit/schema/v1/_generate'

   This command generates the schema and saves it in the path specified by master.schema.files.dir.

2. Update Schema

After generating the schema, you may need to update it with additional attributes:

• Add x-unique Attribute: This defines unique fields in the schema.

  Copy

  "x-unique": ["description"]

• Add x-ref-schema Attribute: Use this attribute if a field within MDMS data needs to refer to another schema.

  Copy

  "x-ref-schema": [{"fieldPath": "billingType","schemaCode": "WaterCharges.BillingType"}]

• Set Default Value for a Field: Use the default keyword to set default values.

3. Migrate Schema

To migrate the schema, use the following curl command:

curl -L 'localhost:8080/mdms-migration-toolkit/schema/v1/_migrate' \
-H 'Content-Type: application/json' \
-d '{
  "schemaMigrationCriteria": {
    "moduleName": "PropertyTax",
    "tenantId": "pb"
  },
  "requestInfo": {
    "apiId": "asset-services",
    "ver": null,
    "ts": null,
    "action": null,
    "did": null,
    "key": null,
    "msgId": "search with from and to values",
    "authToken": "7a9fc02a-bd6e-4e42-bd43-519b9e357bae",
    "correlationId": null,
    "userInfo": {
      "id": 878483,
      "uuid": "3059806b-3059-4724-8ae1-d3f4e12686ff",
      "userName": "8080800000",
      "name": "HRMS-ADMIN-TESTING",
      "mobileNumber": "8080800000",
      "emailId": null,
      "locale": null,
      "type": "EMPLOYEE",
      "roles": [
        {
          "name": "MDMS ADMIN",
          "code": "MDMS_ADMIN",
          "tenantId": "pb"
        },
        {
          "name": "Localisation admin",
          "code": "LOC_ADMIN",
          "tenantId": "pb"
        },
        {
          "name": "Employee",
          "code": "EMPLOYEE",
          "tenantId": "pb"
        }
      ],
      "active": true,
      "tenantId": "pb",
      "permanentCity": null
    }
  }
}'

4. Migrate Data

To migrate data for a specific master/module name, use the following curl command:

curl -L 'localhost:8080/mdms-migration-toolkit/data/v1/_migrate' \
-H 'accept: */*' \
-H 'Content-Type: application/json' \
-d '{
  "masterDataMigrationCriteria": {
    "moduleName": "PropertyTax",
    "tenantId": "pb"
  },
  "requestInfo": {
    "apiId": "asset-services",
    "ver": null,
    "ts": null,
    "action": null,
    "did": null,
    "key": null,
    "msgId": "search with from and to values",
    "authToken": "7a9fc02a-bd6e-4e42-bd43-519b9e357bae",
    "correlationId": null,
    "userInfo": {
      "id": 878483,
      "uuid": "3059806b-3059-4724-8ae1-d3f4e12686ff",
      "userName": "8080800000",
      "name": "HRMS-ADMIN-TESTING",
      "mobileNumber": "8080800000",
      "emailId": null,
      "locale": null,
      "type": "EMPLOYEE",
      "roles": [
        {
          "name": "MDMS ADMIN",
          "code": "MDMS_ADMIN",
          "tenantId": "pb"
        },
        {
          "name": "Localisation admin",
          "code": "LOC_ADMIN",
          "tenantId": "pb"
        },
        {
          "name": "Employee",
          "code": "EMPLOYEE",
          "tenantId": "pb"
        }
      ],
      "active": true,
      "tenantId": "pb",
      "permanentCity": null
    }
  }
}'

5. Schema Sample

Here is an example of a schema:

{
  "id": "060776ef-2eff-4f76-82ba-9b40cfad1c6c",
  "tenantId": "pb",
  "code": "ws-services-calculation.WCBillingSlab",
  "description": "ws-services-calculation WCBillingSlab",
  "definition": {
    "type": "object",
    "allOf": [
      {
        "if": {
          "required": ["connectionType"],
          "properties": {
            "connectionType": {"const": "Metered"}
          }
        },
        "then": {
          "required": ["slabs"],
          "properties": {
            "calculationAttribute": {"enum": ["Water consumption"]}
          }
        }
      },
      {
        "if": {
          "required": ["connectionType"],
          "properties": {
            "connectionType": {"const": "Non_Metered"}
          }
        },
        "then": {
          "properties": {
            "calculationAttribute": {
              "enum": ["Flat", "No. of taps", "Pipe Size"]
            }
          }
        }
      }
    ],
    "title": "Generated schema for Root",
    "$schema": "http://json-schema.org/draft-07/schema#",
    "required": ["buildingType", "calculationAttribute", "connectionType", "minimumCharge"],
    "x-unique": ["buildingType", "connectionType"],
    "properties": {
      "slabs": {
        "type": "array",
        "items": {
          "type": "object",
          "required": ["from", "to", "charge"],
          "properties": {
            "to": {"type": "number"},
            "from": {"type": "number"},
            "charge": {"type": "number"},
            "meterCharge": {"type": "number"}
          }
        }
      },
      "buildingType": {
        "enum": [
          "RESIDENTIAL", "NONRESIDENTIAL", "COMMERCIAL AND GOVERNMENT", 
          "PARTLY COMMERCIAL", "COMMERCIAL", "GOVERNMENT", "MIXED", "PUBLICSECTOR"
        ],
        "type": "string"
      },
      "minimumCharge": {"type": "number"},
      "connectionType": {
        "enum": ["Metered", "Non_Metered"],
        "type": "string"
      },
      "calculationAttribute": {
        "enum": ["Flat", "Water consumption", "No. of taps", "Pipe Size"],
        "type": "string"
      }
    }
  },
  "isActive": true,
  "auditDetails": {
    "createdBy": "3059806b-3059-4724-8ae1-d3f4e12686ff",
    "lastModifiedBy": "3059806b-3059-4724-8ae1-d3f4e12686ff",
    "createdTime": 1701151086754,
    "lastModifiedTime": 1701151086754
  }
}

/**
 * This method accepts master data migration requests and triggers
 * creation of MDMS objects
 * @param masterDataMigrationRequest
 */
public void migrateMasterData(@Valid MasterDataMigrationRequest masterDataMigrationRequest) {

    // Get Master Data map
    Map<String, Map<String, JSONArray>> tenantMap = MDMSApplicationRunnerImpl.getTenantMap();

    // Get tenantId from request
    String tenantId = masterDataMigrationRequest.getMasterDataMigrationCriteria().getTenantId();

    // Build audit details for mdms objects creation
    AuditDetails auditDetails = new AuditDetails();
    RequestInfo requestInfo = masterDataMigrationRequest.getRequestInfo();
    AuditDetailsEnrichmentUtil.enrichAuditDetails(auditDetails, requestInfo, Boolean.TRUE);

    List<JSONArray> masterDataList = new ArrayList<>();

    // Check if master data is present for the incoming tenantId.
    if (tenantMap.containsKey(tenantId)) {
        tenantMap.get(tenantId).keySet().forEach(module -> {
            if (module.equals("common-masters")) {
                tenantMap.get(tenantId).get(module).keySet().forEach(master -> {
                    if (master.equals("CancelCurrentBillReasons") || master.equals("CancelReceiptReason") ||
                        master.equals("CronJobAPIConfig") || master.equals("Department") || master.equals("Designation") ||
                        master.equals("IdProof") || master.equals("UsageCategory") || master.equals("OwnerType") ||
                        master.equals("VehicleType") || master.equals("UOM") || master.equals("StructureType") ||
                        master.equals("TablePaginationOptions")) {
                        // Get master data array for current module and master
                        JSONArray masterDataJSONArray = MDMSApplicationRunnerImpl
                                .getJSONArray(tenantMap.get(tenantId)
                                .get(module)
                                .get(master));
                        masterDataList.add(masterDataJSONArray);
                    }
                });
            }
        });
    }
}

Overview

Tenant represents a body in a system. In the municipal system, a state and its ULBs (Urban local bodies) are tenants. ULB represents a city or a town in a state. Tenant configuration is done in MDMS.

Pre-requisites

Before proceeding with the configuration, the following pre-requisites are met -

• Knowledge of json and how to write a json is required.

• Knowledge of MDMS is required.

• User with permission to edit the git repository where MDMS data is configured.

Key Functionalities

• On the login page, city name selection is required. Tenant added in MDMS shows in the city drop-down of the login page.

• In reports or in the employee inbox page the details related to ULB are displayed from the fetched ULB data added in MDMS.

• Modules i.e., TL, PT, MCS can be enabled based on the requirement of the tenant.

Deployment Details

After adding the new tenant, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Tenant is added in tenant.json. In MDMS, file tenant.json, under the tenant folder holds the details of the state and ULBs to be added in that state.

{
  "tenantId": "uk",  //<ReplaceWithDesiredTenantId>
  "moduleName": "tenant",
  "tenants": [ {
      "code": "uk.citya", //<state.ulbname>
      "name": "City A",  //<name of the ulb>
      "description": "City A", //<ulb description>
      "logoId": "https://s3.ap-south-1.amazonaws.com/uk-egov-assets/uk.citya/logo.png",  //<ulb logo path - To display ulb logo on login>
      "imageId": null,
      "domainUrl": "", //<ulb website url>
      "type": "CITY",
      "twitterUrl": null,
      "facebookUrl": null,
      "emailId": "complaints.citya@gmail.com",  //<ulb email id>
      "OfficeTimings": {
        "Mon - Sat": "10.00 AM - 5.00 PM"
      },
"city": {
"name": "City A",
"localName": null,
"districtCode": "CITYA",
"districtName": null,
"regionName": null,
"ulbGrade": "Municipal Corporation",
"longitude": 78.0322,
"latitude": 30.3165,
"shapeFileLocation": null,
"captcha": null,
"code": "248430"
},
"address": "City A Municipal Coronation Address",
"contactNumber": "91 (135) 2653572"
}]}

Localization should be pushed for ULB grade and ULB name. The format is given below.

Localization for ULB Grade

{
     "code": "ULBGRADE_MUNICIPAL_CORPORATION",
     "message": "MUNICIPAL CORPORATION",
     "module": "rainmaker-common",
     "locale": "en_IN"
  }

Localization for ULB Name

{
     "code": "TENANT_TENANTS_UK_HALDWANI",    
     "message": "Haldwani",
     "module": "rainmaker-tl",
     "locale": "en_IN"
}

Format of localization code for tenant name <MDMS_State_Tenant_Folder_Name>_<Tenants_Fille_Name>_<Tenant_Code> (replace dot with underscore)

Boundary data should be added for the new tenant.

Reference Docs

Doc Links

Overview

Master Data Management Service is a core service made available on the DIGIT platform. It encapsulates the functionality surrounding Master Data Management. The service creates, updates and fetches Master Data pertaining to different modules. This eliminates the overhead of embedding the storage and retrieval logic of Master Data into other modules. The functionality is exposed via REST API.

Pre-requisites

Prior Knowledge of Java/J2EE, Spring Boot, and advanced knowledge of operating JSON data would be an added advantage to understanding the service.

Functionality

The MDM service reads the data from a set of JSON files from a pre-specified location. It can either be an online location (readable JSON files from online) or offline (JSON files stored in local memory). The JSON files should conform to a prescribed format. The data is stored in a map and tenantID of the file serves as the key.

Once the data is stored in the map the same can be retrieved by making an API request to the MDM service. Filters can be applied in the request to retrieve data based on the existing fields of JSON.

Setup and Usage

The spring boot application needs lombok extension added to your IDE to load it. Once the application is up and running API requests can be posted to the URL.

Configuration & Structure

The config JSON files to be written should follow the listed rules

• The config files should have JSON extension.

• The file should mention the tenantId, module name, and master name first before defining the data.

{
  "tenantId": "pb",
  "moduleName": "BillingService",
  "{$MasterName}":[ ]
}

The Master Name in the above sample will be substituted by the actual name of the master data. The array succeeding it will contain the actual data.

Example config JSON for “Billing Service”

{
  "tenantId": "pb",
  "moduleName": "BillingService",
 "BusinessService": 
 [
    {
      "businessService": "PropertyTax",
      "code": "PT",
      "collectionModesNotAllowed": [ "DD" ],
      "partPaymentAllowed": true,
      "isAdvanceAllowed": true,
      "isVoucherCreationEnabled": true
    }
]
}

API Reference Documentation

APIs are available to create, update and fetch master data pertaining to different modules. Refer to the segment below for quick details.

BasePath:/mdms/v1/[API endpoint] Method

POST /_create

Creates or Updates Master Data on GitHub as JSON files

MDMSCreateRequest Request Info + MasterDetail — Details of the master data to be created or updated on GitHub.

MasterDetail

MdmsCreateResponse Response Info

Method

POST /_search

This method fetches a list of masters for a specified module and tenantId.

MDMSCriteriaReq (mdms request) - Request Info + MdmsCriteria — Details of module and master which need to be searched using MDMS.

MdmsCriteria

MdmsResponse Response Info + Mdms

MDMS

Common Request/Response/Error Structures:

RequestInfo should be used to carry meta information about the requests to the server as described in the fields below. All DIGIT APIs will use requestinfo as a part of the request body to carry this meta information. Some of this information will be returned back from the server as part of the ResponseInfo in the response body to ensure correlation.

ResponseInfo should be used to carry metadata information about the response from the server. apiId, ver, and msgId in ResponseInfo should always correspond to the same values in the respective request's RequestInfo.

ErrorRes

All DIGIT APIs will return ErrorRes in case of failure which will carry ResponseInfo as metadata and Error object as an actual representation of the error. When the request processing status in the ResponseInfo is ‘FAILED’ the HTTP status code 400 is returned.

Overview

MDMS supports the configuration of data at different levels. While we enable a state there can be data that is common to all the ULBs of the state and data specific to each ULB. The data further can be configured at each module level as state-specific or ULB’s specific.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• Prior Knowledge of Java/J2EE.

• Prior Knowledge of Spring Boot.

• Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.

• Prior knowledge of Git.

• Advanced knowledge of operating JSON data would be an added advantage to understanding the service.

Key Functionalities

• State Level Masters are maintained in a common folder.

• ULB Level Masters are maintained in separate folders named after the ULB.

• Module Specific State Level Masters are maintained by a folder named after the specific module that is placed outside the common folder.

Deployment Details

• For deploying the changes(adding new data, updating existing data or deletion) in MDMS, the MDMS service needs to be restarted.

Configuration Details

State Level Master Configuration

• The common master data across all ULBs and modules like department, designation, etc are placed under the common-masters folder which is under the tenant folder of the MDMS repository.

ex: egov-mdms-data/data/pb/common-masters/ Here “pb” is the tenant folder name.

• The common master data across all ULBs and are module-specific are placed in a folder named after each module. These folders are placed directly under the tenant folder.

ex: egov-mdms-data/data/pb/TradeLicense/ Here “pb” is the tenant folder name and “TradeLicense“ is the module name.

ULB Level Master Configuration

• Module data that are specific to each ULB like boundary data, interest, penalty, etc are configured at the ULB level. There will be a folder per ULB under the tenant folder and all the ULB’s module-specific data are placed under this folder.

ex: egov-mdms-data/data/pb/amritsar/TradeLicense/ Here “amritsar“ is the ULB name and “TradeLicense“ is the module name. All the data specific to this module for the ULB are configured inside this folder.

Reference Docs

Doc Links

API List

Overview

Configuring master data for a new module requires creating a new module in the master config file and adding master data. For better organizing, create all the master data files belonging to the module in the same folder. Organizing in the same folder is not mandatory it is based on the moduleName in the master data file.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• User with permission to edit the git repository where MDMS data is configured.

Key Functionalities

These data can be used to validate the incoming data.

Deployment Details

After adding the new module data, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Add New Module

The master config file is structured as below. Each key in the master config is a module and each key in the module is a master.

{
  "<module1>":{
    "<master1>":{},
    "<master2>":{},
    ...
  },
  "<module2>":{
    <master3>:{},
    <master4>:{},
    ...
  },
  ...
}

The new module can be added below the existing modules in the master config file.

Create Masters Data

Please check the link to create a new master Adding New Master

Reference Docs

Doc Links