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

• For the 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"
}]}

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

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

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

Reference Docs

Doc Links

API List

Learn how to configure the DIGIT Urban platform. Partner with us to enhance and integrate more into the platform.

​All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Learn how to setup DIGIT master data.

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

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.

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

Creating Masters data

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

Example Config JSON for “Billing Service”

Reference Docs

Doc Links

API List

Objective

Content of pages within this document is designed to help implementation parties and end-users in providing the required data in minimal interaction and iterations and ensure the quality, consistency and shape of data needed to configure into the system.

Audience

This page is intended to help stakeholders as given below on data gathering activities.

1. State Team

2. eGov Onsite Team/ Implementation Team

3. ULB Team (Nodal and DEO)

4. Implementation Partners

Output Artefacts

The artefacts of this document are the data template of a configurable entity, a page with content defining the entity template and helping on how to fill the template with required data.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Key configurations at the state level include -

• Tenants Information

• SMS Account Configuration

• Email Account Configuration

• Google Play Store Account

• Payment Gateway Configuration

• POS Configuration

• Domain Name Configuration

• SSL Configuration

• ULB Departments

• ULB Designations

• Localization

• Google Map Configuration

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

DIGIT environment setup is conducted at two levels.

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

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

Reference Docs

Doc Links

Introduction

The SMS service is a way of communicating necessary information/updates to the users on their various transactions on DIGIT applications.

In order to update the users, there are certain notification parameters that are system configured for various steps in the application process. These configurations can be changed/reconfigured based upon the ULB requirements.

Data Table

We have the below-mentioned parameters which we use for configuration:

Procedure

For the SMS service to be integrated there are various things for which the vendor more or less guides us for the steps to be followed but below mentioned are a few basic steps and the generic data definitions which could be followed.

Data Definition

Below mentioned are the descriptions of the parameters which are needed for configuration:

Steps to fill Data

Since the SMS service is a vendor delivered service for which the below steps would have to be followed:

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. The SMS vendor has to provide the data in the data template attached.

5. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments