1 of 100

Platform

Release Notes

New release features, enhancements, and fixes

Release Summary

DIGIT 2.8 release includes 1 new module, several new products, functional and security features, regression testing, bug fixes of previously released modules and a few non-functional changes.

New Module

Citizen engagement - Survey service

Functional Changes

OBPS Tabular Reports in old UI/UX, Trade Licence Tabular Reports in old UI/UX
Notification based on channels - PGR, OBPS & mCollect
Help/FAQ section in Citizen UI - common framework - integration with all the modules
Bill Genie UI/UX revamp
Survey module
Water & Sewerage UI/UX Revamp, Bill amendment workflow update & UI/UX revamp, W&S disconnection
Water & Sewerage Privacy Exemplar, Standard Reports for W&S - Receipt Register, Collection Register, Defaulters Report - in old UI/UX
Birth & Death Tabular Reports - in old UI/UX
Enhancement on DSS, Finance Module State DSS, NSS Adaptor, Enhancements in National Dashboard- FAQ & About page.

Non-functional Changes

Navigation re-direction from New UI to OLD UI
Bulk Bill PDF generation and performance testing
W&S Bulk Bill generation and performance testing

New ‌Feature Additions

Enhancements

Success Metrics

https://docs.google.com/document/d/1b4plZ0TFMJC53MDt72_sx-Wif2bdR4I5dnD9DTN40Ss/edit

Adoption Metrics

Adoption of new features will be tracked on the basis of the following metrics:

‌Document Resources and Links

UI Technical Documents

Updated docs

Trade License - Apply Flow
New Trade License Application

Backend Service Documents

Master Migration Document

2.8 release master migration document

Bill Amendment (Billing-service)

W&S Bill Amendment workflow config migration

Follow the steps mentioned in the W&S Bill Amendment Workflow config migration document.
Verify once if workflow name is hardcoded except edited parts of UI, Backend - check in indices and report - checked not present except config
Verify if wf config is there for tenant level or state level only
An update has to be added as a patch to the first release of the amendment

Water & Sewerage

Latest persister file - Water
Latest persister file - Sewerage

Note : Replace the existing persister files with the latest files linked above.

Water modify connection
- Workflow config
Sewerage modify connection
- Workflow config
Sewerage Disconnection
- Workflow config
Water Disconnection
- Workflow config

Privacy Feature

By default encryption & privacy is disabled for 2.8

To disable privacy for Property and W&S make changes in the MDMS- DataSecurity -> SecurityPolicy.json file.
For models- Property,PropertyDecrypDisabled, WnSConnection, WnSConnectionOwner, WnSConnectionDecrypDisabled, WnSConnectionOwnerDecrypDisabled, WnSConnectionPlumber, WnSConnectionPlumberDecrypDisabled; insert only one attribute in the attributeList as follows:

 {
         "name": "sample",
         "jsonPath": "sample",
         "patternId": null,
         "defaultVisibility": "PLAIN"
    }

Insert the name and jsonPath which are not actually expected to be present in the RequestBody/ResponseBody
Files to be updated
1. Security policy complete file
2. Masking patterns - needed only if enc is enabled and carried our for old data.
References for reading
Once the above changes are done deploy the following builds:
1. Ws-services
2. Property-services
3. Sw-services
4. Inbox
5. Restart egov-user service
Impact of privacy framework
1. The privacy implementation masks the PII information based on the MDMS config (Security Policy)
2. The masking/unmasking of data is entirely dependent on the roles of the users in the system, adding or removing these roles from the config will enable masking for each role.
3. There is no module-level control here, so if a W&S role is added to an employee of TL then data will be masked so cross-using of roles should be avoided.
4. The agreement with Manish is that the privacy be disabled until redesign with the module filter - Done
5. The policy should be defined for adding or removing fields from the encryption process.
W&S privacy (Skip over if encryption is not carried out)
1. Deploy the latest builds provided for the 2.8 release {builds}
2. Add privacy configs to MDMS (SecurityPolicy.json)
3. Restart the MDMS service followed by the encryption service
4. Add the temporary index config update index with encrypted data
  - This file will fetch data from the Encryption of old data and upload it to the existing index so that the index will be encrypted or masked as per config.
5. Trigger the encryption of old data through the provided APIs
6. Validating the encryption of old data {Doc Link}
7. Disable & enable decryption.privacy
  - water.decryption.abac.enabled=true
  - sewerage.decryption.abac.enabled=true
PT privacy (Skip over if encryption is not carried out)
1. Deploy the latest builds provided for the 2.8 release
2. Add privacy configs to MDMS (SecurityPolicy.json)
3. Restart the MDMS service followed by the encryption service
4. Add the temporary index config update index with encrypted data
5. Add the new index config for the fuzzy search index
6. Trigger the encryption of old data through the provided APIs
7. Validating the encryption of old data {Doc Link}
8. Disable & enable decryptionprivacy
  - property-decryption-abac-enabled: "true"
Bill genie
1. No changes required
Bulk Bill PDF Generation and Performance Testing
1. Enhancement is part of the new build release.
W&S Bulk Bill Generation and Performance Testing
1. PR List
privacy integration - PT
1. Covered as part of privacy above
Notification based on channels - PGR
1. Localisation added as part of the release KIT
Notification based on channels - mCollect
1. Localisation added as part of the release KIT
OBPS/ BPA (Notifications only)
1. Localisation added as part of the release KIT
National Dashboard Adaptor Integration Testing
1. The Docs are specific to Punjab implementation, generic product document is in the pipeline.
NationalDashBoard 3 New KPI
1. CharApiConfig.json
2. MasterDashboardConfig.json
  - Overview Card config
  - Property Tax config
3. DevOps change
Finance Module State DSS
1. Dss Chart API config
MDMS & Configs -

BackWard Compatibility Results -

Folder Link

UI Changes

Please add all MDMS changes before deploying the UI code.

W&S: W&S UI/UX Revamp
- No changes are needed, it will work automatically if we deploy. There are two enhancements in the W&S flow, i.e Edit by normal user and Edit by config user, it is based on the MDMS configuration (Link). This is applicable in all 3 flows.
W&S disconnection
- No changes needed, it will work automatically if we deploy.
Bill amendment W&S UI/UX RevampI
- No changes needed, it will work automatically if we deploy.
Bill Genie UI/UX revamp
- No changes needed, it will work automatically if we deploy.
OBPS Tabular Reports in old
- No changes needed, it will work automatically if we deploy. It is based on the configuration of the backend.
TL Tabular Reports
- No changes are needed, it will work automatically if we deploy. It is based on the configuration of the backend.
Standard Reports for WnS
- No changes are needed, it will work automatically if we deploy. It is based on the configuration of the backend.
Core UI Changes (Banner Images of Each module)
- No changes are needed, it will work automatically if we deploy. It is based on the configuration of the MDMS (Link)
- We need to add the below images in the S3 bucket:PGR: https://egov-uat-assets.s3.amazonaws.com/PGR.png
- PT: https://egov-uat-assets.s3.amazonaws.com/PT.png
- TL: https://egov-uat-assets.s3.amazonaws.com/TL.png
- OBPS: https://egov-uat-assets.s3.amazonaws.com/OBPS.png
- FSM: https://egov-uat-assets.s3.amazonaws.com/FSM.png
- WS: https://egov-uat-assets.s3.amazonaws.com/WS.png
- Bills: https://egov-uat-assets.s3.amazonaws.com/Bill.png
Navigation re-direction from New UI to OLD UII. Mdms Changes are required for this (Link).

Old UI

Only Fire Noc and Tabular reports are PO signed off in the current release for the OLD UI, the rest of the modules are covered as part of backward compatibility tests shared above.

MDMS Configuration & Service Build Updates

Configuration changes and service build details

MDMS Changes

Config Changes

Service Build Updates

Test Cases

Water & Sewerage - Privacy Exemplar

Survey Test Cases

New UI to Old UI

Birth & Death Reports

Help FAQ Section in Citizen UI - Common Framework (Product-Specific Pages)

PGR Notifications

W&S UX/UI Revamp

Bill Amendment For W&S

W&S Reports

Bill Genie

TL Reports

Finance DSS

BPA

DSS Test Case For 3 KPIs

OBPS Reports

Gate 2 Release Checklist

Implementation Checklist

Program Roll Out Plan

DIGIT 2.8 release has a new module, new features, bug fixes and a few non-functional changes.

Account Wise Feature Demand

Punjab W&S is using the old UI. So W&S new features, which are using new UI, cannot be used in Punjab

NUDM Roll Out

The following features are part of the UPYOG Product Roadmap and will be released as part of UPYOG 2.0 by end of March 2023.

*As per current demand from NUDM-enabled states

Adoption Metrics

Adoption of new features will be tracked on the basis of the following metrics:

Product Release Notes

Property Tax Release Notes

Overview

This release provides PRDs of 3 property tax features and a few bug fixes.

Release Highlights

PRDs of 3 property tax features and bug fixes.

Properties amalgamation
Property bifurcation
Capital value system
Property mutation bug fixes.

Release Features

None

Known Issues

Bug

Upcoming Release Features

None

Reference Doc Links

Online Building Permission System UI/UX Revamp Release Notes

OBPS Release notes for Urban DIGIT 2.8 release.

Overview

This release provides the UI/UX revamp of OBPS , workflow timeline changes and reports.

Release Highlights

The functionality in OBPS remains the same - only the UI/UX has changed.

Two reports added for administrative purposes.

Changes made to the workflow timeline for clear representation of application status to the users.

Notiification based on channels.

Release Features

Stakeholder registration and employee approval flow
Architect flow (permit application creation) and employee approval flow
Architect occupancy certificate creation and employee approval flow
Fire NOC employee approval flow
Open link for stakeholder registration flow
Daily collection report

OBPS application status report

Workflow timeline changes in application flow - The image below the one illustration on the right displays the old status view. Here the application status shows pending even if the task is completed. As per the current release, the application displays only the current state where action is marked as pending. The remaining status is marked as done or completed or in submitted state.

Notification based on channels - The OBPS application allows the user to configure different messages for different channels (In app, mobile messages, email) for the same event in the application process flow.

Known Issues

Upcoming Release Features

None

Reference Doc Links

Trade Licence Reports Release Notes

Trade License release notes for Urban DIGIT 2.8 release.

Overview

Few reports are added to the TL module for administrative purposes.

Release Highlights

TL Daily collection report

TL Application status report

Trade license registry

Trade license renewal pending report

Release Features

TL Daily collection report

TL Application status report

Trade license registry

Trade license renewal pending report

Known Issues

Upcoming Release Features

None

Water & Sewerage UI/UX Revamp Release Notes

Overview

This release provides UI/UX revamp of existing features of water and sewerage modules in addition to applying for disconnection, data privacy, and 3 standard reports.

Release Highlights

UI/UX revamp of water and sewerage covers the features given below.

Citizen

My Connections
My Applications
My Payments
My Bills
Search and Pay
Apply for a new connection
Apply for disconnection
View Connection Details
View Consumption Details
View Application Details
Pay Water and Sewerage Bill
Pay Application Fee

Employee

Water Inbox
Sewerage Inbox
Apply for a new connection
Modification of connection
Bill Amendment
Application Workflows
Search Connection
Search Application
View Connection Details
View Consumption Details
Add Meter Reading
View Application Details
Collect Application Fee
Collect Water and Sewerage Bill

Downloads/ PDFs

Connection Details
Application Acknowledgement/ From
Estimation Notice
Sanction Letter

New Features Added

Disconnection of water and sewerage connection.
Disconnection Notice PDF
Application acknowledgement/form PDF

Reports

Receipt Register
Collection Register
Defaulters Report

Data Privacy

Masking of PII data
Option to unmask the PII data
Audit trail of the unmasking of PII data

Release Features

Known Issues

Upcoming Release Features

None

Reference Doc Links

Bill Amendment UI/UX Revamp Release Notes

Overview

UI/ UX revamp of Bill Amendment.

Release Highlights

UI/UX revamp of Bill Amendment Inbox and Application View.

Release Features

Key Features

Description

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

Bill Genie UI/UX Revamp Release Notes

Overview

UI/ UX revamp of Bill Genie.

Release Highlights

UI/UX revamp of Bill Genie features.

Release Features

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

Birth & Death Reports Release Notes

Birth and death release note for Urban DIGIT 2.8.

Overview

Reports have been added to birth and death for administrative purposes.

Release Highlights

Birth count report

Death count report

Birth and death certificate payment records

Release Features

Birth count report

Death count report

Birth and death certificate payment report

Known Issues

Upcoming Release Features

None

National Dashboard Enhancement Release Notes

DSS release note for Urban DIGIT 2.8

Overview

About page, FAQ and 3 new KPIs are added to the DSS page

Release Highlights

About page for the dashboard is added which helps users to understand the purpose, how data is secure and from where the data is being pushed.

And 3 new KPIs were added for administrative purposes.

Release Features

About page

FAQ

3 KPIS - Non-tax revenue collected, Non-tax revenue contribution % and Average PT collected.

Survey Release Notes

Overview

This module allows employees to create surveys for citizens and let them fill out surveys. Later survey results can also be seen on the Survey results dashboard.

Release Highlights

The Survey module consists of the following

For Employees

Surveys section on Home Page
Surveys inbox
Create survey
- Meta Data - Title, Description, Survey start & end date/time
- Questions
  - Short Answer
  - Paragraph
  - Single Answer
  - Multiple choice questions
  - Date
  - Time
Survey Results
- Aggregated view of all survey results in specific charts for each question type
- Download the excel report with the survey results
Modify surveys
- Survey questions
- Extend the Survey date and time.

For Citizens

Notification on Survey creation.
Survey Filling

Known Issues/ Upcoming Enhancements

Expansion to other types of questions
More notifications to citizens prior to survey start, and survey end.
Making surveys open. (Right now citizens need to be logged in to fill out the survey. This needs to be made open)

Mockups

Product Specific Pages Release Notes

Overview

This module gives citizens more information on a service delivery module than just links to access the service.

Release Highlights

Product Specific Pages Module consists of the following:

For Citizen

For a module and tenant that is configured.

FAQs
- List of FAQs for each module
How it works
- List of user manuals, help videos etc (Also in local language)
Link to access service via WhatsApp
Helpline Numbers
Address of Service Centres
- Link to navigate to google maps
Static data
- Ex. Days to process applications/ Amount to pay while applying etc
Dynamic Data
- Number of citizens applied for service in last n months/ Amount collected etc

Known Issues/ Upcoming Features

https://digit-discuss.atlassian.net/browse/UM-5628 https://digit-discuss.atlassian.net/browse/UM-5721 https://digit-discuss.atlassian.net/browse/UM-5640 https://digit-discuss.atlassian.net/browse/UM-5725

Mockups

Platform Features

DIGIT is an open-source platform licensed under the MIT license () compliant with the NUIS digital blueprint.

Detailed mapping of DIGIT’s capabilities with the core requirements mentioned in the NUIS digital blueprint has been done below:

Key Principles

Description

Interoperability

Data specifications/models are available for domain entities. DIGIT is designed as an API-first platform wherein data specs/models are created for all key entities thus ensuring interoperability through open APIs and open standards. Taxonomies are available for the key domain entities/registries. These can later be harmonised with standard taxonomies in the domain as and when they are made available.

DIGIT data models and APIs are published as Open APIs freely available to everyone in the ecosystem. In Punjab, the DIGIT module was easily integrated with 3rd party payment apps like Paytm, Airtel Money, BBPS, etc to increase citizen access and improve collections. At present, DIGIT provides at least 3 key distinct APIs for all domain entities - create, update and search.

Deactivation/Cancellation of key entities in DIGIT is achieved by updating their status to inactive as per their defined specification/API contracts. Given the API-first and micro-services-driven nature of DIGIT, current APIs and models can be quickly harmonised with national standards as and when they are made available. DIGIT strives to leverage established domain standards (national/international) wherever available.

Data Privacy And Security By Design

Data Privacy

Data privacy capabilities are available to mark and protect sensitive data. The core service layer of DIGIT includes signing and encryption service as one of the core services that provide capabilities to sign/encrypt/mask sensitive data. It is designed such that it can work against software key stores and can be extended to integrate with any kind of hardware key store to store and protect signing and encryption keys.

Encryption requirements can be defined and adhered to for the storage of sensitive data. DIGIT requires the User PII data to be stored in its User service which is by default enabled for encryption of sensitive data as User Data Vault. All other services in DIGIT are required to access PII data by explicitly calling the User service - which in turn audits all access to PII. In addition, individual services in DIGIT can leverage DIGIT’s signing and encryption service (which is what User Service leverages to create User Data Vault) to further protect additional sensitive data available with the services.

DIGIT provides the capability to define workflows for data modification that can be configured to have approval steps to get needed consent for any data modification activities. DIGIT currently provides RBAC (Role-Based Access Control) based access control for access (search) to data.

Security

Appropriate access controls can be defined in the APIs to ensure authorised access to sensitive data. DIGIT is designed to handle authentication and authorisation as perimeter control at its API gateway layer to ensure unauthorised calls are not allowed to even contact the respective micro-services. DIGIT provides an RBAC (Role-Based Access Control) mechanism where users are explicitly provided access to relevant resources by assigning them appropriate roles. By default, DIGIT supports OAUTH-based authentication for individual users and APIs. However, the Authentication and Authorization filter on DIGIT is designed to be easily extendable to support any further Auth and Auth needs.

The perimeter security mechanism in DIGIT also helps developers in focusing on the functional developments in further services and offload the access control requirements for new resources and their APIs to the API gateway using simple configurations.

DIGIT also ensures that risks like the following are taken care of:

Privilege escalation – form field manipulation
Failure to restrict URL access
Insecure direct object references (IDOR)
Malicious file upload leads to cross-site scripting
Improper authentication
Missing account lockout
Request throttling attack
Weak encoding mechanism
Sensitive information in URL
Lack of automatic session expiration
Insecure banner implementation
Concurrent session
Clickjacking
Improper error handling

Transparency And Accountability Through Data

DIGIT has the capability to define key registries in OpenAPI 3.0 specs formats and easily achieve key APIs like create/update/search using its building blocks in core services mainly through configurations and using lightweight extensions on a needs basis.

DIGIT has the capability to protect person-specific sensitive data by encrypting them in the user data vault (User Registry) which allows configuration-based protection of sensitive PII. DIGIT requires additional registries to reference PII using this mechanism. In addition, registries in DIGIT can leverage its data protection (Signing and Encryption) core service to provide additional protection to registry-specific attributes.

Registry data in DIGIT can be signed for tamper-proofing using its signing and encryption core service. A proof of concept for this has already been done on the ePass module that was built on the DIGT platform. All key data modifications in DIGIT are access logged to provide an audit trail, which can be accessed through APIs. The upcoming version of DIGIT is planning to bring in the concept of immutable event logs to further strengthen this capability. DIGIT leverages open-source telemetry to provide the ability to gather telemetry data and extend it for the DIGIT-specific processing pipeline. This framework allows for additional event definitions and contextual extension of the telemetry processing pipeline thereby future-proofing this capability in DIGIT.

Reusability and Extensibility

DIGIT platform is designed as a collection of more than 50+ atomic microservices which are bundled together in a given context to provide end solutions. Microservices in DIGIT can be mainly categorized in three categories: Data services (Registries, reference Master data management, etc.), Tech infrastructure services (Authentication, authorisation, notification engine etc.) and domain services (Assessment, NOC etc.). Citizen, employee and administrative interfaces in DIGIT use these microservices to achieve the needed functionality.

Data models and APIs in DIGIT are defined as OpenAPI 3.0 specifications and can be extended by using a combination of configuration and extension techniques. E.g. if the additional attributes are only needed to be stored with format validation, it can be a simple schema extension, while if the additional business checks/functionality need to be implemented using the extended attributes then it can be achieved using pre/post request filters or extending underlying microservices.

DIGIT allows the extension of existing capabilities without needing architectural interventions. As described above extension of existing functionality on DIGIT can be achieved using additional configurations, additional extension services or request/response filters.

Several partners have extended DIGIT modules to cater to new use cases. For instance, DIGIT mCollect module caters to the collection of fees for more than 50 services on the counter, but it did not have a citizen interface for payment of these services online. Directorate General Defence Estates (DGDE) wanted to introduce this interface for the citizens of cantonment boards in India and were able to easily enhance the mCollect module to include this capability. Similarly, Punjab has reused several DIGIT core services to develop new modules on the platform with minimum effort.

DIGIT supports single-instance multi-tenancy to enable sharing of the underlying infrastructure, also all DIGIT data models and services are designed to be multi-tenanted.

DIGIT uses API first approach in its design and development to ensure loose coupling between its various components. These APIs are clearly defined using OpenAPI 3.0 specifications to ensure clear documentation.

Evolvability and Scale

As described above, the extension of existing functionality on DIGIT can be achieved using additional configurations, additional extension services or request/response filters. Similarly, new functionality can be added by re-bundling existing building blocks in the context of new use cases and implementing only additionally required services without requiring any architectural overhaul. Additionally due to its loosely coupled API-driven design DIGIT allows for new components to be implemented in the technology that is most useful for that use case.

API-driven, the microservices-based architecture of DIGIT enables its components to evolve separately. On DIGIT Individual components can evolve separately to enable the heterogeneous evolution of the system.

DIGIT uses SemVer 2.0 for versioning its microservices and interfaces. Semantic versioning is a formal convention for specifying compatibility using a three-part version number: major version; minor version; and patch. More details on this can be found at this link: https://semver.org/.

DIGIT is designed to be horizontally scalable. The microservices-based architecture of DIGIT also enables it to scale only needed components/services, thereby providing resource efficiency. E.g. Billing and Collection services can be scaled separately during financial year closing if the load pattern indicates an increasing volume of bill payments during that period.

DIGIT is designed to be hardware agnostic and can be run on any hardware. It has been tested on multiple commercial clouds and state-sponsored bare metal infrastructure. Components of DIGIT that need to use underlying hardware have been carefully chosen (in cases where DIGIT is using other open-source components) or designed (DIGIT’s own components) to provide a layer of abstraction that can be extended for any type of hardware.

Multi-channel Access

DIGIT is designed using API first approach, therefore enabling any user interface channel to leverage it. DIGIT’s own user interfaces (Web/mobile app, WhatsApp chatbot) are implemented using its APIs to ensure offered platform capabilities and data are accessible to any delivery channel based on configured policies. In states like Punjab and AP where DIGIT modules are being used, the citizens have been given multi-channel access - ULB counters, Web portals, Mobile App, WhatsApp Chatbot and 3rd party applications like Paytm, BBPS to avail local government services.

DIGIT’s access control mechanism can be configured to provide different levels of access based on channels and roles.

Ecosystem-driven

DIGIT platform and its user interfaces are completely open source. Also, all external components used in DIGIT are also Open Source. Due to its API-based and event-driven architecture DIGIT can be integrated with any existing stack. Wherever appropriate, DIGIT also provides out-of-the-box integrations with crucial stacks/platforms. The most common integrations are to payment gateways, SMS providers and SMTP email servers for a typical implementation.

More than 14 organizations have already partnered with us to implement DIGIT across multiple implementations in the country and have built more than 20 new solutions on top of the platform.

DIGIT also provides the capability to gather feedback from the ecosystem in a digital manner. Feedback capability in DIGIT can be looked at the following levels:

Service Delivery feedback on services offered through DIGIT - DIGIT provides a highly configurable and extensible Public Grievance module to enable this kind of feedback/redressal for functional users (Citizens, employees etc)
Service Usage feedback - DIGIT user interfaces include a telemetry SDK which is backed by telemetry infrastructure on the DIGIT platform. Coupled with API access logs, this enables DIGIT to gather user feedback through live action and can be used for fine-tuning interfaces and APIs
Design/Feature feedback - As an open-source project on GitHub, DIGIT provides a mechanism to provide comments/feedback on its various components using GitHub. This feedback can be leveraged to create a Point of View on the future roadmap for the platform.

Architecture

DIGIT Infra and architecture details

DIGIT is India’s largest open-source platform for digital governance. It is built on OpenAPI (OAS 2.0) and provides API-based access to a variety of urban/municipal services enabling state governments and city administrators to provide citizen services with relevant new services and also integrate the existing system into the platform and run seamlessly on any commercial/on-prem cloud infrastructure with scale and speed.

Key Architecture Highlights

DIGIT is a microservices-based platform that is built to scale. Microservices are small, autonomous and developer-friendly services that work together.

A big software or system can be broken down into multiple small components or services. These components can be designed, developed & deployed independently without compromising the integrity of the application.
Parallelism in development: Microservices architectures are mainly business-centric.
MicroServices have smart endpoints that process info and apply logic. They receive requests, process them, and generate a response accordingly.
Decentralized control between teams, so that its developers strive to produce useful tools that can then be used by others to solve the same problems.

MicroServices architecture allows its neighbouring services to function while it bows out of service. This architecture also scales to cater to its clients’ sudden spike in demand.
MicroService is ideal for evolutionary systems where it is difficult to anticipate the types of devices that may be accessing our application.

Multi-layer Architecture

DIGIT follows Multilayer or n-tiered distributed architecture pattern. As seen in the illustration above there are different horizontal layers with some set of components eg. Data Access Layer, Infra Services, Business Services, different modules layers, client Apps and some vertical adapters. Every layer consists of a set of microservices. Each layer of the layered architecture pattern has a specific role and responsibility within the application.

Layered architecture increases flexibility, maintainability, and scalability
Multiple applications can reuse the components
Parallelism
Different components of the application can be independently deployed, maintained, and updated, on different time schedules
Layered architecture also makes it possible to configure different levels of security to different components
Layered architecture also helps users test the components independent of each other

Configuration

This section contains documents and information required to configure the DIGIT platform

Learn how to configure the DIGIT Urban platform. Partner with us to enhance and integrate more into the platform.

Git Repos

Summary of DIGIT OpenSource GitRepos and it's purpose. If you are a partner/contributor you may choose to fork or clone depending on need and capacity.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Setting up Master Data

Learn how to setup DIGIT master data.

MDMS Overview
Configuring Master Data
Adding New Master
Configuring Tenants
State Level vs City Level Master

MDMS Overview

Overview

MDMS stands for Master Data Management Service. MDMS is One of the applications in the eGov DIGIT core group of services. This service aims to reduce the time spent by developers on writing codes to store and fetch master data ( primary data needed for module functionality ) which doesn’t have any business logic associated with them.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.
Prior knowledge of Git.
Advanced knowledge of how to operate JSON data would be an added advantage to understand the service.

Key Functionalities

The MDMS service reads the data from a set of JSON files from a pre-specified location.
It can either be an online location (readable JSON files from online) or offline (JSON files stored in local memory).
The JSON files will be in a prescribed format and store the data on a map. The tenantID of the file serves as a key and a map of master data details as values.
Once the data is stored in the map the same can be retrieved by making an API request to the MDMS service. Filters can be applied in the request to retrieve data based on the existing fields of JSON.

Deployment Details

For deploying the changes in MDMS data, the service needs to be restarted.
The changes in MDMS data could be adding new data, updating existing data, or deletion.

Configuration Details

The config JSON files to be written should follow the listed rules

The config files should have JSON extension
The file should mention the tenantId, module name, and the master name first before defining the data

{
  "tenantId": "uk",
  "moduleName": "BillingService",
  "{$MasterName}":[ ]
}

Example Config JSON for “Billing Service”

{
  "tenantId": "pb",
  "moduleName": "BillingService",
 "BusinessService": 
 [
    {
      "businessService": "PropertyTax",
      "code": "PT",
      "collectionModesNotAllowed": [ "DD" ],
      "partPaymentAllowed": true,
      "isAdvanceAllowed": true,
      "isVoucherCreationEnabled": true
    }
]
}

Reference Docs

Doc Links

API List

Configuring Tenants

Overview

Tenant represents a body in a system. In the municipal system, a state and its ULBs (Urban local bodies) are tenants. ULB represents a city or a town in a state. Tenant configuration is done in MDMS.

Pre-requisites

Before proceeding with the configuration, the following pre-requisites are met -

Knowledge of json and how to write a json is required.
Knowledge of MDMS is required.
User with permission to edit the git repository where MDMS data is configured.

Key Functionalities

For the login page city name selection is required. Tenant added in MDMS shows in city drop-down of the login page.
In reports or in the employee inbox page the details related to ULB is displayed from the fetched ULB data which is added in MDMS.
Modules i.e., TL, PT, MCS can be enabled based on the requirement for the tenant.

Deployment Details

After adding the new tenant, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Tenant is added in tenant.json. In MDMS, file tenant.json, under tenant folder holds the details of state and ULBs to be added in that state.

Naming Convention for Tenants Code

“Code”:“uk.citya” is StateTenantId.ULBTenantName"

Localization should be pushed for ULB grade and ULB name. The format is given below.

Localization for ULB Grade

Localization for ULB Name

Format of localization code for tenant name <MDMS_State_Tenant_Folder_Name>_<Tenants_Fille_Name>_<Tenant_Code> (replace dot with underscore)

Boundary data should be added for the new tenant.

Reference Docs

Doc Links

Configuring Master Data

Overview

Configuring Master Data for a new module requires creating a new module in the master config file and adding master data. For better organizing, create all the master data files belonging to the module in the same folder. Organizing in the same folder is not mandatory it is based on the moduleName in the Master data file.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

User with permission to edit the git repository where MDMS data is configured.

Key Functionalities

These data can be used to validate the incoming data.

Deployment Details

After adding the new module data, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Adding new module

The Master config file is structured as below. Each key in the Master config is a module and each key in the module is a master.

{
  "<module1>":{
    "<master1>":{},
    "<master2>":{},
    ...
  },
  "<module2>":{
    <master3>:{},
    <master4>:{},
    ...
  },
  ...
}

The new module can be added below the existing modules in the master config file.

Creating Masters data

Please check the link to create new master Adding New Master

Reference Docs

Doc Links

Adding New Master

Overview

For creating a new master in MDMS, create the JSON file with the master data and configure the newly created master in the master config file.

Pre-requisites

Before proceeding with the configuration, make sure the following pre-requisites are met -

User with permission to edit the git repository where MDMS data is configured.

Deployment Details

After adding the new master, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Creating Master JSON

The new JSON file needs to contain 3 keys as shown in the below code snippet. The new master can be created either State-wise or ULB-wise. Tenant id and config in the master config file determine this.

{
  "tenantId": "< TENANT ID >",
  "moduleName": "< MODULE NAME >",
  "< MASTER NAME >": []
}

Configuring The Master Config File

The Master config file is structured as below. Each key in the Master config is a module and each key in the module is a master.

{
  "<module1>":{
    "<master1>":{},
    "<master2>":{},
    ...
  },
  "<module2>":{
    <master3>:{},
    <master4>:{},
    ...
  },
  ...
}

Each master contains the following data and the keys are self-explanatory

"master":{
    "masterName": "<>",
    "isStateLevel": true,
    "uniqueKeys": []
}

Reference Docs

Doc Links

State Level Vs City Level Master

Overview

MDMS supports the configuration of data at different levels. While we enable a state there can be data that is common to all the ULBs of the state and data specific to each ULBs. The data further can be configured at each module level as state-specific or ULB’s specific.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.
Prior knowledge of Git.
Advanced knowledge of how to operate JSON data would be an added advantage to understand the service.

Key Functionalities

State Level Masters are maintained in a common folder.
ULB Level Masters are maintained in separate folders named after the ULB.
Module Specific State Level Masters are maintained by a folder named after the specific module that is placed outside the common folder.

Deployment Details

For deploying the changes(adding new data, updating existing data or deletion) in MDMS, the MDMS service needs to be restarted.

Configuration Details

State Level Master Configuration

The common master data across all ULBs and modules like department, designation, etc are placed under the common-masters folder which is under the tenant folder of the MDMS repository.

ex: egov-mdms-data/data/pb/common-masters/ Here “pb” is the tenant folder name.

The common master data across all ULBs and are module-specific are placed in a folder named after each module. These folders are placed directly under the tenant folder.

ex: egov-mdms-data/data/pb/TradeLicense/ Here “pb” is the tenant folder name and “TradeLicense“ is the module name.

ULB Level Master Configuration

Module data that are specific to each ULB like boundary data, interest, penalty, etc are configured at the ULB level. There will be a folder per ULB under the tenant folder and all the ULB’s module-specific data are placed under this folder.

ex: egov-mdms-data/data/pb/amritsar/TradeLicense/ Here “amritsar“ is the ULB name and “TradeLicense“ is the module name. All the data specific to this module for the ULB are configured inside this folder.

Reference Docs

Doc Links

API List

Master Data Collection Templates

Objective

Content of pages within this document is designed to help implementation parties and end-users in providing the required data in minimal interaction and iterations and ensure the quality, consistency and shape of data needed to configure into the system.

Audience

This page is intended to help stakeholders as given below on data gathering activities.

State Team
eGov Onsite Team/ Implementation Team
ULB Team (Nodal and DEO)
Implementation Partners

Output Artefacts

The artefacts of this document are the data template of a configurable entity, a page with content defining the entity template and helping on how to fill the template with required data.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Environment Setup

DIGIT environment setup is conducted at two levels.

State Level Setup
ULB Level Setup

State Level Setup

Key configurations at the state level include -

Tenants Information
SMS Account Configuration
Email Account Configuration
Google Play Store Account
Payment Gateway Configuration
POS Configuration
Domain Name Configuration
SSL Configuration
ULB Departments
ULB Designations
Localization
Google Map Configuration

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Tenants Information

Introduction

An Urban Local Body (ULB) is defined as a tenant. The information which describes the various attributes of a ULB is known as tenant information. This detail is required to add the ULB into the system.

Data Table

S. No.

ULB Name*

ULB Code*

ULB Grade*

City Name*

City Local Name

District Name*

District Code*

Region Name

Region Code

Contact Number*

Address*

ULB Website*

Latitude

Longitude

Email Address

GIS Location Link

Call Center No.

Facebook Link

Twitter Link

Logo file Path*

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Steps to fill data

Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning as given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you and discuss the same to clear out the doubts.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist by taking care of each and every point mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

To see common checklist refer to the page Checklist consisting of all the activities which are to be followed to ensure completeness and quality of data.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There are no checklist activities exists which are specific to the entity.

Attachments

SMS Account Configuration

Introduction

The SMS service is a way of communicating necessary information/updates to the users on their various transactions on DIGIT applications.

In order to update the users, there are certain notification parameters that are system configured for various steps in the application process. These configurations can be changed/reconfigured based upon the ULB requirements.

Data Table

We have the below-mentioned parameters which we use for configuration:

Sr. No.

Parameter

Value

The data given in the above table is sample data. The parameters and its values are SMS service provided specific and may vary accordingly.

Procedure

For the SMS service to be integrated there are various things for which the vendor more or less guides us for the steps to be followed but below mentioned are a few basic steps and the generic data definitions which could be followed.

Data Definition

Below mentioned are the descriptions of the parameters which are needed for configuration:

Sr. No.

Column Name

Data Type

Data Size

Mandatory

Description

Parameter names could differ from vendor to vendor.

Steps to fill Data

Since the SMS service is a vendor delivered service for which the below steps would have to be followed:

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
The SMS vendor has to provide the data in the data template attached.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Email Account Configuration

Introduction

An email account of the client/state team has to be set up in order to receive/send the email notifications.

In order to achieve the functionality, an email account has to be set up at there server since most of the states would defer from creating an account with the Gmail/public server. Further, this email account has to be integrated with the various DIGIT modules.

Data Table

In order to achieve the above functionality, we require the below-mentioned details

Sr. No.

Email ID

Your Name

Account Type

Incoming Mail Server

Outgoing Mail Server (SMTP)

Password

Incoming Server POP3 Port

Outgoing server SMTP Port

Encrypted Connection Type

Days after which the email should be removed from the server

The values mentioned here are sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Steps to fill Data

Below steps could be followed in order to fill the template:

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Ask the state to gather all the data related to the technical configuration from the email server settings.
Get the attached template filled from the state and a sample data is provided in the data table section for reference.
The data would be available in the POP and IMAP account settings at the server level.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Google Play Store Account

Introduction

Whenever an android mobile App is developed it has to be published on the Google play store in order to let the users avail its service. This page provides information about configuring the google play store account to make DIGIT mobile apps available for easy download.

Data Table

In order to start the configuration for the google play store following would be required:

Sr. No

Email Id

Password

Data given in the table is sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Mandatory

Description

Steps to fill Data

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Ask the state team/client to create an email account on Gmail.
Ask the client to log in to the google play console here and make the required payment so that further tasks could be processed.
Ask the client to share the email id and password in the template.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Payment Gateway Configuration

Introduction

DIGIT has modules which require the user to pay for the service that he/ she is availing for example property tax, trade license etc. . In order to achieve the functionality, we have a common payment gateway developed which acts a liaison between DIGIT apps and external payment gateways (which depends on the client requirements).

This module facilitates payments and lookup of transaction status.

Data Table

Following are the details required from the payment gateway vendor in order to configure the payment gateway:

Sr. No

Integration Kit

API Documentation

Redirect Working Key

Merchant Id

Test credential of Debit Card/ Net banking

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Steps to fill data

The payment gateway is a vendor oriented service that is integrated with different modules in order to facilitate the transactions. Below mentioned are the steps which are followed:

The client has to finalize a payment gateway vendor (for example PAYU, Paytm, HDFC, AXIS atc.) depending upon the requirements.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
After which the details/ documents mentioned in the template would be provided by the vendor.
These details are to be received separately for both prods as well as UAT.
Get the IP address for UAT and Production environments whitelisted from the vendor.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

POS Integration Configuration

Introduction

Point of Sales (POS) machine is a machine that helps in handling transaction processing. This machine accepts and verifies the payments which are made by citizens for prevailing the services of DIGIT.

POS facilitates a middleware app developed in order to verify the payment process between the DIGIT module and the payment.

In this case, no data is required from the state team.

Data Table

Not applicable.

Procedure

Not applicable.

Checklist

Not applicable.

Attachments

Not applicable.

All content on this page by is licensed under a .

Domain Name Configuration

Introduction

The domain name is the address through which the internet users can access the website rather than entering the whole IP address in the search bar of the browser.

This domain name is ideally chosen by the state/client since its a product which has to be used for/by them.

Data Table

Following is the table through which the information can be shared.

Sr. No.

Domain Name

EXTERNAL-IP

Data given in the table is a sample data.

Procedure

Since all state governments/clients prefer to host the websites on their servers, this activity is ideally done by them.

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Steps to fill data

Following are the steps which are to be followed:

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
If the state agrees to host the website on their server, provide them with the 2 columns mentioned in the attached template.
If the state disagrees to host on their server, then a domain name has to be purchased by any of the external vendors and the EXTERNAL-IP address has to be mapped with them.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity:

Attachments

SSL Configuration

Introduction

SSL is Secure Sockets Layer is an encryption-based network security protocol developed for the assurance of privacy, authenticity and data integrity in internet communications.

Ideally, the domain name configuration and the SSL certification are obtained consecutively without fail from the state’s IT team.

No data is needed from the state team for this.

Data Table

Not Applicable

Procedure

Not Applicable

Data Definition

Not Applicable

Steps to fill data

Not Applicable

Checklist

Not Applicable

Attachments

Not Applicable

ULB Departments

Introduction

The departments are defined as different sections within the ULB based on which the functions performed by ULBs and employees in ULB are grouped. The budgets details of the ULBs are also defined by the department. It is suggested that the ULB across the state adopt the same department naming terminology. This document will help you in filling the department detail in the template provided.

Data Table

Sr. No.

Department Code*

Department name (In English)*

Department Name (In Local Language)*

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Steps to Fill Data

Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify all the departments in ULB well before start filling then into the template.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed after the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.

Attachments

ULB Designations

Introduction

A designation is an act of pointing someone out with a name, a title or an assignment. For example, someone being named president of an organization. This document is to help to gather various designations data which are generally used in ULBs.

Data Table

Sr. No.

Designation Code*

Designation Name* (In English )

Designation Name* (In Local Language)

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Steps to fill data

Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify all the designations exists in the ULB, refer to governments gazette to define the designations in ULBs.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.

Attachments

Localization

Introduction

Localization is a practice to localize various UI visible data into the local wordings according to the client's requirements. This practice of localization is enforced on various clients so that it becomes easier for the people using the service to understand the common terminology and make the best use of the available system.

The following texts (but not limited to) on the web page can be localized:

Labels
Messages: Alert messages, success messages, validation messages and other notifications etc.
Help Texts

The module-specific master data would already have been made available in the localized form while collecting the data for the respective module-specific configuration.

Data Table

Sr. No.

Code*

Module*

Message (In English)*

Message (In Local Language)*

Data mentioned in the data table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Steps to fill Data

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Present the client the full sheet of codes as well as the English language for which the localized texts are required.
Ask the client to fill the localized text in the last column which is the message(local language) column.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.