1 of 6

Setting up Master Data

Learn how to setup DIGIT master data.

MDMS Overview
Configuring Master Data
Adding New Master
Configuring Tenants
State Level vs City Level Master

MDMS Overview

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 on how to operate JSON data would be an added advantage to understand 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 will be 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 deletion.

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 the master name first before defining the data

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

Title

Description

tenantId

Serves as a Key

moduleName

Name of the module to which the master data belongs

MasterName

The Master Name 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
    }
]
}

Reference Docs

Doc Links

Title

Link

Reference Doc Link 1

MDMS-Service

Reference Doc Link 2

MDMS-Rewritten

API List

Link

API Contract Reference

Configuring Master Data

Overview

Configuring Master Data for a new module requires creating a new module in the master config file and adding masters data. For better organizing, create all the master data files belongs 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 permissions 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

Adding 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.

Creating Masters data

Please check the link to create new master Adding New Master

Reference Docs

Doc Links

Title

Link

Sample Master config file

Sample Module folder

Adding New Master

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 permissions 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 for Statewide or ULB wise. Tenant id and config in the master config file determines this.

{
  "tenantId": "< TENANT ID >",
  "moduleName": "< MODULE NAME >",
  "< MASTER NAME >": []
}

Configuring the 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.

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

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

"master":{
    "masterName": "<>",
    "isStateLevel": true,
    "uniqueKeys": []
}

Reference Docs

Doc Links

Title

Link

Sample Master file

Sample Master configuration

Configuring Tenants

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 permissions to edit the git repository where MDMS data is configured.

Key Functionalities

For login page city name selection is required. Tenant added in MDMS shows in city drop-down of the login page.
In reports or in the employee inbox page the details related to ULB is displayed from the fetched ULB data which is added in MDMS.
Modules i.e., TL, PT, MCS can be enabled based on the requirement for 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 tenant folder holds the details of state and ULBs to be added in that state.

Naming Convention for Tenants Code

“Code”:“uk.citya” is StateTenantId.ULBTenantName"

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

Localization for ULB Grade

Localization for ULB Name

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

State Level Vs City Level Master

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 ULB’s of the state and data specific to each ULB’s. 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 on how to operate JSON data would be an added advantage to understand 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 ULB’s and modules like department, designation, etc are placed under the common-masters folder which is under the tenant folder of the MDMS repository.
The common master data across all ULB’s and are module-specific are placed in a folder named after each module. These folders are placed directly under the tenant folder.

ULB Level Master Configuration

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

Reference Docs

Doc Links

API List

MDMS Overview

Overview

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 on how to operate JSON data would be an added advantage to understand 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 will be 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 deletion.

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 the master name first before defining the data

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

Title

Description

tenantId

Serves as a Key

moduleName

Name of the module to which the master data belongs

MasterName

The Master Name 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
    }
]
}

Reference Docs

Doc Links

Title

Link

Reference Doc Link 1

MDMS-Service

Reference Doc Link 2

MDMS-Rewritten

API List

Link

API Contract Reference

Configuring Tenants

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 permissions to edit the git repository where MDMS data is configured.

Key Functionalities

For login page city name selection is required. Tenant added in MDMS shows in city drop-down of the login page.
In reports or in the employee inbox page the details related to ULB is displayed from the fetched ULB data which is added in MDMS.
Modules i.e., TL, PT, MCS can be enabled based on the requirement for 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 tenant folder holds the details of 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 Cornoration Address",
"contactNumber": "91 (135) 2653572"
}]}

To enable tenant the above data should be pushed in tenant.json file. Here "ULB Grade" and City "Code" are important fields. ULB Grade can have a set of allowed values that determines the ULB type, (, Municipality (municipal council, municipal board, municipal committee) (Nagar Parishad), etc). City "Code" has to be unique to each tenant. This city-specific code is used in all transactions. Not permissible to change the code. If changed we will lose the data of the previous transactions done.

Naming Convention for Tenants Code

“Code”:“uk.citya” is StateTenantId.ULBTenantName"

"logoId": "", Here the last section of the path should be "/<tenantId>/logo.png". If we use anything else, logo will not be displayed on the UI. <tenantId> is the tenant code ie “uk.citya”.

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

State Level Vs City Level Master

Overview

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 on how to operate JSON data would be an added advantage to understand 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 ULB’s and modules like department, designation, etc are placed under the common-masters folder which is under the tenant folder of the MDMS repository.
ex: ///common-masters/ Here “pb” is the tenant folder name.
The common master data across all ULB’s and are module-specific are placed in a folder named after each module. These folders are placed directly under the tenant folder.
ex: ///TradeLicense/ Here “pb” is the tenant folder name and “TradeLicense“ is the module name.

ULB Level Master Configuration

Modules data that are specific to each ULB like boundary data, interest, penalty, etc are configured each ULBwise. 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: ////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.