MDMS Configuration
Steps to Setup State/Urban Local Body (ULB):
Adding a Tenant:
In MDMS, the file tenant.json under the tenant folder holds the details of the state and ULBs to be enabled in that state.
Note:
To enable a state and a ULB, 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, (Municipal corporation (Nagar Nigam), 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. It is not permissible to change the code. If changed, we will lose the data of the previous transactions done.
Localisation should be pushed for ULB grade and ULB name. The formats are given below:
Localisation for ULB Grade
Localisation for ULB Name
Format of localisation code for tenant name:
<MDMS_State_Tenant_Folder_Name>_<Tenants_Fille_Name>_<Tenant_Code>(replace dot with underscore)
Naming Convention for Tenants Code
>
“Code”:“pb.citya” is StateTenantId.ULBTenantName"
citymodule.json file under the tenant folder used to activate modules in specific ulb. Example:
Module TL is enabled in ULB City A and City B. Modules mentioned in this file appear in the menu tree of the application. A ULB-level module enable or disable is handled here.
Adding a State
In MDMS, the file StateInfo.json, under the common-masters folder holds the state data.
Boundary Data Load:
Boundary is ULB-specific master data. For revenue modules, we use the revenue boundary. It is pushed under each ULB.
Boundary Hierarchy : Zone -> Ward -> Locality -> Area
Boundary data json is generated using the implementation kit.
Trade License Master Data Load:
Trade Type Master:
Trade Types of all ULBs are pushed under the “Trade License” folder of the MDMS repo.
The file path would be:
Example:
For each trade type, sub-types are defined. Each sub-type has mandatory documents to be attached. A unique code will be defined for each trade type, sub-type, and document.
TRADE is category
INDUSTRY is a Trade Type
FM is a Trade Subtype (Floor Mill)
For all the master data, we are pushing localisation messages. An explanation of inserting localisation for master data is given in the localisation section below:
Trade Rates:
Trade Rates for each trade subtype are stored in the database. Rest endpoints are available to create trade rates and search existing trade rates. You can use the below curl command to create and search trade rates.
-------------------------- Search Trade Rates ------------------------------------
H 'Content-Type: application/json' \
H 'Postman-Token: 80d84c50-b16e-44dd-9cc5-544def2ecd81' \
"RequestInfo": {
"authToken": "3bad8c62-b769-4a69-bf8b-0c6f008a5f01"
}
}'
-------------------------- Create Trade Rates ------------------------------------
H 'Content-Type: application/json' \
H 'Postman-Token: 59653a46-0a96-4eb0-a1cd-3e6c47f67aa0' \
"RequestInfo": {
"authToken": "796978d5-47d4-48b0-8995-f9e3fbfc32d8"
},
"billingSlab": [
{
"tenantId": "state.ulbname",
"licenseType": "PERMANENT",
"structureType": "IMMOVABLE.SHED",
"tradeType": "TRADE.HOTELS.HL30B",
"accessoryCategory": null,
"type": "FLAT",
"uom": null,
"fromUom": 0,
"toUom": 0,
"rate": 1000
}
]
}’ //<Replacewith proper application URL and the tenantid>
Note: Currently, the delete rate is not supported. To delete any specific rate, updating 'rate' to null using the update endpoint will inactivate the rate for a specific sub-type.
Adding role, and actions to MDMS
Actions-test.json:
Role-based actions will have mappings between actions and roles. It specifies which role can perform what actions. Example: A user with a TLCreator role mapped to the “Create Trade License” action/feature, can only perform the create TL application. A user can have multiple roles and multiple actions mapped.
Roleactions.json:
Localisation
All the master data, labels, notifications, validation/success messages are localised. To support multi-lingual, we use a common code for each field for which messages in different languages will be pushed using endpoints. Create, upsert, and search endpoints are used to create/update localisation messages.
Need to push localisation messages for newly-added master data.
Localisation code format for Masters: <ModuleName_MasterName_Code>
Example: Trade Type Master -
Trade Sub-Type:
Use the below rest endpoints to push these data:
Only boundary localization messages are pushed at the ULB level. Rest all are pushed at the state level.
-----------------------
Upsert: Update and Insert Localisation
-------------------------
--------
This API, updates if code already exists or else inserts newly
----------------
H 'Content-Type: application/json' \
H 'Postman-Token: 39264728-2857-4cb4-825c-53612fce51c0' \
"RequestInfo": {
"api_id": "org.egov.pgr",
"ver": "1.0",
"ts": "16-03-2017 12:09:14",
"action": null,
"did": "4354648646",
"key": "xyz",
"msg_id": "654654",
"requester_id": "61",
"authToken": "8850660e-7d35-4e8e-9d8b-9656c1a91d30"
},
"tenantId": "XYZ",
"messages":[
{
"code": "TL_OWNER_NAME",
"message": "OWNER",
"module": "rainmaker-tl",
"locale": "en_IN"
}
]
}'
-----------------------Search Localisation--------------------------
H 'Content-Type: application/json' \
H 'Postman-Token: 8fae6bd4-17ae-4fa5-afc4-a692f2c74064' \
"RequestInfo": {
"api_id": "org.egov.pgr",
"ver": "1.0",
"ts": "16-03-2017 12:09:14",
"action": null,
"did": "4354648646",
"key": "xyz",
"msg_id": "654654",
"requester_id": "61",
"authToken": "7315d713-773c-4282-97a1-b69b95895711"
},
"tenantId": "XYZ"
}'
Employee Creation
HRMS Admin and SUPERUSER
"CreateNoValidate" api is used to create admin and superuser for the first time when no users exists. This endpoint is for User Creation only.
For Employee creation, Separate endpoint or UI used. HRMS admin is responsible for employee creation.
----------------------
Create No Validate Api to create first time employees
---------------------
curl -X POST \
H ‘Content-Type: application/json’ \
H ‘Postman-Token: 3c8eb85e-877e-4b0a-a1db-60676fa5eb45’ \
H ‘cache-control: no-cache’
Online Payment Gateway Integration :
Refer to the following link for documentation:
SMS Gateway Integration :
Set the below configurations in the application.properties file of egov-notification-sms service
Below configuration holds service provider details.
---------------------------
application.properties
---------------------------------------
sms.enabled=true
sms.provider.url=http://placeholder
sms.sender.username=placeholder
sms.sender.password=placeholder
sms.sender=placeholder
#Parameter names are kept compatible with sms service provider(SMSCountry gateway).
sms.sender.req.param.name=sid
sms.sender.username.req.param.name=user
sms.sender.password.req.param.name=passwd
sms.destination.mobile.req.param.name=mobilenumber
sms.message.req.param.name=message
sms.extra.req.params=smsservicetype=singlemsg
sms.error.codes=401,403,404,405,406,407,408,409,410,411,412,413,414
#SMS priority settings if available
sms.priority.enabled=false
sms.priority.param.name=
sms.high.priority.param.value=
sms.medium.priority.param.value=
sms.low.priority.param.value=
sms.verify.response = false
sms.verify.responseContains=Message submitted successfully
sms.verify.ssl = false
sms.url.dont_encode_url = true
# POST or GET requests
sms.sender.requestType=POST
Add the below environment variables to your egov-user deployment. This will enable your login without OTP.
CITIZEN_LOGIN_PASSWORD_OTP_FIXED_VALUE: 123456
CITIZEN_LOGIN_PASSWORD_OTP_FIXED_ENABLED: true
Implementation Kit Usage Steps
Pre-requisites:
Clone the implementation kit repo using the following link:
Last updated
Was this helpful?
