1 of 100

v2.8

Introducing DIGIT Urban

The Digital Urban Governance Platform

Mission

Building an urban governance platform to catalyze digital transformation across towns and cities - changing the way citizens interact with government bodies.

Overview

DIGIT Urban Stack is a set of Open APIs, services, and reference implementations, set up as a public good, to allow government entities, businesses, startups, and civil society to use a unique digital Infrastructure and build solutions for urban India at a large scale. It provides a set of open standards, specifications and documentation to create a level playing field and enable ecosystem players to innovate on the stack. As a public good, the platform is provided without profit or restriction to all members of society.

Important Updates:

DIGIT is certified as a Digital Public Good (DPG) by the Digital Public Goods Alliance (DPGA) - a multi-stakeholder initiative with a mission to accelerate the attainment of sustainable development goals. Find the DIGIT platform in the DPG registry along with a host of other globally recognized DPGs.

Click here for more details.

Goals

The urban mission offers digital governance solutions that encapsulate the core platform principles. The apps provide

Secure & reliable governance tools
Simple reusable modules for effective integration
Scalable & standardized solutions
Open APIs to promote interoperability
Multiple channel support
Configurable building blocks that support customization at each stage

Approach

DIGIT-Urban focuses on inclusion and is designed on the principle of enhancing both platform openness and choice for citizens. The platform uses open APIs and standards, creating a powerful framework to drive convergence across the multiple systems currently in use and to lower the barrier to entry for locally-developed solutions.

Keeping in mind that most Indians use the internet through their phones, we follow and advocate a “mobile-first” approach, while supporting multi-channel access to accommodate diverse needs and preferences.

Open Source - DIGIT is Open Source and has been built using the best in class Open Source technology stacks powering the most advanced companies in the world. DIGIT is able to provide the lowest total cost of ownership and helps ensure that governments retain strategic control of their systems and data.
Mobile-Enabled - DIGIT has adopted a mobile-first approach, with robust mobile applications enabling citizens to easily access government services through their phones. Government officials and field workers are also empowered with mobile applications that enable them to deliver 24×7 governance with ease.
Real-time Dashboards - DIGIT’s real-time dashboards provide governments with actionable insights on demand. Administrators and department heads are empowered with verified data that enables them to manage their work and budgets better. Field-level employee reports enable effective performance management and ensure efficient usage of government resources.

Useful Links

Contact Us

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 .
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 -
Latest persister file -

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

Water modify connection
Sewerage modify connection
Sewerage Disconnection
Water Disconnection

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:

Insert the name and jsonPath which are not actually expected to be present in the RequestBody/ResponseBody
Files to be updated
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
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}
3. Restart the MDMS service followed by the encryption service
4. - 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.
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
3. Restart the MDMS service followed by the encryption service
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
NationalDashBoard 3 New KPI
2. MasterDashboardConfig.json
Finance Module State DSS
MDMS & Configs -

BackWard Compatibility Results -

UI Changes

Please add all MDMS changes before deploying the UI code.

W&S: W&S UI/UX Revamp
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)

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

UM-5322: PT: Mutation flow: In Acknowledgement Form only one Transferor Details are present.SIGNED OFF

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

https://digit-discuss.atlassian.net/browse/UM-5599

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

https://digit-discuss.atlassian.net/browse/UM-5286 https://digit-discuss.atlassian.net/browse/UM-5625 https://digit-discuss.atlassian.net/browse/UM-5682 https://digit-discuss.atlassian.net/browse/UM-5547 https://digit-discuss.atlassian.net/browse/UM-5554 https://digit-discuss.atlassian.net/browse/UM-5692

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

https://digit-discuss.atlassian.net/browse/UM-5637 https://digit-discuss.atlassian.net/browse/UM-5293

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

https://digit-discuss.atlassian.net/browse/UM-5256

Upcoming Release Features

None

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

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

Installation

to learn more about the setup basics.

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 .
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 -
Latest persister file -

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

Water modify connection
Sewerage modify connection
Sewerage Disconnection
Water Disconnection

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
2. - 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 ()
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 ()
3. Restart the MDMS service followed by the encryption service
4. Add the temporary 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
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 ()
3. Restart the MDMS service followed by the encryption service
4. Add the temporary update index with encrypted data
5. Add the new for the fuzzy search index
6. Trigger the encryption of old data through the provided
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 are specific to Punjab implementation, generic product document is in the pipeline.
NationalDashBoard 3 New KPI
2. MasterDashboardConfig.json
Finance Module State DSS
MDMS & Configs -

BackWard Compatibility Results -

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 (). 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 ()
- We need to add the below images in the S3 bucket:PGR:
- PT:
- TL:
- OBPS:
- FSM:
- WS:
- Bills:
Navigation re-direction from New UI to OLD UII. Mdms Changes are required for this ().

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.

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 Privacy And Security By Design

Data Privacy

Security

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

Reusability and Extensibility

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.

Evolvability and Scale

Multi-channel Access

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

Ecosystem-driven

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.

Dashboard Analytics - Backend

DSS Backend Configuration Manual

Overview

DSS has two sides to it. One is the process in which the data is pooled to ElasticSearch and the other is the way it is fetched, aggregated, computed, transformed and sent across. DSS must be configurable since the entire process involves playing around with a variety of data sets. This ensures easy configuration of data sets in new scenarios.

This document explains the steps on how to define the configurations for both sides of DSS Analytics and Ingest Pipeline Services.

Commonly Used Terms

Ingest: Micro Service which runs as a pipeline and manages to validate, transform and enrich the incoming data and pushes the same to ElasticSearch Index

Analytics: Micro Service which is responsible for building, fetching, aggregating and computing the Data on ElasticSearch to a consumable Data Response. Which shall be later used for visualizations and graphical representations.

JOLT: JSON to JSON transformation library written in Java where the "specification" for the transform is itself a JSON document

Modules / Domain Level: These are the Services in this context. Each of the services, such as Property Tax, Trade License, Water and Sewerages are considered as Modules / Domains

Chart: Each individual graphical representation is considered as a Chart in specific. For example, a Metric of Total Collection is considered as a Chart.

Visualization: Group of different Charts is considered as a Visualization. For example, the group of Total Collection, Target Collection and Target Achieved is considered as a Metric Collection of Charts and thus it becomes a Visualization.

Configuration Details

Discussed below are the ingest pipeline configuration details -

Topic Context Configurations
Validator Schema
JOLT Transformation Schema
Enrichment Domain Configuration
JOLT Domain Transformation Schema

Topic Context Configurations

Topic context configuration is an outline to define which data is received on which Kafka Topic.

Indexer Service and many other services are sending out data on different Kafka Topics. If the Ingest Service receives the data and passes it through the pipeline, the context and the version of the data received have to be set. This configuration is used to identify which Kafka topic consumed the data and the mapping details.

Click here for the full configuration

Validator Schema

Validator schema is a configuration schema library from Everit. By passing the data against this schema, it ensures whether the data abides by the rules and requirements of the schema that has been defined.

Click here for an example configuration

JOLT Transformation Schema

JOLT is a JSON to JSON transformation library. In order to change the structure of the data and transform it in a generic way, JOLT has been used.

While the transformation schemas are written for each data context, the data is transformed against the schema to obtain transformed data.

Follow the slide deck for JOLT Transformations

Click here for an example configuration

Enrichment Domain Configuration

This configuration defines and directs the enrichment process that the data goes through.

For example, if the data which is incoming is belonging to a collection module data, then the collection domain config is picked. And based on the specified business type the right config is picked.

In order to enhance the data of collection, the domain index specified in the configuration is queried with the right arguments and the response data is obtained, transformed and set.

Click here for an example configuration

JOLT Domain Transformation Schema

As a part of enhancement, once the domain level object is obtained, we might not need the complete document as is in the end data product.

Only those parameters which should be or can be used for aggregation and representation are to be held and others are to be discarded.

In order to do that, we make use of JOLT again and write schemas to keep the required ones and discard the unwanted ones.

The above configuration is used to transform the data response in the enrichment layer.

Click here for an example configuration

Use case:- JOLT Transformation Schema for collection V2

JOLT transformation schema for payment-v1 has been taken as a use case to explain the context collection and context version v2. The payment records are processed/transformed with the schema. The schema supports splitting the billing records into an independent new record. So if there are 2 bill items in the collection/payment incoming data then this results in 2 collection records in turn.

Click here for an example configuration

Here: $i, the variable value that gets incremented for the number of records of paymentDetails

$j, the variable value that gets incremented for the number of records of bill details.

Note: For Kafka connect to work, Ingest pipeline application properties or in environments direct push must be disabled.

es.push.direct=false

Analytics Configurations

Below is the list of configurations

Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration

Chart API Configuration

Each Visualization has its own properties. Each Visualization comes from different data sources (Sometimes it is a combination of different data sources)

In order to configure each visualization and its properties, we have Chart API Configuration Document.

In this, Visualization Code, which happens to be the key, will be having its properties configured as a part of the configuration and are easily changeable.

Click here for an example configuration

Master Dashboard Configuration

Master dashboard configuration defines the dashboards that are to be painted on the screen.

It includes all the visualizations, their groups, the charts and even their dimensions in terms of height and width.

Click here for an example configuration

Role Dashboard Mappings Configuration

Role dashboard mapping ensures that each role is mapped against the dashboards that they are authorized to see.

Click here for an example configuration

Adding Configurations

Adding Roles and Dashboards

To add a new role, modify the RoleDashboardMappingsConf.json (roles node) configuration file as given below.

Note: Any number of roles & dashboards can be added

Below as in Figure 9 is a sample to add a new role object, a new dashboard object.

To add a new dashboard, modify the MasterDashboardConfig.json (dashboards node) as shown below in Figure 10.

Note: dashboards array add a new dashboard as given below

Adding Visualizations

To add new visualisations, modify the MasterDashboardConfig.json (vizArray node) as shown in Figure 11.

Note: vizArray is used to hold multiple visualizations.

Adding Charts

To add a new chart, chartApiConf.json has to be modified as shown below. A new chartid has to be added with the chart node object.

Metric chart Sample as shown in Figure 12.

Pie chart Sample as shown in Figure 13.

Line chart Sample as shown in Figure 14.

Table chart Sample: This chart is of 2 types - table and xtable.table (as shown in Figure 15.) Type allows the addition of aggregated fields as available in the query keys. To extract the values based on the key, aggegationPaths have to be added along with their data type as in pathDataTypeMapping.

xtable (as shown in Figure 16) type allows the addition of multiple computed fields with the aggregated fields added dynamically.

To add multiple computed columns, define the following params within computedFields []

actionName - (IComputedField<T> interface),
fields - [] names as existing in the query key,
newField - name to appear for the computation

https://github.com/egovernments/configs/blob/master/egov-dss-dashboards/dashboard-analytics/ChartApiConfig.json for the full configuration in detail.

Steps to create charts and visualise are:

Create/Add a chart in chartApiConf.json
Add a visualization for the existing dashboard in MasterDashboardConfig.json as defined above.
Or in order to create/add a new dashboard create the dashboard in MasterDashboardConfig.json and create a role in RoleDashboardConfig.json

Configuration Changes For DrillThroughs:

Example - drill through in ward table in the property tax dashboard.

wardDrillDown is the visualization code for PT Drill Down. The 'kind' attribute shows the type of visualization code. Apart from two things all the attributes are common.

Example - Drill through in the ComplaintList table in the PGR Dashboard.

complaintDrillDown is the visualization code for PGR Drill Down.

The above complaintDrillDown visualization code is called in the drill chart parameter.

DSS Dashboard - Technical Document for UI

Overview

A decision support system (DSS) is a composite tool that collects, organizes and analyzes business data to facilitate quality decision-making for management, operations and planning. A well-designed DSS aids decision makers in compiling a variety of data from many sources: raw data, documents, personal knowledge from employees, management, executives and business models. DSS analysis helps organizations identify and solve problems, and make decisions.

Code Git Repos: https://github.com/egovernments/frontend/tree/master/web/dss-dashboard

Type Of Users

State-Level Admin
Commissioner
Domain-Level Employee

Dashboard List

There are three types of dashboards -

Home page (refer figure 1)
Overview page (refer figure 2)
Module level dashboard (refer figure 3)

1. Home page

The home page contains multiple cards, each card is clickable.

There are two types of cards, i.e, the overview card and the module-level card.

The overview and the module level cards are differentiated by vizType,

Overview card: Clicking on the overview card navigates to the overview page. vizType for overview is a collection.
Module Level card: Clicking on the module level card navigates to the module level dashboard. vizType is a module (i.e Property Tax, Trade License etc).

Request Payload for dashboardConfig

auth-token: authenticate the request and it fetches from a local storage key called “Employee.token”

DashboardConfig API Response

roleName: the type of user.

Visualisations: The key contains all configurations for displaying the visualisation like rows with charts etc please refer to figure 1.3.

In Figure 1.3, vizType key will define the module UI like

Collection chart & module chart refer figure 1

2. Overview Dashboard

3. Module Level Dashboard

Visualisation List

In dashboardConfig response, the visualisation key contains all rows & charts details (refer figure 1.3). Each row contains the visual details like name, vizType, noUnit, isCollapsible, charts etc (refer figure 1.3).

name - name of visualisation
vizType - type of visualisation like COLLECTION, MODULE, METRIC-COLLECTION, PERFORMING-METRIC, CHART
- COLLECTION - The home page, contains the collection data (refer figure 1).
- MODULE - The home page, contains the module-level data (refer figure 1).
- METRIC-COLLECTION - In Overview/Module Level Page, contains the collection data (refer figure 2.1).
- PERFORMING-METRIC -In Overview/Module Level Page, contains the top/bottom performing data (refer figure 2.2).
- CHART - In Overview/Module Level Page, contains the below visualisations (refer figure 2.3 to figure 2.7).
  - PIE CHART (refer figure 2.3)
  - LINE CHART (refer figure 2.4)
  - BAR CHART (refer figure 2.5)
  - HORIZONTAL BAR CHART (refer figure 2.6)
  - TABLE CHART (refer figure 2.7)

Visualisations

ULB Dashboard

ULB dashboard contain different filters, i.e ULBs and Wards/Blocks. The data to the filters are loaded from MDMS API below - https://dev.digit.org/egov-mdms-service/v1/_search

Each ULB dashboard, overview dashboard and module-level pages contain different filters and are identified by roleName in configs API.
The Wards/Blocks filter is a dependable filter, which gets loaded on ULB selection.
In the ULB dashboard, the on-page ULB filter is applied across all the charts and for the performance chart, the default ULB filter is not applied.
Overview and all module level pages has a ULB dashboard.

GLOBAL Filters (refer to figure 2.8)

Filters are loaded from the MDMS API - https://dev.digit.org/egov-mdms-service/v1/_search. Filters are loaded on the basis of roleName.

Admin role: On the Module level page, Date, DDR and ULB filter are loaded.

On the Overview level page, Date, DDR, ULB and Service filter are loaded.

Commissioner role: On the Module level page, Date, ULB and Wards/Blocks filters are loaded.

On the Overview page, Date, ULB and Service filters are loaded.

Denomination filter: The Denomination filter has three options to display the amount and number in a particular format.

Crore
Lack
Unit

The denomination filter is not applied to the percentage and text (refer to figure 2.10). The type of data is identified by a symbol in the plots of charts API.

Custom Date Filter

If duration < 15 days, it displays data day-wise

If duration <= 30 days, it displays data week-wise

If duration >30, it displays data month-wise

Tabs

Currently, the dashboard contains two types of tabs -

Revenue (refer figure: 4.1)
Service (refer figure: 4.1)

Tabs are identified by name in visualisations of config API.

Table Chart with drill-down

Table chart visualisations have normal material UI data table features like search, sort etc.

In table response, if filter key & drillDownChartId contain any value users can drill-down the table.

Cards

Each card header is localised and has an info icon with a tooltip option that displays the header and can display a description.
The number of cards in a row and in a page is driven by the backend. The backend provides the row number to each card where it should be displayed.
Card contains option icon that enables users to either download images and or share images.
Image download and share user id from vizArray in order to differentiate each card in a page.

Download and Share (refer to figure 2.9)

Download offers two options - to download data as an image or a PDF.

Share: Share creates the Image/PDF and uploads it S3 using below API and returns file id - https://mseva-uat.lgpunjab.gov.in/filestore/v1/files

The file Id is fetched using the API - https://mseva-uat.lgpunjab.gov.in/filestore/v1/files/url

Each S3 image is shortened using the API - https://mseva-uat.lgpunjab.gov.in/egov-url-shortening/shortener

Configurations

Github link for config: https://github.com/egovernments/frontend/blob/master/web/dss-dashboard/src/config/configs.js

BASE URL: End point of REST API for dashboard.

FILE Upload: End point of REST API for file upload.

FETCH FILE: End point of REST API for file fetch.

MDMS: End point of REST API for fetch MDMS Data.

SHORTEN URL: End point of REST API for Shorten URL, which is used for share via Email / What's app.

CHART COLOR CODE: Color code object for all charts.

MODULE LEVEL: for global filters, which contains services name & filter key.

SERVICES: for global filter, service filter.

Upload Localisation Keys

code: pre-defined key for back-end.

message: message contains the value for the key.

module: rainmaker-dss

locale: contains locale data

for more details eGov team to be documented

Module name: rainmaker-dss

NPM Module Used - https://github.com/egovernments/DIGIT-OSS/blob/master/frontend/mono-ui/web/dss-dashboard/package.json

Steps to setup DSS in Local

Step 1: Run as independent, switch to dss-dashboard folder

Step 2: Get the below details from the environment website and update the localstorage in the browser.

Employee.tenant-id Employee.user-info Employee.token Employee.module Employee.locale localization_en_IN locale

Step 3: Run Yarn install and yarn start to start working on dss in local setup.

DSS Features Enhancements V2: DSS Features Enhancements V2 Technical Document for UI

Turn-Io-Adapter

Transform API

Objective: Reap Benefit system is one of the vendors that provide the chatbot services using the turn as backend services to communicate with citizen through chatbot. As part of the requirement, we need to create a complaint in digit platform when ever citizens raise the complaint through Reap Benefit chatbot.

Overview

The turn-io-adapter service is a wrapper to transform Reap Benefit request format to DIGIT PGR request format. This service has transform API that constructs the required PGR request from the request message sent from the Reap Benefit system. Reap Benefit system consumes the tranform API to communicate with the DIGIT PGR module.

In this process, once a complaint is created it sends a WhatsApp message to the citizen with a track link. Whenever some action is taken by ULB employees on complaint, a WhatsApp message is sent to citizen.

Pre-requisites

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

Java 8
Rainmaker-PGR service is running

Key Functionalities

Complaints are generated on the DIGIT platform using the Reap Benefit system chatbot.
Messages are sent to citizen through WhatsApp when employees perform some action on the complaint.

Deployment Details

Deploy the following builds

rainmaker-pgr-db:v1.1.3-bb2961cf-13
turn-io-adapter:v1.1.3-bb2961cf-19
egov-searcher:v1.1.3-d43c421c-5
nlp-engine:v1.0.0-c3889d14-10

Note: Please refer to the following url for nlp-engine technical documentation - NLP Engine Service

Frontend commits

Infra Configuration Details

1) turn-io-adapter: "http://turn-io-adapter.egov:8080/" (In service host configuration)

2) Add /turn-io-adapter/_transform in egov-mixed-mode-endpoints-whitelist configuration

3) Once you are done with 2nd step restart zuul pod

MDMS Data

Add name filed in complaint category master in PGR. Link for the data -

https://raw.githubusercontent.com/egovernments/egov-mdms-data/DEV/data/pb/RAINMAKER-PGR/ServiceDefs.json

Localisation Data

Push the localisation data for all the locality data with module as rainmaker-chatbot. Sample localisation object -

{ "code": "SC1", "message": "Azad Nagar - WARD_1", "module": "rainmaker-chatbot", "locale": "en_IN" }

Business Service / Workflow Configuration

Actions & Role Action Mapping

Actions

{
      "id": 2116,
      "name": "Create Turn Io Adapter",
      "url": "/turn-io-adapter/_transform",
      "displayName": "Turn Io Adapter",
      "orderNumber": 1,
      "enabled": true,
      "serviceCode": "turn-io-adapter",
      "code": "null",
      "path": ""
    }

Role Mapping

{
      "code": "ANONYMOUS",
      "name": "Any User",
      "description": "Can Transform the Data"
    }

RoleAction Mapping

{
     "rolecode":"ANONYMOUS",
     "actionid":2116,
     "actioncode":"",
     "tenantId":"pb"
  }

Data Setup

This is the samplerequest for _transform api to create a complaint

curl --location --request POST 'https://dev.digit.org/turn-io-adapter/_transform' \
--header 'Content-Type: application/json' \
--data-raw '{
    "contacts": [
        {
            "profile": {
                "name": "Rohit"
            },
            "wa_id": "9199999999992"
        }
    ],
    "messages": [
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "917391904467",
                        "name": "The_Subtle_Guy",
                        "type": "OWNER"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "inbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:33.809218Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "917391904467",
            "id": "ABEGkXORkERnAhBOXKjR8Jyyk-Iar8Gd2yeo",
            "text": {
                "body": "4"
            },
            "timestamp": "1621452093",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "fc89d3d7-bcab-4734-a82f-bf06fa99a980",
                        "name": "Complaint Selection",
                        "type": "THREAD"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "outbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:35.313898Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "15550152059",
            "id": "gBEGkXORkERnAglCxuTiC7G_ERg",
            "preview_url": false,
            "recipient_type": "individual",
            "text": {
                "body": "Please provide landmark or additional details of your locality.\\nOtherwise type and send *No*"
            },
            "timestamp": "1621452095",
            "to": "917391904467",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "917391904467",
                        "name": "The_Subtle_Guy",
                        "type": "OWNER"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "inbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:40.701184Z",
                    "labels": [
                        {
                            "confidence": 0.3339659565,
                            "metadata": {
                                "nlu": {
                                    "confidence": 0.3339659565,
                                    "intent": "await_reply",
                                    "model_name": "nlu-general-spacy-ngrams-20191014"
                                }
                            },
                            "uuid": "df376fa2-9358-4088-a6d0-8f3db031158b",
                            "value": "Unclassified"
                        }
                    ],
                    "rendered_content": null
                }
            },
            "from": "917391904467",
            "id": "ABEGkXORkERnAhBgzXDW_hlyiVg_IS6NxTMH",
            "text": {
                "body": "No"
            },
            "timestamp": "1621452100",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "fc89d3d7-bcab-4734-a82f-bf06fa99a980",
                        "name": "Complaint Selection",
                        "type": "THREAD"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "outbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:41.297301Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "15550152059",
            "id": "gBEGkXORkERnAgnMDgDG2-YCOv0",
            "preview_url": false,
            "recipient_type": "individual",
            "text": {
                "body": "Please enter the category of your issue from the options given below.\\n\\n1. Garbage\\n2. Street Lights\\n3. Water and Sewerage\\n4. Roads And Footpaths\\n5. Public Toilets\\n6. Land Violations\\n7. Animals and Insect"
            },
            "timestamp": "1621452101",
            "to": "917391904467",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "917391904467",
                        "name": "The_Subtle_Guy",
                        "type": "OWNER"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "inbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:44.672489Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "917391904467",
            "id": "ABEGkXORkERnAhARhnoBHV4O_DOlR9CNENoq",
            "text": {
                "body": "1"
            },
            "timestamp": "1621452104",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "fc89d3d7-bcab-4734-a82f-bf06fa99a980",
                        "name": "Complaint Selection",
                        "type": "THREAD"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "outbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:46.759132Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "15550152059",
            "id": "gBEGkXORkERnAgnskmr3neFP1ec",
            "preview_url": false,
            "recipient_type": "individual",
            "text": {
                "body": "Pick a issue from the options given below which describes closest to what you are facing.\\n\\n1. Garbage Needs To be Cleared\\n2. Damaged Garbage Bin\\n3. Burning Of Garbage"
            },
            "timestamp": "1621452106",
            "to": "917391904467",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "917391904467",
                        "name": "The_Subtle_Guy",
                        "type": "OWNER"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "inbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:51.967923Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "917391904467",
            "id": "ABEGkXORkERnAhBhofKX9wPf4-6xzUNnNJ5x",
            "text": {
                "body": "2"
            },
            "timestamp": "1621452111",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "fc89d3d7-bcab-4734-a82f-bf06fa99a980",
                        "name": "Complaint Selection",
                        "type": "THREAD"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "outbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:53.336395Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "15550152059",
            "id": "gBEGkXORkERnAglgp1wnhrkeJb0",
            "preview_url": false,
            "recipient_type": "individual",
            "text": {
                "body": "Please select from below option\\n\\n1. To submit complaint details\\n2. To re-enter the complaint details"
            },
            "timestamp": "1621452113",
            "to": "917391904467",
            "type": "text"
        },
        {
            "_vnd": {
                "v1": {
                    "author": {
                        "id": "917391904467",
                        "name": "The_Subtle_Guy",
                        "type": "OWNER"
                    },
                    "chat": {
                        "assigned_to": null,
                        "owner": "+917391904467",
                        "permalink": "https://app.turn.io/c/ac1ad367-1631-41b8-a29c-024ed19c1547",
                        "state": "OPEN",
                        "state_reason": "Re-opened by inbound message.",
                        "unread_count": 21,
                        "uuid": "ac1ad367-1631-41b8-a29c-024ed19c1547"
                    },
                    "direction": "inbound",
                    "faq_uuid": null,
                    "in_reply_to": null,
                    "inserted_at": "2021-05-19T19:21:58.364053Z",
                    "labels": [],
                    "rendered_content": null
                }
            },
            "from": "917391904467",
            "id": "ABEGkXORkERnAhCpESguA5JfsAlvKVTgoD0H",
            "text": {
                "body": "1"
            },
            "timestamp": "1621452118",
            "type": "text"
        }
    ],
    "thread": {
        "contact": {
            "arts": null,
            "birthday": null,
            "city": "pb.amritsar",
            "cityset": true,
            "complaint_category": "Garbage",
            "complaint_image": "No",
            "complaint_sub_category": "Dirty Water Supply",
            "complaintset": false,
            "complaintsetvalue": "To submit complaint details",
            "language": null,
            "locality": "JLC833",
            "localityset": true,
            "location": null,
            "math": null,
            "name": null,
            "opted_in": false,
            "opted_in_at": null,
            "space": null,
            "surname": null,
            "whatsapp_id": "917391904467",
            "whatsapp_profile_name": "Rohit"
        }
    },
    "RequestInfo": {
        "userInfo": {
            "id": 23342,
            "uuid": "f212e8aa-53ba-456f-9013-89fb806dc24b",
            "userName": "7878787878",
            "name": "Aditya",
            "mobileNumber": "7878787878",
            "emailId": "",
            "locale": "en_IN",
            "type": "CITIZEN",
            "roles": [
                {
                    "name": "Citizen",
                    "code": "CITIZEN",
                    "tenantId": "pb"
                }
            ],
            "active": true,
            "tenantId": "pb",
            "permanentCity": "pb.amritsar"
        }
    }
}'

Integration Details

Integration Scope

Turn-io-adapter is integrated with Rainmaker-pgr application. Turn-io-adapter application internally invokes the rainmaker-pgr service to generate complaints.

Steps to Integration

Turn-Io-adapter application to call turn-io-adapter/_transform to generate the complaint and takes the data from the PGR.

TL Apply Flow UI Details

Objective: To provide the facility for the user to create a trade license application for the current year by citizen users or counter employees.

Workflow Details

Apply for Trade License

Users can apply for a trade license application by clicking on the Apply for Trade License button. Users can add all the information as per the questions asked across the workflow. The summary screen at the end of the flow displays all details for review. Users can click on the submit button after review. The application for a trade license is created for the current financial year.

Apply Flow - The trade license registration screen is displayed after login which helps users identify the documents required to apply for a trade license. A citizen info card at the bottom of the page displays any additional information about the maximum size of the file that can be uploaded.

Trade License Details/Assessment Flow - This flow captures the trade-specific information required for registering the trade.

Trade Name - The user provides the name of the trade. An info card is displayed at the bottom of the screen stating that the license will be issued for the current financial year. The financial year value is retrieved from the MDMS.

Structure Type - The users can select yes or no based on whether the trade has mobility or not. If yes, the next screen prompts you to enter the vehicle type. If no, the next screen moves to the building type page.

Vehicle Type / Building Type - The options for vehicle and building type are fetched from the MDMS. The Building Type screen displays an information card about the pucca or kuccha options.

Commencement Date - It defines the date on which the trade started or will start in the future.

Trade Units - Users must provide the trade category as either goods or services. Based on the selected option the Trade Type is loaded from the MDMS as a drop-down list. The trade sub-type options are loaded based on the selected trade type. The unit of measure and UOM value get pre-populated from the MDMS as per the options selected above.

Users must enter at least one unit to move forward. Clicking on Add More Unit option enables users to enter additional units. Clicking on the delete icon on the top right corner of the unit card removes the unit.

Accessories - The Accessory page inquires if there are any accessories required for the business. Accessories may not be compulsory for all trades. If yes, it will move to the accessory details page. If not, it will skip it altogether and will load the address flow.

Accessory details - The options for accessories are retrieved from the MDMS. The Unit of Measure or UOM is pre-populated and cannot be edited. The users can edit the UOM value and the accessory count. In some cases, these are pre-populated from the MDMS. Clicking on Add More Trade Accessory button allows users to add multiple accessories.

TL Enhanced Flow

If the citizen selects Movable as the structure type in the previous screens, then the flow will jump to the owner details flow. Here the Same as Property Owner’s check box will not be visible.

If the citizen selects Immovable as the structure type then the user is allowed to add the property details. Once the property is added, the flow will redirect to the owner details flow where the Same as Property Owner check box is displayed. If the user checks it, the following details get auto-populated and the screen skips to the proof of Identity page.

Common PT integration with TL: After entering the trade details, users have the option to either search and integrate the already created property or create new lightweight property data for the trade license. This step can be skipped and users can proceed with the normal address details flow.

Address Details Flow - In the next flow, users have to enter the trade address details. This flow is straightforward, without any conditional routing.

Users can pinpoint the location in the Geo-location map, according to which pin code and city, as well as locality, is auto-filled.

Owner Details Flow - Finally, the users need to enter the trade owner details. Ownership can be Single or Multiple Owners. According to which the details are filled.

In the case of single/multiple owners, the following screen is displayed. The remaining flows remain the same.

Users can add multiple owners by clicking on the add owner button - a similar functionality as in trade units and accessories. The Add Owner button is not visible in case the user selects a single owner on the previous page.

The user must provide the owner's primary address and upload three documents that include address proof, owner identity and owner photograph.

Check Page and Acknowledgement Screen - Users can cross-verify the data entered throughout the flow in the Check page. Clicking on the change option adjacent to the data fields allows users to make any changes or updates to the data. The user is redirected back to a corresponding information page and the entire flow is repeated once again to submit the application.

The Applying of Trade License Create API is called. Create API snippet:1create: "/tl-services/v1/_create"

If the API response is successful, then the Acknowledgement Screen is displayed, otherwise Failed Acknowledgement Screen is displayed.

Clicking on the Download Acknowledgement Form button downloads the PDF copy of the acknowledgement.

Release 2.8 Enhancements & Changes

On the Trade Units page, values for trade type and trade subtype have been loaded by the following MDMS call:

The following validations have been added for the same :

When users select trade type and then subtype, it is compared with the available billing slab. The hook for this is given below. In case the billing slab is not there it will not allow users to move forward and an error message is displayed.

Once the correct trade type and subtype are added and the correct billing slab is there, the UOM value validation is added. This checks the value in the given range, mentioned in the billing slab object and displays an error if the value is outside of the range.

Technical Implementation Details

All screens are developed using the new-UI structure followed previously in FSM, PGR and PT, except for multi-component.

The TL (Trade License) module is segregated into a specified structure. The screen configuration is inside the PageComponent folder, and the configuration for routing of the pages are mentioned under the config folder which is common for both citizen users and employees. Below is the snippet for folder structure and routing configuration.

The pages folder is where the high-level configuration for controlling the whole flow is mentioned, for citizens and employees. Citizen flows include Create, Edit Trade, Renewal, Applications and Search Trade. The index or the starting point of the entire flow is available in this folder.

In the Accessory-details page, the Billing slab search API "/tl-calculator/billingslab/_search" is called. This returns the array list of all the accessories for which the billing slab has been configured. If the response returns an empty array then the options are curated from the MDMS API mentioned in the MDMS data section.

The Utils folder basically contains all the methods used throughout the TL module. Additional common methods can be imported and added to this folder.

For creating an application the Create API from Trade License is called using the React hooks. This is declared in the hooks/elements/TL as TLService.

MDMS Data

There are multiple pages within the workflows where data is imported from the MDMS. The table below lists the pages .js files for distinct page components.

React Hooks are used to call MDMS data that is shared across the modules. Below is the code snippet for the MDMS call.

Localization

Localization keys are added to the ‘rainmaker-tl’ locale module. In future, if any new labels are implemented in the Trade License (Citizen) it is pushed to the locale DB in the rainmaker-tl locale module. Below is an example of a few locale labels.