Integration with signed audit
Enabling signed audit for a module ensures that all transactions - creates, updates, deletes - are recorded in a digitally signed fashion. Learn more about the signed audit service here.
Enabled signed audit is optional but highly recommended to ensure data security.
Add the following lines of code to the birth registration persister after the fromTopic attribute under mappings:
Follow the steps detailed below to implement Kafka Producer & Consumer.
Producer classes help in pushing data from the application to Kafka topics. DIGIT has a custom implementation of KafkaTemplate class in the tracer library called CustomKafkaTemplate. This implementation of the Producer class does not change across services of DIGIT.
Access the producer implementation details here - Producer Implementation.
The Codegen jar already has created a Producer class. We will continue using it.
Make sure the tracer dependency version in the pom.xml is 2.9.0-SNAPSHOT.
For our guide, we will be implementing a notification consumer in the following section.
Once an application is created/requested or progresses further in the workflow, notifications can be triggered as each of these events is pushed onto Kafka topics which can be listened to and an sms/email/in-app notification can be sent to the concerned user(s).
For our guide, we will be implementing a notification consumer which will listen to the topic on which birth registration applications are created. Create a customised message and send it to the notification service (sms/email) to trigger notifications to the concerned users.
Sending SMS notifications to the customer:
Once an application is created/updated the data is pushed on Kafka topic. We trigger notifications by consuming data from this topic. Whenever any message is consumed the service will call the localisation service to fetch the SMS template. It will then replace the placeholders in the SMS template with the values in the message it consumed.
(For example, It will replace the {NAME} placeholder with the owner name from the data consumed). Once the SMS text is ready, the service pushes this data on the notification topic. SMS service consumes data from notification topic and triggers SMS.
Open Kafka/NotificationConsumer.java and paste the following code:
Create a POJO by the name of SMSRequest in the web.models package and add the below content to it:
Create a class by the name of NotificationService under service folder to handle preparation of customised messages and pushing the notifications.
Add the below content to it -
This page provides the steps on how to add persister configuration.
The persister configuration is written in a YAML format. The INSERT and UPDATE queries for each table are added in prepared statement format, followed by the jsonPaths of values that have to be inserted/updated.
For example, for a table named studentinfo with id, name, age, and marks fields, the following configuration will get the persister ready to insert data into studentinfo table -
Fork the configs repo. Ignore if done already. Clone configs repo in the local environment.
Persister configurations for all modules are present under the egov-persister folder. Create a file by the name of btr-persister.yml (or any other name) under the egov-persister folder.
Add the below content to it -
Import all the core-services projects as Maven projects into your IDE. It is assumed that you have already cloned the DIGIT code locally.
Modify the application.properties file in the egov-persister project and set the following property:
Note: You can set a comma-separated list of files as the value of the above property. If you are running multiple services locally, then this has to be a comma-separated list of persister config files. Make sure you always give the absolute path.
Make sure the Spring DB configurations and Flyway config reflect the same database as what has been set in the module itself. Otherwise, we will see failures in the persister code.
Make sure the Kafka is running locally. Now, go ahead and run the EgovPersistApplication from the IDE. Check the console to make sure it is listening to the right topics as configured in your module's application.properties file.
The persister is now ready for use.
Note: Below steps are for when you deploy your code to the DIGIT env, not for local development. You may choose to do this when you build and deploy.
Push the code to the appropriate branch from which your environment will read it.
Navigate to your fork of the DIGIT-DevOps repository. Under the deploy-as-code/helm/environments directory, find the deployment helm chart that was used to deploy DIGIT.
In the deployment helm chart (which was used to set up the DIGIT environment), find "egov-persister". Find the "persist-yml-path" property and add the path to your new persister file here.
In the snippet below, file:///work-dir/configs/egov-persister/birth-module-developer-guide.yml
Raise a PR to the appropriate branch of the DevOps repo (master, in egov case) which was forked/used to create the deployment. Once that is merged, restart the indexer service in your environment so it will pick up this new config for the module.
This section contains information on steps for integrating with the Persister Service and Kafka.
Steps to integrate Persister Service and Kafka:
Add Kafka Configuration
Implement Kafka Producer & Consumer
Add Persister Configuration