Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section contains information on steps for integrating with the Persister Service and Kafka.
Steps to integrate Persister Service and Kafka:
Follow the steps detailed below to implement & .
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 -
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 -
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.
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 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
:
Fork the . Ignore if done already. Clone configs repo in the local environment.
Add Kafka Configuration
Implement Kafka Producer & Consumer
Add Persister Configuration
DIGIT backend development guide
This guide provides detailed steps for developers to create a new microservice on top of DIGIT. At the end of this guide, you will be able to run the sample module provided (code provided), test it out locally and also deploy it using CI/CD to your DIGIT environment.
Steps to create a microservice:
Set up your development environment
Develop the registries, services, and APIs for a voter registration module that were described in the Design Guide
Integrate with an existing DIGIT environment and re-use a lot of the common services using Kubernetes port forwarding
Test the new module and debug
Build and deploy the new service in the DIGIT environment
The guide is divided into multiple sections for ease of use. Click on the section cards below to follow the development steps.
Access the sample module here. Download and run this in the local environment.
This section provides the complete details of the system pre-requisites, prepping and setting up the system for development.
Follow the steps in the docs resources below:
List of tutorials for the tools required to build on DIGIT platform
On this page:
Tools Required | Tutorials Resource Links |
---|---|
Topics | Study Materials / Youtube links | Official links/documentation |
---|---|---|
Artefacts required before beginning the development phase
The outputs of the design phase are the inputs to the development phase.
The docs below provide the steps and the resources required to build and design the module.
Generate Project Stub
This page provides detailed steps for generating projects using the given API specifications.
Prepare contracts that detail all the APIs that the service is going to expose for external consumption. eGov uses a customised tool.
Download the jar file and make sure it is available in the classpath. Use the to generate client SDKs using these Swagger contracts.
Refer to the following tutorials to understand the creation of Swagger contracts -
Use the generic command below to create an API skeleton for any Swagger contract:
The following sequence is used to generate the API skeleton using codegen jar:
Navigate to the folder where you have downloaded the codegen jar.
Execute the following command:
OR
Rename the output
folder to birth-registration.
Import it in Eclipse or VS Code.
Update the spring-boot-starter-parent to 3.2.2 in pom.xml.
Perform a maven update once the spring boot version is updated.
Put a slash in front of server.contextPath and add this property to the application.properties file which helps request handlers to serve requests -
Add the below external dependencies to pom.xml:
Follow our developer guides to start building on DIGIT
Welcome to DIGIT Developer Guides!
For ease of use, we have divided our guides broadly into 2 sections:
For a practical orientation, these guides, together, will walk you through all the steps required to build a birth registration service module and a corresponding UI module.
Once PostgreSQL (v10) has been installed and the basic setup is done, we use Flyway to create the tables.
Configure the below properties in the application.properties file to enable flyway migration:
Add the Flyway SQL scripts in the following structure under resources/db/migration/main
:
Add the migration files to the main folder. Follow the specified nomenclature while naming the file. The file name should be in the following format:
Example: V20180920110535__tl_tradelicense_ddl.sql
For this sample service, use the following SQL script to create the required tables.
This section showcases how to create a basic Spring Boot project using an API spec and configure the database.
Follow the steps detailed below:
Follow the steps outlined on this page to setup the DIGIT development environment.
To setup the DIGIT development environment -
Run the Kafka and PostgreSQL on the development machine and re-use other services from the DIGIT development environment. The following tools are required for development:
Install Git
Install JDK17
Install IDE - To create SpringBoot/Java applications it is recommended to use IntelliJ IDE. IntelliJ can be downloaded from the following links -
Install the Lombok plugins for IntelliJ as we use Lombok annotations in this module.
Install Kafka (version 3.2.0 which is the latest version) - To install and run Kafka locally, follow the following links -
Install Postman - To install Postman, follow the following links -
Install Kubectl - Kubectl is the tool that we use to interact with services deployed on our sandbox environment -
Install aws-iam-authenticator - (if the DIGIT development environment is in AWS) -
Install PostgreSQL v14 locally
Add configuration - Post installation of Kubectl, add the following configuration in the Kubernetes config file to enable access to resources in our sandbox environment. Kubernetes config file is available in the user's home directory (which varies from OS to OS).
For example, on a Mac, it is available at:/Users/xyz/.kube/config
Once the config file is created, add the following content to it.
Note: Replace the placeholder keys and tokens in the snippet below with your AWS-specific keys. Contact your system administrator for help with this.
Once the configuration file is created, access the pods running in the environment by typing: kubectl get pods
This lists all the pods in the development environment.
In case you get an error stating “Error: You must be logged in to the server (Unauthorized)”, add sudo before the command. For example, “sudo kubectl get pods”. That should resolve the error.
The application.properties file is already populated with default values. Read on to learn how to customise and add extra values for your application (if required).
Kafka topics for the module that need to be added are detailed .
There are three ways to access services:
a. Run the code locally.
b. Access the service in a DIGIT environment.
c. Access the service locally via port forwarding. This bypasses Zuul's authentication and authorization.
Wherever the localhost is in the URL, the Kubernetes port forwarding has been set up from the development environment to the specified port. In your setup, modify the URLs for the various services depending on whether you are using them from an environment or running them locally or accessing them via port-forwarding.
For example, if no port forwarding has been done, you will have to provide the FQDN of your DIGIT install instead of localhost. Also, without port forwarding, you will have to update the auth tokens in your .aws profile file periodically.
Include all the necessary service host URLs and API endpoints in the "application.properties" file.
This guide specifically references the User, Localisation, HRMS, IDGen, MDMS, and Workflow services that are operational within the DIGIT development environment.
Add the following properties to the application.properties
file.
The following properties must be added for configuring the database and Kafka server. Make sure to use the default values to tune in the Kafka server that can be overwritten during deployment.
Include the following properties in the "application.properties" file to configure the database and Kafka for development purposes once you have completed adding the external dependencies to the "pom.xml" file and reloading the Maven changes.
Append Kafka configurations as per the specific requirements of the DIGIT services. Each module may use different configurations to manage its topics.
Available design artifacts
Find below the Open API specifications defined for this guide:
As a part of this guide, we are going to build a single birth registry. We will re-use the user registry from the DIGIT core. This will capture the mother and father details and store them in the user registry. The baby's details will remain in the birth registry.
A single birth service will manage the registry.
Download the contract and save it in a file locally. Run the following command to generate the skeleton code from the contract.
Learn all about the development pre-requisites, design inputs, and environment setup
The first step is to create and configure a spring boot project
The next step is to integrate the Persister service and Kafka to enable read/write from the DB
Steps on how to integrate with other key DIGIT services
Learn how to integrate the billing and payment services to the module
Learn how to integrate advanced services to the built module
Test run the built application in the local environment
Deploy and run the modules
eg_bt_registration | This table holds the baby's information |
eg_bt_address | This table holds the applicant address who applied for the birth registration. |
The pom.xml typically includes most of the dependencies listed below at project generation time. Review and ensure that all of these dependencies are present. Update the pom.xml in case any are missing.
Models/POJOs of the dependent service can be imported from the digit-core-models library (work on creating the library is ongoing). These models are used to integrate with the dependent services.
These are pre-written libraries which contain tracer support, common models like MDMS, Auth and Auth and the capability to raise custom exceptions.
Once these core models are imported, it is safe to delete the RequestInfo, and ResponseInfo classes from the models folder and use the ones present in the common contract that is imported.
Before starting development, create/update the following classes as given below.
Delete the following classes which have been generated from codegen - -Address -AuditDetails -Document -Error -ErrorResponse -RequestInfo -RequestInfoWrapper -ResponseInfo -Role -User -Workflow After this import the above classes from egov common-service library as follow-
Create the BirthApplicationSearchRequest POJO with the following content -
Update BirthApplicationAddress pojo
Create the BTRConfiguration class within the configuration package. The MainConfiguration class should already exist inside the config package.
The core models are imported.
Methods in the service layer, upon performing all the business logic, call methods in the repository layer to persist or lookup data i.e. it interacts with the configured data store. For executing the queries, JdbcTemplate class is used. JdbcTemplate takes care of the creation and release of resources such as creating and closing the connection etc. All database operations namely insert, update, search and delete can be performed on the database using methods of JdbcTemplate class.
On DIGIT the create and update operations are handled asynchronously.
The persister service listens on the topic to which service applications are pushed for insertion and updation. Persister then takes care of executing insert and update operations on the database without clogging the application’s threads.
The execution of search queries on the database returns applications as per the search parameters provided by the user.
Create packages - Add thequerybuilder
and rowmapper
packages within the repository folder.
Create a class - by the name of BirthApplicationQueryBuilder in querybuilder
folder and annotate it with @Component
annotation.
Insert the following content in BirthApplicationQueryBuilder class -
Create a class - by the name of BirthApplicationRowMapper within the rowmapper package and annotate it with @Component.
Add the following content to the class.
Create a class - by the name of BirthRegistrationRepository within the repository folder and annotate it with @Repository annotation.
Add the following content to the class.
The repository layer is implemented.
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 -
The service layer performs business logic on the RequestData and prepares the Response to be returned back to the client.
Follow the steps below to create the service layer.
Create a new package called Service.
Create a new class in this folder by the name BirthRegistrationService.
Annotate the class with @Service annotation.
Add the following content to the class -
NOTE: At this point, your IDE must be showing a lot of errors but do not worry we will add all dependent layers as we progress through this guide and the errors will go away.
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.
Find the steps to create the Validation Layer and Enrichment Layer on DIGIT.
All business validation logic should be added to this class. For example, verifying the values against the master data, ensuring non-duplication of data etc.
Follow the steps below to create the validation layer.
Create a package called validators. This ensures the validation logic is separate so that the code is easy to navigate through and readable.
Create a class by the name of BirthApplicationValidator
Annotate the class with @Component annotation and insert the following content in the class -
NOTE: For the sake of simplicity the above-mentioned validations are implemented. Required validations will vary on a case-to-case basis.
This layer enriches the request. System-generated values like id, auditDetails etc. are generated and added to the request. In the case of this module, since the applicant is the parent of a baby and a child cannot be a user of the system directly, both the parents' details are captured in the User table. The user ids of the parents are then enriched in the application.
Follow the steps below to create the enrichment layer.
Create a package under DIGIT by the name of enrichment. This ensures the enrichment code is separate from business logic so that the codebase is easy to navigate through and readable.
Create a class by the name of BirthApplicationEnrichment
Annotate the class with @Component and add the following methods to the class -
NOTE: For the sake of simplicity the above-mentioned enrichment methods are implemented. Required enrichment will vary on a case-to-case basis.
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.
Information on creating a custom calculator service
This calculator service integrates with the core platform's billing service & generates a demand. A bill can be fetched based on the demand and presented to the user. This page provides details about creating a custom calculator service.
Code for the custom calculator service is here. A separate API spec is written for the calculator service.
A calculator service typically has three APIs:
_calculate - This API returns the calculation for a given service application.
getbill or createbill - Creates and returns the bill associated with a particular application.
_search - to search for calculations.
The birth registration service calls the _calculate API to generate a demand for birth registration charges.
In governments, each region, city or state has custom rates and charges for the same domain. For example, birth certificate registration rates may differ from city to city and the way it is computed can also vary. This cannot be generalised into a platform service. However, billing is a generic platform service.
The way DIGIT solves for this is to "unbundle" the problem and separate out billing from calculations. A customisable service called a "calculator" is used for custom calculation. The calculator then calls the billing service to generate the bill. Each service/module ships with a "default" calculator which can then be customised for that city.
Postman collection of btr-calculator is available here.
The indexer is designed to perform all the indexing tasks of the DIGIT platform. The service reads records posted on specific Kafka topics and picks the corresponding index configuration from the yaml file provided by the respective module configuration. Configurations are yaml based. A detailed guide to creating indexer configs is mentioned in the following document - Indexer Configuration Guide.
Create a new file under egov-indexer
in configs
repo by the name of digit-developer-guide.yml
and place the below content into it -
Note: Follow the steps below when the code is deployed to the DIGIT environment. These steps are not applicable for deployment in the local environment. You may choose to follow these when you build and deploy.
Navigate to the forked 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-indexer". Find the "egov-indexer-yaml-repo-path" property and add the path to your new indexer file here. The code block is shown below for reference:
Raise a PR to the DevOps branch which was forked/used to create the deployment. Once that is merged, restart the indexer service and make sure the cluster configs are propagated.
Java Basics
Spring Boot
Postgres
Kafka
Elastic Search
Json Path Basics
Yaml & regular expressions
Kubernetes
Helm
HTML5
CSS3
Javascript
Learn Javascript
ReactJs
Routing , Lazy Loading , Custom Hooks
React-hook-form
React Query
Tailwind css
Axios (Optional)
i18Next(Optional)
Yarn(Optional)
Flutter
Click here to learn about Flutter
Implementing the controller layer in Spring
The web/controller layer handles all the incoming REST requests to a service.
Follow the steps below to set up the request handler in the controller layer.
Make a call to the method in the Service Layer and get the response back from it.
Build the responseInfo.
Build the final response to be returned to the client.
The controller class reflects the below content -
NOTE: At this point, your IDE must be showing a lot of errors but do not worry we will add all dependent layers as we progress through this guide and the errors will go away.
The web layer is now setup.
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.
Calculating costs for a service and raising demand for bill generation
The calculation class contains the calculation logic for the birth certificate registration charges. This can vary from city to city. Based on the application submitted, the calculator class will calculate the tax/charges and call the billing service to generate the demand.
What is a demand?
A demand is the official communication sent by a government authority to a citizen requesting them to pay for a service. A demand leads to a bill. When a bill is paid, a receipt is generated. A demand can be modified prior to bill generation.
For our guide, we are going to create a Calculation Service that will call the calculator to generate a demand. Follow the steps below -
Create a class under service
folder by the name of CalculationService
Annotate this class with @Service annotation and add the following logic within it -
Status of payment
A demand leads to a bill which then leads to payment by a citizen. Once payment is done, the application status has to be updated. Since we have a microservices architecture, the two services can communicate with each other either through API calls or using events.
The collection service publishes an event on a Kafka topic when payment is collected for an application. Any microservice that wants to get notified when payments are done can subscribe to this topic. Once the service consumes the payment message, it will check if the payment is done for its service by checking the businessService code. The application status changes to PAID or triggers a workflow transition.
For our guide, follow the steps below to create payment back update consumer -
Create a consumer class by the name of PaymentBackUpdateConsumer. Annotate it with @Component annotation and add the following content to it -
Create a new class by the name of PaymentUpdateService in the service folder and annotate it with @Service. Put the following content in this class -
Create the following POJOs under models folder:
PaymentRequest.java
Payment.java
PaymentDetail.java
Bill.java
BillDetail.java
BillAccountDetail.java
The birth registration module follows a simple workflow derived from the swimlane diagrams. Please check the section for correlation as well as the 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.
The final step in this process is the creation of configurations to create a voter registration PDF for the citizens to download. For this, we will make use of DIGIT’s PDF service which uses PDFMake and Mustache libraries to generate PDF. Detailed documentation on generating PDFs using PDF service is
Follow the below steps to set up PDF service locally and generate PDF for our voter registration service -
Clone repo.
Clone repo.
Navigate to the DIGIT-Dev repo and open up a terminal. Checkout DIGIT_DEVELOPER_GUIDE branch.
Navigate to the configs folder and under pdf-service data config. Create file by the name of digit-developer-guide.json
Add the following content in this newly created data config file -
Navigate to the format-config within the pdf service folder. Create a file by the name of digit-developer-guide.json
and add the below content to it -
Open the PDF service (under core-services repository of DIGIT-Dev) on your IDE. Open Environment.js
file and change the following properties to point to the local config files created. For example, in my local setup I have pointed these to the local files that I created -
Make sure that Kafka and Workflow services are running locally and port-forward the following services -
egov-user to port 8284
egov-localization to port 8286
egov-filestore to 8288
egov-mdms to 8082
PDF service is now ready to be started up. Execute the following commands to start it up
Once PDF service is up hit the following cURL to look at the created PDF -
Note: Follow the steps below when the code is deployed to the DIGIT environment. These steps are not applicable for deployment in the local environment. You may choose to follow these when you build and deploy.
Navigate to the forked DIGIT-DevOps repository.
Find the deployment helm chart that was used to deploy DIGIT within the deploy-as-code/helm/environments
directory.
Find "pdf-service"in the deployment helm chart (which was used to set up the DIGIT environment).
Find the "data-config-urls"
property.
Add the path to your new PDF config file here. For this module, we have added file:///work-dir/configs/pdf-service/data-config/digit-developer-guide.json
to the end of the data-config-urls
. The code block is shown below for reference:
Raise a PR for this to the appropriate branch of DevOps which was forked/used to create the deployment.
Restart the PDF service in the k8s cluster, once the PR is merged. It will pick up the latest config from the file above.
DIGIT UI development guide
After the backend development and deployment of DIGIT, as per the steps detailed in the , it is time to start building the UI screens. For illustration purposes, we will build the citizen and employee screens for the Sample module.
This guide offers a systematic view of creating the application screens on DIGIT.
Developer code: Download the UI code from the link here .
DIGIT UI basics to browse through before initiating the frontend development.
Follow the cards below to build and deploy the DIGIT UI.
Custom UI development depends on specific user requirements. We have listed common scenarios (listed below) - follow the steps outlined for each to set up DIGIT UI as per requirements.
Visit our FAQs section to troubleshoot -
Follow the instructions on this page to build and deploy applications on DIGIT.
eGov recommends before developing on top of DIGIT. This ensures that new modules can be developed and deployed in a streamlined way. DIGIT ships with CI as code as part of the DevOps repository. Run the before developing on DIGIT.
Step 1: Add entry in build-config.yaml file in the master branch of the forked MDMS repository. This will set up the job pipeline in Jenkins. Make sure to also add the same config to the feature branch you are working on. Refer to this .
Step 2: Follow the instructions for the , and configuration.
Step 3: Go to the Jenkins build page, select "Job Builder" and click on "Build now". This will pull config from build_config.yaml and identify all modules that need to be built.
Step 4: Once the build is done, go to your Jenkins build page. The service will appear under the repository path in which it has been added, i.e. if the service is added under core-services, it will show up in the core-services section on the aforementioned page.
Step 5: Most likely, you will be working on a feature branch for this module and not on "master". Click on "Build with parameters" for the module and search for the branch name in the filter box. Select the feature branch you are working on and then click "Build". This will make sure that Jenkins builds the module pulling code from the branch you prefer.
Step 6: Click on "Console Output". If the build pipeline and docker registries have been set up properly as part of the CD/CI setup, the docker image will be built and pushed to the registry. The console output will have the docker image ID for the module. Scroll down to the bottom and copy the following information -
Step 7: After copying the docker image ID, go to your Jenkins server home page, click on "Deployments" and scroll to find your deployment environment. Deployment environments have the template of deploy-to-<env name> and get created as part of the CD/CI setup. If multiple environments have been configured, you will see multiple deploy-to-* entries.
Step 8: It is best practice to always test out any new module in the dev environment. Select the environment you would like to deploy to and click on the "Run" icon on the right-hand side of the page against the environment. In the Images text box, paste the copied docker image ID and click "Build". Refer to the screenshot below.
Jenkins will now take care of deploying the new image to the DIGIT environment.
Step 9: Test your new service by testing out the APIs via Postman.
Key components of DIGIT-UI
This page provides the architecture and key features of the DIGIT UI. Click on the broader headings below to find the details.
Broadly, the DIGIT UI frontend components are categorized as below:
The CSS Library contains all the classes both in the module and compiled form.
This can be imported using import "@egovernments/digit-ui.css/Button"
or full CSS import using import "@egovernments/digit-ui.css"
The Component Library contains a set of all required components defined in it.
The libraries and utils contain the following:
Localization workflows
API Handling Strategies - Centralize API caching and handling strategies within shared functions, accessible by all modules. This ensures consistency and efficiency across the application.
Localisation
The module is a closed system for states, allowing access only to node_modules or CDNs. State-specific components can be provided during the module's initialization in the employee or citizen application.
Below is an illustration of how the module structure looks like:
Modules contain the following inbuilt
Theme - this may change if we later decide to use any css-in-js
library, like styled-components
.
Components
Routes
State management
Business logic
API integrations
The first line contains the Architecture Component name or info
The second line contains an npm package and a template in brackets for creating the component.
Easy-to-use CLI
Handles all modern JS features
Bundles commonjs
and es
module formats
Supports complicated peer-dependencies
Supports CSS modules
The templates have the following folder structure: Components related to the template are inside the src
folder. An example is provided to demonstrate the app created by the template.
We have two main React Apps:
micro-ui-internals
This is meant for the eGov development team to build components and default modules.
It contains the following modules:
CSS Library
UI Components (presently react-components
)
Utils Library: Contains Services, Localization handling and React Hooks.
UI Modules
Core - containing login, routing and global state.
PGR
FSM
PT
Payment
etc ...
micro-ui
This is meant for the state team to manage, make changes, and deploy
It allows the import of digit-ui-internals
modules
Customizations
View
Services
Build and deploy scripts
Dockerfile & nginx.conf
build-config.yaml
The app imports the developed module.
In the next phase, we can merge the Employee and Citizen apps into one app with role-based permissions and content.
Run the deployed application in the local environment
It is time to test our completed application! Follow the steps on this page to test and run the deployed application.
Before testing our application, we need to run a couple of services locally -
To run the persister service locally -
Run Kafka.
Open egov-persister folder which should be present under core-services repository.
Update the following properties in application.properties file -
To run indexer service locally (optional) -
Run Kafka.
Run ElasticSearch.
Open egov-indexer folder which should be present under core-services repository.
Update the following properties in application.properties file -
For example, the path to config files would be something like -
To run and test our sample application, follow the below steps -
Ensure that Kafka, Persister, Indexer and PDF services are running locally and run the code of voter-registration-service from DIGIT_DEVELOPER_GUIDE branch (for consistency).
Port-forward the following services -
egov-user to port 8284 (for e.g. - kubectl port-forward egov-user-58d6dbf966-8r9gz 8284:8080
)
egov-localization to port 8286 (for e.g. kubectl port-forward egov-localization-d7d5ccd49-xz9s9 8286:8080
)
egov-filestore to 8288 (for e.g. kubectl port-forward egov-filestore-86c688bbd6-zzk72 8288:8080
)
egov-mdms to 8082 (for e.g. kubectl port-forward egov-mdms-service-c9d4877d7-kd4zp 8082:8080
)
Run birth-registration-service that we just created.
Setup environment variables in Postman:
hostWithPort - Eg. yourserver.digit.org:8080 or yourserver.digit.org if the service is running on port 80.
applicationNumber - used in the search/update requests to search for that specific application number. Set it post the create birth registration application call.
In case no workflow has been configured, run the scripts to configure and search for workflow. Double-check ID gen by running the ID gen script.
a. Hit the _create API request to create a voter registration application.
b. Hit the _search API request to search for the created voter registration applications.
c. Hit _update API request to update your application or transition it further in the workflow by changing the actions.
Multi-language Translate React JS APP with React Hook & i18next - Multi-language Translate React JS APP with React Hook & I18NEXT
- Once the setup is complete, run the sample module provided in this guide. Test run the module and deploy it using CI/CD to your development environment.
for example usage and local dev for React-based libraries
for bundling
for transpiling
Import the postman collection of the APIs that this sample service exposes from here -
Radio button components enable users to select a single option from a list of alternatives.
While using the radio component independently and to disable it set the prop as disabled={true}.
For more information: Storybook for radio field
A toggle UI component is a user interface element that allows users to switch between two states, typically "on" and "off" or "enabled" and "disabled".
For more information: StoryBook for toggle field
This page outlines methods to reduce UI/UX audit bugs post-development by enhancing a UI library. Key improvements include:
These enhancements aim to streamline development and ensure a consistent, user-friendly interface.
To resolve UI/UX audit issues, we will implement new components featuring enhanced functionality, modern design, and superior performance. These elements should adhere to current design trends and meet user expectations to improve the user experience. Below is the list of DIGIT Components
Standardising design principles ensures consistency across the UI library, reducing the likelihood of UI/UX audit bugs. This involves establishing design guidelines, naming conventions, and component usage patterns.
Enhancing the stability of the UI library is crucial for reducing UI/UX audit bugs. This includes optimizing code quality, implementing robust testing strategies, and monitoring performance to identify and address potential issues.
Transitioning from px to em units improves scalability and accessibility, reducing UI/UX audit bugs related to inconsistent text sizes and layouts across different devices and screen resolutions.
Storybook provides a development environment for testing and documenting components, helping to identify and address UI/UX audit bugs early in the development process.
Implementing colour and text size constants ensures consistency in styling across the UI library, reducing UI/UX audit bugs related to colour contrast, readability, and visual hierarchy.
Introducing newer component variants enhances flexibility and caters to diverse user requirements, reducing UI/UX audit bugs related to limited functionality or options.
Creating Flutter widgets extends the UI library's reach to mobile platforms, reducing UI/UX audit bugs related to inconsistent user experiences across different devices and operating systems.
Implementing the improvements discussed here ensures the UI library is better equipped to reduce UI/UX audit bugs after development. These enhancements promote consistency, scalability, accessibility, and cross-platform compatibility, resulting in a more polished and user-friendly experience for end-users.
The checkbox component allows users to select one or multiple options from a given set of choices.
By default, the checkbox appears before the label, but this order can be changed using the isLabelFirst
option.
For more information: Storybook for checkbox field
Buttons are used for specific user actions. These clickable UI components allow the users to interact with the system.
Primary Variant
Secondary Variant
Tertiary Variant
Link Variant
Icons are sent as a string added before the label. To add it as a suffix, set the isSuffix parameter to true.
For more information: StoryBook for button components
A dropdown UI component is a user interface element that allows users to select one option from a list of choices. When the dropdown is clicked, it expands to reveal the list of options, and the user can click an item to select it. This component is often used in forms and navigation menus to save space and organize options efficiently.
Simple Dropdown
To show the icons beside each option, set the showIcon prop to true. Send the icons as a string along with the required options. The dropdown is searchable but can be configured using the isSearchable prop.
To reset the option after selecting it, clear the option and click enter.
For more information: StoryBook for simple dropdown
Nested Dropdown
For the type dropdown with the "nesteddropdown" variant, options can be configured as shown above. Icons are optional but can be included if needed. The search results are displayed as per the main category names.
For more information: Storybook for nesteddropdown varinat
Tree Dropdown
Here's a simplified version of your explanation:
For the type dropdown with the "treedropdown" variant, options can be configured as shown in the configuration above. Currently, the treedropdown does not support icons. Clicking on the parent option displays the child options. The final child options are enabled for selection.
This version maintains the necessary details while being clear and concise.
For more information: Storybook for treedropdown
NestedText Dropdown
For the type
dropdown with the variant nestedtextdropdown
, use the above configuration details to define the options.
Use this variant when you need to describe each option.
For more information: StoryBook for nestedtext dropdown.
Profile Dropdown
For the type dropdown with the "profiledropdown" variant, use the configuration details above to define the options.
You can set any image as a profileIcon as shown in the configuration.
For more information: Storybook for profiledropdown
Profilenestedtext Dropdown
For more information: Storybook for profilenestedtext dropdown
Simple MultiSelect Dropdown
For a multi-select dropdown, set options in the format given in the above configuration.
Ignore these If icons are not needed. Else, set the showIcon to true. Set the isDropdownWithChip parameter to true to show chips once the options are selected.
Configure the clearLabel param to ensure the chips are cleared from the label.
For more information: Storybook for multiselect dropdown
Nested MultiSelect Dropdown
Multiple options can be selected for each category.
For more information: Storybook for nested multiselect dropdown
Tree MultiSelect Dropdown
In a tree multiselect dropdown, you can select both parent and child options. Choosing a child option does not automatically select the parent option. When only some child options are selected, the parent option will show in an intermediate state.
Selecting any parent option will automatically select all its child options.
For more information: Storybook for treemultiselect dropdown
NestedText MultiSelect Dropdown
For more information: Storybook for Nestedtext Multiselect Dropdown
A list of FAQs for developers by developers
1. Hot Reload: Flutter's hot reload feature allows developers to see instant updates to the UI during development. It significantly speeds up the development process, enabling developers to experiment, iterate, and refine their app's UI and functionality in real-time.
2. Single Codebase: One of the key advantages of Flutter is the ability to write code once and deploy it on multiple platforms. With a single codebase, developers can build applications for Android, iOS, web, and desktop platforms, reducing development time and effort.
3. Expressive UI: Flutter offers a rich set of customizable widgets that allow developers to create beautiful and responsive user interfaces. These widgets are designed to adapt to different screen sizes and form factors, providing a consistent look and feel across platforms.
4. Fast Performance: Flutter's performance is comparable to native applications as it uses Dart, a compiled language, and leverages the Skia graphics library. Flutter apps are compiled to highly efficient native code, ensuring smooth animations, fast startup times, and excellent overall performance.
5. Access to Native Features: Flutter provides direct access to native device features and APIs, enabling developers to utilize platform-specific capabilities. Whether it's accessing device sensors, camera, geolocation, or integrating with platform-specific services, Flutter makes it easy to leverage native functionality.
6. Rich Ecosystem: Flutter has a vibrant ecosystem with a wide range of packages and plugins available through the Flutter Package Manager (pub.dev). These packages extend the functionality of Flutter and offer pre-built solutions for common app requirements, saving development time and effort.
The Input field enables users to interact with the application through content input and data. The component allows users to input responses or data based on specific requirements.
Type: text
Below are the details for the type: text:
Example Usage of TextInput Component
For more information: StoryBook for Text Input field
Type: date
The date can be selected from the date chart. If editableDate is set to true, the date can be edited without using the date chart; otherwise, it cannot be edited.
For more information: StoryBook for date field
Type: time
The time can be selected from the time chart. If editableTime
is set to true
, the time can be edited without using the time chart; otherwise, it cannot be edited.
For more information: StoryBook for time field
Type: geolocation
Click on the geolocation icon to call and activate the onIconSelection function. Otherwise, the location details are captured by default.
For more information: StoryBook for Geolocation field
Type: numeric
The numeric value by default increases and decreases by step value 1. But it can be configured using the step value sent as a prop in the config.
For more information: StoryBook for Numeric field
With Prefix and Suffix
Type: password
For more information: Storybook for password field
Type: search
There are two variants for the textarea - one has a resize option and the other is resizeSmart which auto-adjusts the height based on the input content.
For more information: Storybook for TextArea
Migration guide to aid users in shifting from the "react-components" package to the "components-core" package
Topics covered:
This document details the essential modifications needed in the modules for smooth integration of components from the "components-core" package. It offers precise guidelines on utilizing FormComposerV2 and InboxSearchComposer, along with updates made in the configs.
In the components-core package, several enhancements have been implemented to improve code clarity and address issues related to pixel inconsistencies. Previously, there were challenges associated with pixel-based sizing, leading to inconsistencies across different devices and screen resolutions. To mitigate this, the codebase has been updated to utilize rems as the primary unit of measurement. This transition to rems offers several advantages over pixels, including improved scalability and responsiveness across various viewport sizes.
Adopting rems ensures the components' styling is more consistent and adaptable, providing a seamless user experience across different platforms and devices.
Furthermore, TextInput, TextArea, Radio, Button, Checkbox, Toggle, Dropdown, Multiselectdropdown, InfoCard, and Toast offer different variants. Adding variants for these components makes them more flexible, serving a wider range of purposes and meeting different design needs effectively.
These are some of the updates made in the components-core package.
Atom | Variants | State |
---|---|---|
To install:
Add the dependency in the frontend/micro-ui/web/package.json
Syntax for importing any components:
Syntax for importing FormComposerV2:
In the micro-ui/web/micro-ui-internals/packages/modules/Project/src/pages/employee/CreateProject/CreateProjectForm.js:
In the micro-ui/web/micro-ui-internals/packages/modules/Project/package.json :
Add “@egovernments/digit-ui-components-core”:”0.0.1” in the dependencies.
And when you import any component the syntax for the import statement is:
In the micro-ui/web/micro-ui-internals/packages/modules/Project/src/pages/employee/ProjectWMSSearch:
Verify the components in the sample module:
Sample module Integrated with new components
These are some of the modifications that need to be done in the modules to use the components from the components-core package.
The InfoCard component has four variants: default, success, error and warning. The default labels for these variants are Info, Success, Error and Warning.
However, the label can be configured using the label prop. The configuration enables users to set the array of elements for display in the info card component.
By default, the elements are shown in the vertical direction. To show the elements in the horizontal direction set the inline prop to true.
With Additional Elements:
DIGIT UI components is a collection of common Flutter widgets designed to simplify UI development. These components offer easy-to-use and customizable features to enhance UI design and streamline the development process.
Add this to your pubspec.yaml file:
Then run:
Import the package in your Dart code:
Atom | Variants | States |
---|
DIGIT UI components include various text input fields with optional features such as character count display, inner labels, and help text. These fields also come with built-in validation support for improved data integrity.
Text Input Field: A text input field for general alphanumeric data.
Text Area Input Field: For multi-line text input.
Search Input Field: Designed for search queries or search-related inputs.
Password Input Field: A secure input field for password entry.
Numeric Input Field: This field is suitable for numeric input.
Date Input Field: An input field designed to capture dates.
Time Input Field: Use this field to input time values.
Location Input Field: Specifically for geographic location data, such as coordinates.
These are some common props which can be sent inside all the input fields:
TextAreaScroll
Usages
Usages
Usages
Usages
Usages
Usages
Usages
Usages
The Toggle Buttons component in DIGIT UI presents a list of interactive toggle buttons, providing users with the ability to select an option. Each button is equipped with callbacks for both mouse-down and hover effects, ensuring a responsive and engaging user interface.
The widget contains the following required parameters:
Below are some additional parameters:
Usages
Add the following lines of code:
The Toast component is used to provide users with temporary notifications. It does not require any user action.
Success Toast
Warning Toast
Error Toast
The default transitionTime for any variant of toast is 5 seconds. However, this is configurable using the transitionTime prop (in milliseconds).
The Radio Buttons component in DIGIT UI empowers users to make a single selection from a list of options. This intuitive interface provides a smooth user experience with hover and mouse-down effects. It is designed to handle both horizontal and vertical layouts based on the screen width.
Below are some required parameters inside the radio list:
The following are additional parameters:
Usages
Add the below lines of code to configure the radio button:
DIGIT UI components provide a variety of buttons with optional suffix and prefix icons, contributing to a cohesive and visually appealing UI.
Button Type
Primary: Represents the primary action. It features a prominent colour, and its appearance can change on hover or click.
Secondary: Offers a secondary action. It has a different colour scheme than the primary button.
Tertiary: Provides a tertiary action with a distinct visual style.
Link: Resembles a hyperlink, suitable for navigation or linking to other parts of the application. It typically includes an underline.
Hover and Disabled State
The DigitButton widget handles hover effects and a disabled state. When the button is hovered over, it can exhibit visual changes depending on its type. The disabled state prevents interaction and adjusts the button's appearance accordingly.
Icon Placement
The widget supports the placement of icons both before and after the label text. This allows for flexibility in button design.
Properties
It contains the following required Parameters:
These are some optional parameters:
To use the primary button add the below lines of code:
With suffix Icon:
With prefix Icon:
To use the secondary button add the following lines of code:
Prefix and Suffix icons can be added to the secondary button using the same code as given for the primary button.
To use the tertiary button add the below lines of code:
To use a link, add the following lines of code:
This widget is a versatile and customizable checkbox component. It provides a checkbox with an associated label and allows users to toggle between checked and unchecked states. This widget supports various customisation options, including the ability to customise the checkbox icon colour, label, padding, and disabled state.
The widget provides a hover state, visually indicating when the user hovers over the checkbox. This is useful for enhancing the user experience.
This widget contains the following required parameters:
These are some option parameters:
Usages
Add the following lines of code:
This widget is a versatile and customizable information card designed inside a digit ui widget. It provides a visually appealing way to display information, with options for different types of information.
The Info Card supports different types of information, each with its distinct visual style:
Info: Default information card with a blue background and an information icon.
Success: This represents a successful operation, featuring a green background and a check-circle icon.
Error: Indicates an error or unsuccessful operation with a red background and an error icon.
Warning: Represents a warning or caution, featuring a yellow background and a warning icon.
Developers can include additional widgets beneath the description for extra information or interactive elements. The inline property controls whether these widgets are displayed horizontally or vertically.
Info cards contain the following required parameters:
There are some additional customisation parameters:
Usages
Info Card
Success Card
Error Card
Warning Card
DIGIT UI components offer various drop-down menus, including single-select, multi-select, and tree-select options.
The Single Select drop-down in Digit UI Components provides a drop-down menu for users to make a single selection. It supports various features such as item filtering and selection handling. This intuitive component supports options with additional features such as images, icons, and descriptions, complemented by hover and mouse-down effects.
Sub-Types
Default drop-down
Nested drop-down
Tree drop-down
Below are some required parameters:
These are some additional customisation parameters:
DropdownItem
Inside the dropdown item, we can pass additional parameters to include the drop-down like description, image and icons.
There are the customisations available inside the drop-down item:
TreeNode
Inside the tree node we can pass a list of children associated with a node:
Usages
Default drop-down
With description and profile image:
Nested drop-down
Tree drop-down
The Multi-Select drop-down in DIGIT UI components offers a user-friendly interface for selecting multiple options simultaneously. This clean and intuitive component is equipped with built-in chips and provides responsive mouse-down and hover effects.
Sub-Types
Default drop-down
Nested drop-down
Tree drop-down
Below are some required parameters:
These are some additional parameters:
Usages
Default Drop-down
Nested Drop-down
Tree Drop-down
This page lists the technical resources and knowledge required to develop a user interface on DIGIT.
Prior knowledge of React JS
Prior knowledge of HTML / CSS
Prior knowledge of Redux/Hooks
Prior knowledge of SCSS/React StoryBook
Prior knowledge of Git
Prior knowledge of Queries and Mutations
Knowledge of the DIGIT UI framework
Check the page to access help documents on the tools required for UI development.
The Toast widget provides a customizable toast notification for Flutter applications. It is designed to display short-lived messages, alerts, or notifications to users in a visually appealing and informative manner.
The ToastType enumeration defines different types of toasts, including:
success: Indicates a successful operation.
error: Indicates an error or failure.
warning: Indicates a warning or caution.
The Toast widget provides a static method for displaying toasts. This method includes the following parameters:
Usage
Success Toast
Error Toast
Warning Toast
Building and deploying the digit-ui module
Follow the instructions to set up the job pipeline. Ignore the steps not applicable to the frontend.
Instructions here are provided assuming CD/CI has been set up using the DIGIT ci-as-code module.
All content on this website by is licensed under a .
This page provides the steps to configure the FormComposer.
For complex configuration or screen details refer to documentation on
There are 3 new use cases added to the FormComposer in addition to the default one where the whole form was rendered in a single card. Those 2 are the following:
Multiple cards
Cards with navigation menu
Multiple cards with navigation menu on a single card
The following use cases are covered in the .
URL to access:/works-ui/employee/works/sampleForm
This can be done by setting the showMultipleCards
prop to the FormComposer as true. In this case, every object in the formConfig will be treated as a separate Card and will be rendered accordingly.
Access .
FormComposer provides the option to activate a navigation menu that appears on top of the card. Each link in the menu corresponds to a specific card. To enable this feature, provide an array configuration for the navigation menu as a prop to the FormComposer component. Then, map each card with a link from the navigation menu configuration array using a designated key named "navLink", associating it with a value in the Navigation Menu Config.
This use case is the same as above. The only difference is the navLink
property in the config. If this property is present and valid for a card config, the corresponding card will be mapped to a navigation menu link. On the other hand, if navLink
is not present or invalid, the corresponding card will be rendered as a separate Card.
Multiple options can be selected.
Once the local setup is completed, the next step is to run the application locally. This document provides the steps on how to run the digit-ui on a local machine.
Step 1: To run the application in the local environment, add the .env
file in the example
folder -
Step 2: Copy the following content and add it to the .env file. If the user is a citizen, configure the .env file as shown below:
Step 3: To run the application as an employee, update the value of the param to - REACT_APP_USER_TYPE=EMPLOYEE.
Step 4: To direct the front end to different environments, update the REACT_APP_GLOBAL
variable and add the GlobalConfig environment file corresponding to that environment.
Update both REACT_APP_PROXY_API
and REACT_APP_PROXY_ASSETS
to the environment URL.
Before initializing the frontend app locally, ensure that you are in the specified directory.
Step 1: To initialise the Yarn execute the below command -
Step 2: Once the yarn initialization is successful execute the below command -
Step 3: Running this command will start the application.
There are two types of login -
Employee: If you log in as an employee, the below screen is displayed.
HomePage Employee: Once the employee is logged in, users are redirected to the employee home page.
HomePage Citizen: Once the citizens are logged in successfully, users are redirected to the citizen homepage.
if you do not have a global config and AWS credentials are not present, then create a temporary local config under the path:
Include this between the head tags
UI configuration for the application
This page offers details of the DIGIT UI configuration required to enable it in any environment. Browse through the configuration details listed below:
eGov recommends before developing on top of DIGIT. This ensures that new modules can be developed and deployed in a streamlined way. DIGIT ships with CI as code as part of the DevOps repository. Please run the before developing on DIGIT.
Step 1: Add entry in build-config.yaml file in the master branch of the forked repository. This will set up the job pipeline in Jenkins. Make sure to add the same config to the feature branch you are working on. Refer
Add the below content for digit-ui.
Step 2: Go to the Jenkins build page, select "Job Builder" and click on "Build now". This will pull the config from build_config.yaml and identify all modules that need to be built.
Step 3: Once the build is done, go to your Jenkins build page. The service will appear under the repository path in which it has been added, i.e. if the service is added under frontend, it will show up in the frontend section as below,
Step 2: Deploy-as-code/helm/charts/frontend/digit-ui
Step 1: Locate the following "deploy-as-code/helm/environments/works-dev.yaml" i
n the DevOps repository of your organization.
Step 2: Add the below code block within the environment YAML file used to deploy the Works platform -
This section contains the configuration that applies globally to all UI modules. These need to be configured before the configuration of service-specific UI.
Create a config file (globalconfigs.js) with the below-mentioned config (refer to code below).
Configure all the images/logos required in the S3 and add links as footerBWLogoURL , footerLogoURL.
Mention the state tenant ID as stateTenantId.
If any User roles have to be made invalid add as invalidEmployeeRoles.
Then push this global config file into your S3 bucket as globalconfigs.js
The S3 bucket has to be configured by the DevOps team, to store all the assets being used in the application like Logos, globalConfigs, etc.
Steps to create a new AWS Bucket -
Create a new AWS S3 Bucket
Update the Bucket Policy with the following content, to make the bucket public
Update the Cross-Origin Resource Sharing (CORS) configuration with the following content
To proxy the same bucket in any environment and make the necessary changes in the environment.yaml
file located in the DevOps repository's configmaps
under egov-config
, follow the steps below:
Add the s3-assets-bucket: "pg-egov-assets"
After adding the proxy in the environment file, restart the s3-proxy
build in the environment with config enabled.
Steps to add new screens in DIGIT-ui
This document provides the steps for creating new screens in the DIGIT-UI.
Creating a screen in DIGIT UI involve simple steps and is classified into 4 different screen -
To create any new screen of the Create type, use the FormcomposerV2 and transmit the configuration as specified in the file.
To check the different types of configurations, refer to the function.
To use any view screen, create the hook for initiating API calls and structure the configurations for the View section.
Refer to the integrated screen with ApplicationDetailsTemplate - .
The hook details for the same is mentioned in .js
The service configuration details are available in
To create any inbox screen, use the InboxComposer and add the following configurations:
Front-end module project structure
Before starting with the Module code, ensure your local development environment is set up. You can refer to the local development setup guide link given below for detailed instructions.
Download the UI code from the link here . if not done earlier
Follow the steps given below to create the project structure.
Once you have cloned the repository from Digit-Frontend, do the following.
Go to micro-ui-internals → packages → modules
.
Create a new folder with module's name , For example (Sample).
Create a folder called src and add the components , configs, hooks and pages inside that.
The project structure should be as in the image below:
After creating the new Sample
module, we need to create a package.json
file for the module, specifying the module name, version, scripts, and required dependencies.
Employee view of the module
Now that we are done with setting up the citizen module, the next step is to build the employee portal on top of the DIGIT UI for the Birth Registration module. The employee portal is designed to support multiple workflows like verifying the information and approving or rejecting the registered details of citizens.
Build the employee portal for a module - Steps
The guide provides examples and illustrations on how to set up and integrate the most commonly used DIGIT UI libraries.
Refer to the sample screens .
We can develop custom React hooks like useCustomAPIMutationHook
to fine-tune the application API interactions. The custom hooks allow us to control how data is fetched and managed, aligning it perfectly with our requirements.
This custom hook, useCustomAPIMutationHook
, simplifies API calls for mutation operations in React applications using react-query
. It allows parameter and body customization for requests to a specified URL, seamlessly managing loading indicators and states. This hook streamlines API interaction and state management within components.
Create useCustomAPIMutationHook
under the following path:
To override the useCustomAPIMutationHook
, create a new custom hook with the desired enhancements. When considering overriding useCustomAPIMutationHook
, identify specific modifications required, such as adding additional parameters or altering data processing logic. Create a new custom hook, preserving the original functionality while incorporating these modifications to suit specific application needs.
We need to replace the usage of the original hook throughout the codebase with the new custom hook. This ensures that wherever the original hook is used, the modified functionality of the custom hook is applied instead.
There is a hook called useCustomMDMSV2
, which is used to get data from a Multi-Domain Master Service (MDMS) API. This hook makes it easier to request data, handle load, and prepare the received data for React applications.
useCustomMDMSV2
Create the hook under the following path:
There are two common components for workflow related actions and timeline management.
WorkflowActions -
WorkflowTimeline -
Both of these components are available on each View Screen. The WorkflowTimeline component is responsible for presenting the workflow history at the bottom of the View Screen. Similarly, the WorkflowActions component renders an action bar at the bottom of the view screens, showcasing pertinent actions based on the logged-in user's role and workflow configuration.
This component is directly integrated with the component that renders all the relevant data in view screens. WorkflowTimeline component is called in this component like this:
It expects a few props:
BusinessService -> Name of the businessService from workflow configuration
applicationNo -> Idgen generated application number
tenantId
timelineStatusPrefix -> prefix used in localisation of every checkpoint in timeline
statusAttribute -> here we can pass the attribute(either status/state) that is the key in the workflow process instance response, whichever we want to show in the checkpoint.
This component internally calls the workflow APIs to fetch the process instance of the application and renders the history accordingly. It also makes a check for the current state of the application. If the current state is not terminated state then it will show an extra checkpoint at the top with statusAttribute as status to show pending states checkpoint. If the current state is terminated state then it will not show pending states.
Refer to the below snapshots, notice they both have 4 checkpoints. Approved refers to terminate state.
This component is rendered on every View component separately to render the action bar with relevant actions.
Sample code Snapshot:
It expects a few props:
BusinessService -> Name of the businessService from workflow configuration
forcedActionPrefix -> for localization
applicationNo -> Idgen generated application number
tenantId
applicationDetails -> same data returned from hook used on view screen
Url -> update API url to hit
setStateChanged -> when update is successful this is called. Hence search apis will be called again and workflow history and workflow actions will be updated without screen refresh
moduleCode
editApplicationNumber -> Used in case of edit/modify action
This component internally calls the update apis and shows a relevant toast on success/failure or a response screen in case of edit action.
Once the project structure is ready, it is time to install and configure the module dependencies in the Master Data Management Service (MDMS). Follow the steps below to finalise these.
After creating the Sample
module and its package.json
file, you need to ensure that this module is enabled in the citymodule.json
file in the MDMS (Master Data Management Service) configuration. If it is not enabled, you need to update the MDMS configuration accordingly. You need to add this module to the root tenant in your environment from your branch.
file location
for reference: .
For illustration here, add the following module (sample) as given below:
Register the Sample UI module in three places so that it will be available to the developer at runtime as well as at the time of deployment. Below are the three places where the module needs to be registered:
micro-ui/web/micro-ui-internals/package.json
micro-ui/web/micro-ui-internals/example/package.json
Micro-ui-internals:- Open the micro-ui-internals
package.json
file and add the following inside the scripts:
In the example/package.json, add the following line:
In the web/package.json, add the following line:
Screenshots of employee and citizen modules
This page outlines the steps to set up the UI development environment locally.
Before setting up: Install the tools listed below before development. Make sure the specific versions are installed. In case no version in listed, install the latest version.
Install Visual Studio Code. VS Code Extensions to be installed from the marketplace:
Install NodeJS 14.20.0
version 1.22.19
Install Python version 2.7
Clone the repository locally from your organization's umbrella. This contains the frontend code under the frontend folder.
To learn how to install yarn on Linux, follow .
This guide provides a step-by-step approach to creating an employee module screen with essential functionality. Learn how to set up the module, create a sample card, and integrate links for individual search and create pages. Following these steps ensures modularity and reusability in your code, making it easier to manage and scale.
Create a Sample card within the Sample module. This card will display links to pages within the module, such as Individual Create and Individual Search.
Create a SampleCard.js file under the following path:
Register the SampleCard
inside the Module.js
file.
Hurray! Now you can see the Sample Card with 2 links on the screen as visible in the below screenshot:
Nothing is rendered when clicking on the label. We need to set up the routes to fix this.
Approach to render Inbox and Search screen content based on config passed via MDMS data.
The is an event-based service designed to:
Fetch pre-aggregated data of municipal services and workflows.
Perform complex search operations.
Return applications and workflow data in a paginated manner.
Provide the total count of entries matching the search criteria.
This page outlines the following:
Rendering the Inbox or Search screen based on configurations.
Dynamically calling APIs using details provided in configurations.
InboxSearchComposer is a container component for the inbox and search screens. It consists of four child components, which can be rendered conditionally.
Prop Name | Description |
---|
The InboxSearchLinks component is used to render titles and links in the inbox.
The SearchComponent is used to render search or filter forms. It includes 'clear' and 'search' buttons for user interaction.
The Results table component is used to render a table with searched results.
The RenderFormFields component is used to render form fields specified in the 'fields' parameter of the configuration.
To fetch inbox details, the useCustomAPIHook
is utilized. This hook takes all necessary API details such as URL, query parameters, body, and config from the configuration (defined in MDMS).
Create config based on the sections to be displayed on the screen. The basic structure for the Inbox and Search screens is given below.
Based on the flag given for each section its visibility is controlled. If the ‘show’ flag is true, then the section is visible, else it is hidden.
Add API details in the top section, this API will be called via useCustomAPIHook and return the data. This consists of the below details.
Add search form config which can be used in both inbox/search screen. It consists of UIconfig containing label info, styling info, default form values, and fields which need to be rendered in the form. Refer below
Add Links config consists of link info, logo to be shown and title. Refer below
Add Filter form config which is similar to the search form. Refer below
Add Table (Search result) config consists of labels, column data and related jsonpaths to access the data passed. Refer below
To add any customisations on query params, request body, table columns or to add any custom validations in forms, related code can be added in the UICustomisations file as below
Once the above config is defined, created an index file/ Component in the pages folder. Fetch the config from MDMS and pass it to the inboxSearchComposer component as below
This approach is followed only in Inbox and Search screens currently.
Only one API can be called dynamically based on given configurations.
To use the latest Inbox search composer it has to be imported from the React components or Utilities
React components
package
Utilities:
package
The next step is to register SampleModule
in module.js
, the module's entry file. To demonstrate rendering, display "Sample Module" using a simple <div>
element within the SampleModule
component. This creates a basic screen setup for the module, which can be customized or expanded as needed.
Add the below code in the Module.js file which is already created.
Initialize the module's custom hooks, configurations, and register components using initSampleComponents()
here.
If there is a local server running, make sure to stop it. Restart by running yarn install
followed by yarn start
at the micro-ui-internals
level.
Hurray! Now, the screen is displayed below on visiting the given URL:
Refer to the below sections for a deeper understanding
Customisation options for DIGIT UI
This document provides the customisation details for DIGIT UI. Customisation can be classified broadly into two types -
Overriding the Component/Hooks/CSS
Overwriting the required changes directly into the Micro-ui-internals
Overriding involves making all customization changes exclusively within the micro-ui/web directory.
Within the custom CSS module, define customized CSS using the same class name or ID. Afterward, publish the changes. Ensure to reference this custom CSS file in the index.html to reflect the modifications on the website.
For overriding any components, re-register the same component in the same name in the customization folder. The latest changes are reflected.
Overwriting involves directly modifying the micro-ui-internals directory. This is slightly more challenging method to incorporate changes. Make sure the docker file is updated as per the code below and includes the install-deps.sh script.
The workspace in the web/package.json should be updated as below:
A new component called KibanaCard.js
has been introduced to render Kibana DSS based on the configuration provided in dashboardConfig
. This document outlines the steps to integrate the Kibana Dashboard with the DSS module.
In the dashboardConfig
, a new configuration has been added to render Kibana DSS. The configuration includes details that specify which Kibana dashboards to render.
So here moduleName refers to the module name in uiConstants master and pageName refers to the iframe routes route information.
Based on the configuration, we render the KibanaCard
component, passing moduleName
and pageName
as props.
Within KibanaCard
, we utilize the IFrameInterface
component. This component receives the following props passed from KibanaCard.
We can define kibana dashboard URL in common-masters in uiCommonConstants.json config. Below are the examples of the structure
This component calls MDMS-V2
common-masters to fetch the URL of the Kibana dashboard and render it using an iframe.
Additionally, if a date range filter is set by the user, we update the Kibana URL to reflect this. The following logic is applied to construct the contextPath
:
API to fetch common constants
Payload:
Response:
This page explores the steps to publish CSS if there are any CSS Customization/changes. While customising, if any changes are made In the CSS folder it has to be compiled and published to npm.
Currently, the CSS is published in npm as @egovernments/digit-ui-css
Refer to the NPM link here - .
So any changes to the CSS folder locally must be published in different organisations and in the same or different package name. For example - @xyz/digit-ui-css and version 1.0.0 then the following changes have to be made in the code to reflect in the digit-ui
- file location
frontend/micro-ui/web/public/index.html
The style sheet link must be updated as follows,
<link rel="stylesheet" href="https://unpkg.com/@xyz/digit-ui-css@1.0.0/dist/index.css"/>
Use either of the following commands to publish the CSS
In the frontend/micro-ui/web/micro-ui-internals
folder run yarn run publish:css
or
In the frontend/micro-ui/web/micro-ui-internals/packages/css
folder run yarn run publish --access public
There are two ways to customize the CSS -
Override the required CSS only without changing in the CSS folder and making changes only in the custom CSS folder. Both CSS will be present in the index.html the order of the package mentioned in the HTML determines which CSS needs to be taken ie the box mentioned in the last will have more precedence. example of overriding CSS as follow -
Overwrite the complete existing CSS.
Note: If there is overwriting of the complete CSS, future upgrades will need manual work to take the upgrade/difference changes.
Reference doc for publishing any package to npm -
This page provides details about how the Banner image and Citizen Services Card are rendered.
The link to banner images and the labels and links of citizen services on the citizen services card are defined in the below MDMS file.
For mobile and desktop we have different banner images link. We can change the images link on the below object
Here we have two objects citizenServicesCard
and informationAndUpdatesCard
. Both of them have sideOption
object which is a link to View All page.
props
object contains the objects that we want to show on these two cards.
Change the label of the cards and add the navigation URL for each prop. Click on the card redirects users to the respective screen.
Similar to Banner image, for WhatsApp Banner Image, we have two objects for mobile and desktop view. On click of the image it will redirect to WhatsApp bot. The redirection URL is defined in the navigation URL param.
Multiple options can be selected.
Details about how the module cards are rendered in the Citizen Home screen and how to add a new Card.
All the modules that are enabled are defined in this file
Now initData.modules will be containing an array of modules containing the following details about each module. Example object is shown here as PT module:
This array is further passed down to the CitizenHome component present in the file
This component will render a CitizenHomeCard component for every module that is present in the passed-down array of modules according to some conditions that are explained below.
As you can see in the home screen of Citizen, every module card has some links for it. Details of those links is stored in MDMS so that it becomes configurable. In the UI those details are fetched and accordingly module cards are rendered with the information fetched from the MDMS.
url → every link in the citizen side has this property set to “digit-ui-card”. It is used to filter all the links that belong to Citizen side
parentModule → describes to which module this link belongs
navigationURL → describes the destination url
In the UI this above mentioned data is fetched using this hook which calls this API egov-mdms-service/v1/_search
.
After some processing in the UI this linkData will be an array in which every key will be module name and its value would be an object containing the links array and iconName and module Header, it will look like this:
Using this data every card along with it’s icon, header and links will be rendered in Citizen Home.
Icon Configuration / Naming Convention
Now that we are aware of how the module cards are rendered with their respective data , let’s discuss how to add a new module Card.
To add a new module card , we need to add the name of the module in the list of enabled modules. The details of this module will be fetched using this same hook as explained above:
const { isLoading, data: initData } = Digit.Hooks.useInitStore(stateCode, enabledModules);
Sample actions-test and roleactions object
Sample actions-test object
Sample roleactions Object
Multiple options can be selected.
DIGIT comes with common re-usable libraries that can be imported for use in a new module. Follow the steps below to import the required components.
We are reusing certain React components from our libraries, such as InboxSearchComposer
, FormComposerV2
, SubmitCard
, CardText
, and others. Refer to the link below to learn more about these components.
All components are available in the link below.
Steps to build a citizen portal for a module
This section of the guide enables developers to create their front-end citizen module from scratch which they can deploy on top of DIGIT UI. The new module will be visible as a "card" in the DIGIT citizen portal.
Steps to build the citizen portal for a module
This guide provides examples and illustrations on how to set up and integrate the most commonly used DIGIT UI libraries.
The sample screens are available .
Configuration of privacy policy component on the login screen
A new feature, the Privacy Component, has been added to the login screen to enhance user transparency. This component displays privacy policy information based on the login configuration. Follow the steps below to configure this component on the login screen.
To render the Privacy Component, you must include specific configurations in the MDMS :
Master Name: commonUiConfig
Module Name: LoginConfig
If these configurations are not present, the configuration will be rendered instead.
The content displayed within the Privacy Component's pop-up will be filtered according to the module code
specified in the schema.
The fields on the login screen are fully configurable. Users can add or remove fields according to their specific requirements.
To ensure all mandatory fields are completed, the login button will be disabled until all required fields are filled. This ensures that users provide all necessary information before proceeding.
Here are some examples of different configurations for the login screen and their corresponding displays:
These configs will help to enable/disable the privacy declaration, at an instance level.
Screen:
Config:
Screen:
Config:
Localisation modules used:
Monitor and trace user activity
To monitor and trace user activity on the client side, we need to enable telemetry in the local or development environment.
Whichever environment file has been used to deploy DIGIT, please make sure the above code blocks are added to the file. Dev has been used here as an example. This can differ based on the environment.
Redeploy the citizen, employee, and digit-ui modules using Helm. For example, to redeploy the citizen module, identify the docker image ID from the product release charts.
/DIGIT-DevOps/config-as-code/product-release-charts/DIGIT/dependancy_chart-digit-<version>.yaml
If you have deployed DIGIT v2.6, use the 2.6 release chart. If 2.7, use the 2.7 release chart. Search for the docker image ID of the citizen, employee and digit-UI modules and copy those.
Then, run the following commands to redeploy the citizen module with the updated variables in the environment file. This will replace the new values during deployment and configure it appropriately:
Repeat this exercise for the employee module. Redeploy the digit-ui module based on the instructions . Once the deployment is successful, we can track it into the Network tab by filter telemetry.
All content on this website by is licensed under a .
Steps to integrate external UI with DIGIT UI
This document provides the steps on how to integrate another UI into the DIGIT UI using iframe.
Enable the module.
Once the Utilities module is enabled, add the following changes to the master (file path given below).
Master details: data/pg/commonmasters/uiCommonConstants.json
Here -
shg is the path name to access inside digit-ui;
home is the route to access it;
whatever is mentioned inside routePath should be the Application/Pod name that is expected to be shown inside the digit-ui;
Once the MDMS changes are applied, access the new application using the following route - <SERVER_URL>/digit-ui/employee/utilities/iframe/<PATH_NAME>/<ROUTE_NAME>
Examples: New Web Application (UI - any framework)
DIGIT UI
This page provides the steps to resolve issues using the network tab on the browser.
While using the application or while performing some action if something fails we get generic error messages on the UI.
Such as - Something went wrong / Please try again or contact support.
Despite trying again, the same error message pops back up. What else could go wrong? The Network tab enables us to see more information about the Error.
To fetch more information in context to the error message -
Inspect the Page - On the page with the error message, right-click the page and choose Inspect in the dropdown menu.
Select the Network Tab - The browser’s network tab is a way to look directly at what’s happening behind the scenes of a page. It shows us not only the type of data being requested and passed as we interact with the page, but it also let's know if there are any actions that are failing. After selecting Inspect, a new window will appear. In this new window, click the Network tab. Then, select the XHR filter option. This will hide everything except API requests.
Refresh the Page - Click the Refresh button in your browser. Since the Network tab will only show us the requests that occur after the tab has been opened, we’ll need to refresh the page so that we can view the error as it occurs. As the page reloads, you’ll see various API requests populate the panel.
Re-create the Error - In order to understand what’s causing our error, we’ll first need to go through the same steps we took to get the error so that we can watch the request happen in real-time. In this case, to recreate the error we’ll click Update again. By re-creating the error, we’ll see exactly which request is causing the issue.
Find the Red-Line Item in the Network Panel - This is the error that occurs when clicking Update. The status is 400, which is the error code for “bad request.” Everything else has the status 200, which is the code for “OK,” meaning nothing went wrong for those other requests.
Preview the Error Details - Click the red-line item to see the error details. Clicking that line item will open a new frame on the right-hand side, and in this frame, you’ll see a few tabs: Headers, Preview, Response, Cookies, and Timing. In this case, stick with Preview since this contains the basic information.
View the Error Message - While in some cases you won’t see a specific message here, in this case, you’ll see the following:
Thanks to the network panel, you were able to take a look under the hood, diagnose the issue, and put a fix in place.
Steps to debug
This page provides the steps to debug the android application using a chrome browser.
Connect your android device to the system.
Go to developer mode in the mobile device and enable USB debugging.
Open the Chrome browser and navigate to the URL chrome://inspect
The browser shows the list of devices connected to the system.
Select the mSeva application and click on inspect.
This opens a new window. Here we can see the mobile preview and the developer tool.
Start debugging the application as we have done in normal web applications.
This utility is designed to transform the MDMS configuration into FormComposer and InboxFormComposer configurations. Typically, every UI configuration relies on certain parameters. These parameters might include dropdown dependencies or custom classes determined at runtime based on specific logic. However, since the configuration is in JSON format stored within MDMS, direct usage of variables is not feasible. To address this requirement, we've developed a utility capable of converting this JSON into a parameter-based JSON structure.
This utility serves as an engine that accepts MDMS configurations along with dependent parameters. It then processes this data to generate a parameter-enabled configuration. This resultant configuration can be utilized by FormComposer and InboxFormComposer to render the UI elements accordingly.
Below is the method used to configure the MDMS -
Pass the JSON path of the dependent key that requires runtime updates. In the example above, the target is on “populators.options”.
Update the options at runtime based on certain logic.
Note :
Make sure to pass the JSON path in an array.
The order in which these JSON path are passed is important. Later on, this order will be used to target the respective dependent object.
Once the configuration is complete, this will be added to MDMS. So, the next thing is to pass this config and its dependencies to the Pre-Process utility. The Namespace to access this utility :
The dependency Object contains multiple actions which the pre-process function runs for us.
Translate - This targets the JSON path and does translation for the passed data.
updateDependent - This targets the JSON path and update the dependencies.
convertStringToRegex - This targets the JSON path and converts the String RegEx to RegExp based Regex.
Refer to the sample example below -
In the example above, we are using the action “updatedependent” from pre-process utility.
“Key” targets the input key name. This will help preprocess to target the right input field.
“Value” - Each input within the configuration is associated with a JSON path, with each path targeting a dependent object. As previously demonstrated, we passed the JSON in a specific order within an array. Similarly, we must pass the corresponding dependent values in the same order to ensure alignment with the correct targets.
Note: Ensure that the preprocessing call is optimized for performance. It should only be invoked when there is a change in the dependent values. As our dependent values are component states, the preprocessing should occur whenever the state changes, triggering a re-render of the component. To mitigate potential over-iterations, we employ useMemo to cache the result, ensuring efficient processing and minimizing unnecessary recalculations.
A similar utility is also developed for InboxSearchComposer. Refer to this same document for both utilities.
Prior knowledge of Flutter
Prior knowledge of Dart language
Prior knowledge of State management
Prior knowledge of pub dev packages
Prior knowledge of Git
Prior knowledge of HTTP client request calls
Knowledge of the DIGIT Flutter UI framework
Check the page to access help documents on the tools required for UI development.
Label | Label for text field |
---|---|
For more information:
For more information:
Access .
To learn more about global config visit .
On the home page, users can see the cards mCollect, HRMS, NOC, Property Tax, etc These cards need to be added. Refer to the instructions on the to create an employee card.
Click on the to create a card for your module on the home page under "Citizen Services".
Refer to section to learn about globalConfig file.
Link to .
To learn more about the and process visit
Step 1: Add an entry in the helm chart of the frontend directory in the master branch of the forked repository.
Step 3: Modify the development environment as per requirements.
Mention the globalconfig file URL in your .
Main file:
Check the which contains other configs like filter, table, search, and mobile responsiveness.
The hook for the same is defined in
Use the latest (InboxV2)
Both Inbox and Search screens can be shown based on the input configurations passed to that component -
Configuration are mentioned in for local reference and it is fetched from the MDMS .
An example of a Search screen is available in .
Refer to the file here -
The next step is to initialise the Dependency, refer to learn more about the setup
Reference of using this hook on a view screen:
Refer to the file here:
A significant part of this component is another component called the . This is the popup that renders whenever the user clicks on a specific action. This popup is fully configurable through this configuration file . Popup configs are defined in this configuration file which are organised as per the businessService of the workflow configuration. Refer to the configMap object in this file for more details.
The next step is to initailise the module.js, refer to know more about the setup
Refer to the file here:
Reference for Routing and index.js file is available here:
One link is for the Create Individual screen, and the other is for the Individual Search. You can view the code for the Create screen or set up the Create page by referring to the link here -
The reference for the App.js file is available here:
Reference for the Index.js file is available here:
Prop Name | Description |
---|
Prop Name | Description |
---|
Prop Name | Description |
---|
Prop Name | Description |
---|
Refer to the file here:
Reference for the App.js file:
Reference for the Index.js file:
URL:
This array contains a list of modules that are enabled in DIGIT-UI. This array is passed down to DigitUIWrapper Component defined here: . Here this array is passed down to this hook:
This module card data is stored in this file . The format of the link data is described in such a way that every link object will have these key properties among others:
This hook call is made in this file
This rendering is done in this component using CitizenHomeCard component.
Every module icon is stored as an svg component in this file . Name of every svg component follows a common format which is the name of the module followed by Icon string. For instance, PTIcon is the icon name for PT module. This icon name details are also stored in the MDMS file, which is used to display appropriate icons on the module cards.
By doing this a new module card will be rendered but it’s header, links, and icon will not be rendered because we need to add this data in the MDMS. We need to add this data in this file as explained above and accordingly add matching ids in this file with rolecode property set to ‘CITIZEN’
Hooks We will implement custom hooks in our code to handle data transfers to the backend. These hooks will make API calls and format the responses accordingly. Refer to the link -
Refer to the file here - Once the integration is complete the data is saved into the database.
Once we enable the BR module in app.js and index.js, the module will be available in the UI. Click on to see the UI.
All content on this website by is licensed under a .
Data Customisation: The data can be modified through MDMS and localization updates. MDMS Path: to access the privacy component file.
placeholder
Placeholder for the text field
isMandatory
Whether field is mandatory or not
disable
To disable the text field (no interaction will be possible if disabled)
nonEditable
To make text field readOnly
infoMessage
Information to be shown when hovered on the info icon beside the label
description
Help text for the text field
charCount
Number of characters in the input value
withoutLabel
Default will be false, if sent as true then label won't be shown
populators
Name : Mandatory field
Error : Error message to be shown
Validations: if required like maxlength, minlength etc
customIcon: to show any icon inside the text field (can be sent as a string)
onIconSelection: IconSelection function
Prefix: To show prefix
Suffix: to show suffix
wrapLabel
Can wrap label to the next line in desktop and tablet screens
Text
Date
Time
Geolocation
Numeric
Prefix
Suffix
Password
Search
Default
Filled
Disabled
NonEditable
Focus
Error
Label
Character Count
Inner Label
Info
Help Text/ Description
Default
Filled
Disabled
NonEditable
Focus
Error
Label
Character Count
Inner Label
Info
Help Text/ Description
resizeSmart
Radio Selection
Default
Disabled
Selected
PreSelected
Toggle
Default
Disabled
Selected
PreSelected
Primary
Secondary
Teritiary
Link
Active
Disabled
Label
Interactions
Default
Nested
Tree select
Profile
Profile with nested text
Nested Text
Default
Disabled
Selected
Interactions
Default
Nested
Tree Multiselect
Nested Text Multiselect
Default
Disabled
Selected
Interactions
Default
Checked
Active
Disabled
Label
Interactions
Success
Warning
Failure
Default
Success
Warning
Error
import {FormComposerV2} from "@egovernenets/digit-ui-components-core"
selectedOptions List of DropdownItem, which will be selected by default |
headerText | Config fetched from MDMS data |
links | Links to navigate to other screens |
customClass | Class to update styling |
logoIcon | Icon name and class to render in component |
uiConfig | Config to render search/filter form |
header | Title of form |
screenType | Type of parent screen, can be either ‘inbox’ or ‘search’ |
fullConfig | Entire config of screen which also includes API details |
config | Config to render table |
data | Search results need to be populated in table |
isLoading | Flag to pass to handle loading state |
isFetching | Flag to pass to handle loading state |
fullConfig | Entire config of screen which also includes API details |
fields | Config to render all form fields |
control, formData, errors, register, setValue, getValues, setError, clearErrors | Props to handle all form actions like collectibe data, setting errors, clearing errors etc. |
apiDetails | Includes all API details required to fetch data |
Create Form Screen
Create and integrate a form within a micro-frontend architecture using the DIGIT framework.
configs | Config fetched from MDMS data |
DIGIT UI Flutter Development Guide
|
|
|
Text Date Time Geolocation Numeric Password Search TextArea | Default Filled Disabled NonEditable Focus Error Label Character Count Inner Label Info Help Text/ Description |
Radio Selection | Default Disabled Selected PreSelected |
Toggle | Default Disabled Selected PreSelected |
Primary Secondary Tertiary Link | Active Disabled Label Interactions |
Single Select Multi Select Sub type: Default Nested Tree | Default Disabled Selected Interactions |
Default Checked | Active Disabled Label Interactions |
Success Warning Failure |
Default Success Warning Error |
4) How to Register New Module in Digit UI? Creating config into mdms:-
If you are creating a new module then, first we need to enable that module as true in citymodule.json and update the Module in citymodule.json.
Suppose your module name is BR(Birth-Registration) then change the module and code as BR. and update the citymodule.json file. or
Install Dependency 5) In Digit UI Where do we need to add the .env file? Add the .env file in the example folder -
If the User is a citizen then we will configure the .env file as follow:-
If the User is an Employee then we configure the .env as follows:-
6) In Digit UI Where do we need to add the .env file when we run the react app from micro-ui/web?
Add the .env file in the micro-ui/web/src/
Overview of Flutter and its key features
Flutter is an open-source UI framework developed by Google for building natively compiled applications for mobile, web, and desktop platforms using a single codebase. It provides a fast and efficient way to create visually appealing and high-performance applications with a consistent user experience across different platforms.
At the core of Flutter's architecture is the Flutter engine, which is written in C++ and provides low-level rendering capabilities. The engine interfaces with the host operating system and handles tasks such as layout, drawing, and gesture recognition.
On top of the engine, Flutter provides a comprehensive UI toolkit that consists of widgets. Widgets are the building blocks of Flutter applications and represent different elements of the user interface.
Flutter's reactive framework allows widgets to rebuild efficiently when there are changes
Watch the video here to understand Flutter Architecture -
This document will help us generate the APK for Citizen and Employee applications.
Android offers a variety of ways to present content to a user. To provide a user experience that’s consistent with the rest of the platform, it’s usually best to build a native app that incorporates framework-provided experiences, such as Android App Links or Search. Additionally, you can use Google Play-based experiences, such as App Actions and Slices, where Google Play services are available. Some apps, however, may need increased control over the UI. In this case, a WebView
is a good option for displaying trusted first-party content.
In Egov we create only responsive web apps instead of native apps (Android, IOS). The Android web view is used to render the out web application.
Open the below location in the Android studio.
Generate APK for citizen application
Go to build. Gradle file there we have created multiple environments(UAT and PROD), please select the environment where you want to generate APK and put your web application URL.
Update the web application URL as required Application URL.
buildConfigField 'String', 'url', '"https://uat.digit.org/citizen/user/register"'
also, specify the citizen gateway hostname if not using Mastercard,
buildConfigField 'String', 'gatewayHost', '"migs.mastercard.co.in"'
3. Save the file on the left side of the Android studio. Click Build Variants and select the applicable build variant.
4. Click on Build menu, select Build APK(s) submenu.
It will take some time to generate and it will show generated location.
Generating APK for employee application
1. Go to build. Gradle file there we have created multiple environments (UAT and PROD), please select the environment where you want to generate APK and put your web application URL.
2. Save the file, left side of the android studio click Build variants, and select build variant.
3. Click on the build menu, and select Build APK(s) submenu.
It will take some time to generate and it will show generated location.
Follow the 3rd and 4th steps mentioned above.
Click on the Build menu and select Generate Signed Bundle / APK.
Select 1st radio button - Android App Bundle.
Enter the information presented in the form and click on Next.
Upload the APK generated by the 4th step and upload it to the play store.
__All content on this website by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.