Add MDMS Configuration
Overview
MDMS data is the master data used by the application. New modules with master data need to be configured inside the /data/<tenant>/
folder of the MDMS repo. Each tenant should have a unique ID and sub-tenants can be configured in the format state.cityA, state.cityB etc..Further hierarchies are also possible with tenancy.
If you already have a DIGIT environment configured with a tenant and CITIZEN/EMPLOYEE roles, that is sufficient data to get this module running locally. Configuring role-action mapping is necessary during deployment of the app in the DIGIT environment. It will not be needed to run the application locally.
For more information on MDMS see here. To read about how to design for MDMS, please see the design guide.
In the birth registration use case, we use the following master data:
tenantId = "pb"
User roles - CITIZEN and EMPLOYEE roles configured in roles.json (see below section for more info)
Actions - URIs to be exposed via Zuul (see below section for more info)
Role-action mapping - for access control (see below section for more info)
Make sure to add data to the correct branch of the MDMS repository. i.e. if you have setup CD CI to deploy the DEV branch of the repository to the dev environment (default), then make sure to add the information in the DEV branch. If you are testing in staging or some other environment, make sure to add the master data to the corresponding branch of MDMS.
Steps
Create a folder called "pb" in the data folder of the MDMS repository "DEV" branch. You will have a new folder path as follows:
<MDMS repo URL path>/data/pb
Restart the MDMS service in the development environment where DIGIT is running once data is added to the MDMS repository. This loads the newly added/updated MDMS configs.
A sample MDMS config file can be viewed here - Sample MDMS data file.
API Access Control Configuration
URIs (actions), roles and URI-role mapping will be defined in MDMS. These will apply when the module is deployed into an environment where Zuul is involved (not while locally running the app). In this sample app, we have used "pb" as a tenantId. In your environment, you can choose to define a new one or work with an existing one.
All folders mentioned below need to be created under the data/pb
folder in MDMS.
You can choose to use some other tenantId. Make sure to change the tenant ID everywhere.
Actions
Actions need to be defined inside the /data/pb/ACCESS-CONTROL-ACTIONS/actions.json
file. Below are the actions for the birth registration module. Append this to the bottom of the actions.json file. Make sure the "id" field in the JSON is incremented. It needs to be unique in your environment.
Note that the IDs in the actions.json config are generated manually.
Roles Configuration
Roles config happens at a state level. For birth registration, we need only CITIZEN and EMPLOYEE roles in the /data/pb/ACCESSCONTROL-ROLES/roles.json
file.Here are some sample roles that can be defined in an environment. If these roles are already present in the file, then there is no need to add them in again.
Role-action Mapping
Append the below code to the "roleactions" key in the /data/pb/ACCESSCONTROL-ROLEACTIONS/
roleactions.json.
Note that other role-action mappings may already be defined in your DIGIT environment. So please make sure to append the below. The actionid
refers to the URI ID defined in the actions.json file.
Last updated