Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Integration with other DIGIT services
A separate class should be created for integrating with each dependent microservice. Only one method from that class should be called from the main service class for integration.
This guide showcases the steps to integrate our microservices with other microservices like
For interacting with other microservices, we can create and implement the following ServiceRequestRepository
class under repository
package -
Describes how to integrate with DIGIT's ID Gen service
This page provides the steps to integrate with the IDGen Service. Each application needs to have a unique ID. The IDGen service generates these unique IDs. ID format can be customised via configuration in MDMS.
Add the ID format that needs to be generated in this file - Id Format Mdms File. The following config has been added for this module:
Restart the IDGen service and MDMS service and port-forward IDGen service to port 8285:
Note that you can set the ID format in the application.properties file of IDGen service and run the service locally if you don't have access to a DIGIT environment.
Hit the below curl to verify that the format is added properly. The "ID" name needs to match exactly with what was added in MDMS.
Once verified, we can call the ID generation service from within our application and generate the registrationId.
In the BirthApplicationEnrichment class, update the enrichBirthApplication method as shown below:
Make sure below ID generation host configuration is present in the application.properties file. Make sure to fill in the correct values for the host.
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've configured the DIGIT environment with a tenant and CITIZEN/EMPLOYEE roles, you have sufficient data to run this module locally. Configuring role-action mapping is only necessary during app deployment in the DIGIT environment and won't be needed for local application execution.
Refer to MDMS docs for more information. To learn about how to design the MDMS, refer to 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)
Ensure that you add data to the appropriate branch of the MDMS repository. For example, if you've set up CD/CI to deploy the DEV branch of the repository to the development environment (default), add the information to the DEV branch. If you're testing in staging or another environment, make sure to add the master data to the corresponding branch of MDMS.
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.
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 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 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.
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.
We will call into MDMS deployed in the sandbox environment. All MDMS config data needs to be uploaded into the MDMS repository (DEV branch if you are deploying/testing in your dev environment).
Integration with MDMS requires the following steps to be followed:
Add a new MDMS file in MDMS repo. For this guide, a sample MDMS file has already been added available here. Copy this file into your repository.
Restart MDMS service after adding the new file via Jenkins build UI.
Once restarted, hit the curl mentioned below to verify that the new file has been properly added .
Call the MDMS service post verification from within our application and fetch the required master data. For this, create a Java class by the name of MdmsUtil under utils folder. Annotate this class with @Component and put the following content in the class -
Add the following properties in application.properties file -
Overview
The User Service provides the capabilities of creating a user, searching for a user and retrieving the details of a user. This module will search for a user and if not found, create that user with the user service.
DIGIT's user service masks PII that gets stored in the database using the Encryption Service.
Create a class by the name of UserService under service folder and add the following content to it:
Add the below methods to the enrichment class we created. When we search for an application, the code below will search for the users associated with the application and add in their details to the response object.
Add in a userService object:
And enhance the following two methods in BirthRegistrationService.java:
Add the following properties in application.properties file:
Note: If you're port-forwarding using k8s, use "localhost". Otherwise, if you have a valid auth token, provide the hostname here.
The birth registration module follows a simple workflow derived from the swimlane diagrams. Please check the design inputs section for correlation as well as the design guide for info on how the workflow configuration is derived.
Integration with workflow service requires the following steps -
Create Workflow service - Create a class to transition the workflow object across its states. For this, create a class by the name of WorkflowService.java under the service directory and annotate it with @Service annotation.
Add the below content to this class -
Add workflow to BirthRegistrationService.
Add the below field to BirthRegistrationService.java
Transition the workflow - Modify the following methods in BirthRegistrationService.java as follows. Note that we are adding calls into the workflow service in each of these methods.
Configure application.properties - Add the following properties to application.properties file of the birth registration module. Depending on whether you are port forwarding or using the service directly on the host, please update the host name.
Run the workflow service locally - the application will call into it to create the necessary tables in the DB and effect the workflow transitions.
Workflow configuration should be created based on the business requirements. More details on extracting workflow in the design guide.
For our guide, we will configure the following workflow which was the output of the design phase:
We will re-use the workflow service which is deployed in the development/sandbox environment.
This guide assumes you can call the development environment workflow service directly with a valid auth token.
A sample curl is posted below. Make sure to replace the server hostname and the username and password in the below statement:
In POSTMan, create a new POST request and paste the below content in the body. The URL for the request is http://yourserver.digit.org/egov-workflow-v2/egov-wf/businessservice/_create
to create the workflow.
Make sure to replace the authToken field in the body with appropriate auth token in your environment. Login to the server as a CITIZEN or EMPLOYEE user (depending on which one you've created) and obtain the authToken from the response body.
In DIGIT, the API Gateway (Zuul) enriches user information based on the auth token for all requests that go via the gateway. Port forwarding by-passes the API gateway. In this case, when accessing a service directly, for a request to be valid, a user has to send the userInfo JSON inside the RequestInfo object. This is true not just for Workflow but for any service. Sample:
"userInfo": {
"id": 24226,
"uuid": "11b0e02b-0145-4de2-bc42-c97b96264807",
"userName": "sample_user",
"roles": [
{
"name": "Citizen", "code": "CITIZEN"}
]
}
Note that UUID and roles can be dummy place-holder entities in this case for local testing.
Below is the URL and POST body for the business service creation request.