Overview

This page contains the changes related to core and municipal services along with the MDMS, DevOps and configuration setups required to accommodate multi-tenancy. Browse through the details below to learn more about the Central Instance.

Refer to SAAS Guidelines for Central Instance to find additional information.

Migration Steps

Service-request Module - Citizen Feedback Module

The service-request module is required for the surveys to work. Follow the steps given below:

1. Add the Service-request module

2. Add the new persister file: service-request-persister

3. Add the Helm chart

4. Configure the build

- name: "builds/digit-dev/core-services/service-request"
    build:
      - work-dir: "core-services/service-request"
        image-name: "service-request"
        dockerfile: "build/maven/Dockerfile"
      - work-dir: "core-services/service-request/src/main/resources/db"
        image-name: "service-request-db"

1. Make the role action-mapping changes in the MDMS

Access Control Actions Test

Access Control Role Actions

1. Click on the Job-builder once the above steps are complete.

2. Restart the following services: egov-accesscontrol, egov-mdms-service, egov-persister

3. Deploy the service-request module build

   For further details on how to use Citizen-feedback APIs refer to the Citizen Feedback service.

4. Create the Citizen Feedback Service definitions (as mentioned in the above Citizen Feedback Service document) for modules and flows as per requirement before using it on the UI.

New KPIs

1. Refer to KPIs: Pendancy, Citizen Feedback and Pt-SLA changes and make changes as per the document.

2. Restart dashboard analytics with Cluster-configs.

UI Migration Changes

• Central Instance:

Find the details for prepping the UI build for a new instance.

UI build preparation for a new instance

• Citizen Consent Form:

This feature allows citizen users to give their consent at the time of logging in.

Add this MDMS file

Documentation: a. Refer to Citizen Consent Form b. Restart MDMS and deploy the latest front-end builds.

• Citizen Feedback:

A functionality that allows users to provide the user facility to submit feedback/ratings at the end of the service.

Add the MDMS file available here: https://github.com/egovernments/egov-mdms-data/blob/QA/data/pb/common-masters/RatingAndFeedback.json

{
  "tenantId": "pb",
  "moduleName": "common-masters",
  "RatingAndFeedback": [
    {
      "type": "isCitizenRatingEnabled",
      "value": true
    },
    {
      "type": "headerByRating",
      "value": [
        {
          "minvalue": 1,
          "maxvalue": 3,
          "code": "CS_WHAT_WENT_WRONG"
        },
        {
          "minvalue": 4,
          "maxvalue": 5,
          "code": "CS_WHAT_WENT_GOOD"
        }
      ]
    },
    {
      "type": "enabledScreensList",
      "value": [
        {
          "module": "PT",
          "bussinessService": "PT_CREATE",
          "screenfrom": "pt/property/new-application/acknowledgement",
          "cardHeader": "PT_RATE_HELP_TEXT_CREATE",
          "cardText": "PT_RATE_CARD_TEXT_CREATE"
        },
        {
          "module": "PT",
          "bussinessService": "PT_MUTATION",
          "screenfrom": "pt/property/property-mutation/acknowledgement",
          "cardHeader": "PT_RATE_HELP_TEXT_MUTATE",
          "cardText": "PT_RATE_CARD_TEXT_MUTATE"
        },
        {
          "module": "PT",
          "bussinessService": "PT_UPDATE",
          "screenfrom": "pt/property/edit-application/acknowledgement",
          "cardHeader": "PT_RATE_HELP_TEXT_UPDATE",
          "cardText": "PT_RATE_CARD_TEXT_UPDATE"
        },
        {
          "module": "PT",
          "bussinessService": "PT",
          "screenfrom": "digit-ui/citizen/payment/success",
          "cardHeader": "PT_RATE_HELP_TEXT_PAY",
          "cardText": "PT_RATE_CARD_TEXT_PAY"
        }
      ]
    }
  ]
}

In the provided configuration, the parameter headerByRating is utilized to specify the value for the star condition, along with the corresponding message to be displayed on the UI screen. The enabledScreensList parameter is used to indicate the specific flows where the Citizen feedback screen will be presented, allowing citizens to provide reviews.

The rating component is utilized for displaying star ratings on the citizen feedback screen. You can locate this component within the micro-ui-internals folder on the following GitHub link: Rating.js.

Documentation

a. Refer to Citizen Feedback Documentation for more details.

b. Restart MDMS and deploy the latest front-end builds.

Overview

The page assumes that the deployment of the central instance will happen in a Kubernetes-based environment independent of whether it’s a cloud-based or a bare metal deployment with a Kubernetes-based orchestrator. This page lists all types of services available in a DIGIT SAAS package and the steps to deploy, implement, and add a new service.

Useful Terms

Namespace/deployment-space - refers to the Kubernetes namespace or the equivalent by establishing access restrictions.

State/Tenant - A state is a separate entity whose applications and data are separated from the rest by namespaces and schemas in the database.

Deployment Setup

1. Backbone Services - The backbone services include Kafka, Redis, and Elastic stack. The number of deployments and the namespace where the services will be deployed are taken care of by the deployment manager itself.

2. State Deployment space - Namespace - In DIGIT SAAS, the private application/deployment space (namespace in K8s & schema in DB) is provided for different tenants (states) when they onboard, the steps to create and provide the same are mentioned in the following document.

3. Central/Shared Services - In DIGIT SAAS, each new tenant is given a separate namespace, but most use some unmodified out-of-box services provided by DIGIT deployed in a shared space known as the central namespace. These sets of services include some of DIGIT’s core services and registries. Among the services mentioned some can never be modified by the state (tenant) actors and some can be modified. In case of any modification, the services should be deployed in their own space.

   • 1.3.1 The unmodifiable core services are listed below:

     • user(egov-user + egov-otp + user-otp )

     • API-Gateway(Zuul + Access Control + nginx-ingress controller)

     • Internal gateway

     • Workflow

     • Persister

     • Indexer

     • Report

     • Searcher

     • HRMS

     • Localisation

     • Location

     • NDSS

     • MDMS

The above-mentioned services cannot be modified by the state actors and should only be deployed in the central/shared namespace.

• The modifiable registries

  • Registries of any kind are provided by eGov out of the box and are not customized by the state actors. for ex property-registry, TradeLicense-registry etc..,

  • These registries should be deployed in the central namespace to improve usage and reduce cost.

  • When there are modifications to the service then the same has to be deployed in the state’s own deployment space.

4. State services

The services that are by default deployed and run in the state namespaces whether there are modifications or not. Since they have functionalities that are directly related to the specific requirement of the state.

These services can be divided into multiple categories -

• User Interface - The DIGIT UI by default requires customisation related to the state(tenant), hence will always be deployed in state-specific deployment spaces.

• Core state services (Unmodifiable) - The DIGIT core services will be deployed in state-specific deployment spaces due to their nature of being dependent on the state(tenant) base configs.

  • MDMS

  • Notification SMS

  • Notification email

  • User event

  • IDgen

  • Payment gateway service

• Utility services - The utility services are always state config dependent hence they will be deployed in the state-specific spaces.

  • Pdf

  • Inbox

  • DSS

  • EDCR

  • Finance

• Calculators - The calculation logic requirement will mostly change along with the state-specific configs hence they are by default deployed in state-specific spaces.

  • Property

  • Trade License

  • Water

  • Sewerage etc..

Configuration Setup

The DIGIT applications require different types of config setup, they are as follows the MDMS data, persister, indexer, pdf, report, searcher and internal gateway.

1. MDMS Data

The MDMS data is required for the Master data management service to supply the data required by other modules to perform their basic validation and verify the validity of the data. The prescribed format of the same can be found in the application setup. Since the application is deployed in all the namespaces central and state. Each deployment will need its own GitHub repo.

Central MDMS - central MDMS repo

State 1 MDMS - state1 MDMS repo

2. Persister & Indexer

The persister and indexer configuration for all states should be added in a single GitHub repo in the same branch. Since both applications run in a single place. Each state deployment will have to modify their KAFKA topic names with a prefix of their state schema name.

3. PDF

The pdf configs have to be added in a separate repository since the format of pdfs printed will change with each different tenant.

4. Report & Searcher

The configs of report and searcher have to be added in the same GIT repo and same branches as the persister and indexer. The additional change that needs to be done here is that their URL should be appended with state schema names like the topic names with persister config.

5. Internal Gateway

The internal gateway config should be added to the central git config repo since the app is deployed in the central namespace.

Development Guide

The development of any service in DIGIT should be based on this development guide.

1. Common Update For All Services

The following library versions are a minimum requirement before any service can be made central instance compatible.

Changes to pom.xml

1. Add Tracer 2.1.1 and above

<dependency>
	<groupId>org.egov.services</groupId>
	<artifactId>tracer</artifactId>
	<version>2.1.1-SNAPSHOT</version>
</dependency>

1. Services-common 1.1.0 and above

<dependency>
	<groupId>org.egov.services</groupId>
	<artifactId>services-common</artifactId>
	<version>1.1.0-SNAPSHOT</version>
</dependency>

1. MDMS-Client 0.0.4 and above

<dependency>
	<groupId>org.egov</groupId>
	<artifactId>mdms-client</artifactId>
	<version>0.0.4-SNAPSHOT</version>
</dependency>

1. ENC-Client 2.04 and above

<dependency>
	<groupId>org.egov</groupId>
	<artifactId>enc-client</artifactId>
	<version>2.0.4-SNAPSHOT</version>
	<exclusions>
		<exclusion>
			<groupId>org.springframework.kafka</groupId>
			<artifactId>spring-kafka</artifactId>
		</exclusion>
		<exclusion>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-clients</artifactId>
		</exclusion>
	</exclusions>
</dependency>

2. Multi-Schema Services List

The following document helps to make multi-environment applications (Services which will run in the DIGIT namespace but store their data in state-specific namespaces of DB based on tenant-id) central instance compatible. These services include the likes of -

1. Billing-service

2. Collection-service

3. workflow-service

4. egov-apportion-service

5. egov-hrms

6. All the municipal registries

7. Property-services

8. TL-services

9. PGR-services

10. bpa-services

11. echallan-services

12. firenoc-services

13. land-services

14. noc-services

15. sw-services

16. ws-services

Any service that needs to share its data among multiple DB schemas can be added to the above category.

3. Migration Changes For Multi-Schema Services

Certain services in Central-instance will only be deployed in the central (DIGIT) namespace but their data needs to be stored in different schema belonging to different state namespaces. The migrations of foretold services need to be run in all Required schemas(i e namespaces who want to make use of the centrally deployed services). To enable the above functionality the following changes are required.

1. Migrate.sh

This file is needed for building migration docker image is located in the DB folder of resources. eg: property-services/src/main/resources/db/migrate.sh. Update the file with the following contents:

#!/bin/sh
baseurl=$DB_URL
echo "the baseurl : $DB_URL"
schemasetter="?currentSchema="
schemas=$SCHEMA_NAME
echo "the schemas : $schemas"
for schemaname in ${schemas//,/ }
do
    echo "the schema name : ${baseurl}${schemasetter}${schemaname}"
    flyway -url=${baseurl}${schemasetter}${schemaname}  -table=$SCHEMA_TABLE -user=$FLYWAY_USER -password=$FLYWAY_PASSWORD -locations=$FLYWAY_LOCATIONS -baselineOnMigrate=true -outOfOrder=true -ignoreMissingMigrations=true migrate
done

1. values.yml

The DB configuration is by default provided in the common values.yml file in the helm chart and need not be edited in normal scenarios. Since we are injecting the multiple schema list for app-specific purposes all the DB-migration ENV variables should be overridden in the app-specific values.yml file.

#Values.yml of the specific service before multiple schema changes

# Init Containers Configs
initContainers:
  dbMigration:
    enabled: true
    schemaTable: "property_services_schema"
    image:
      repository: "property-services-db"

#Values.yml of the specific service after multiple schema changes.

# Init Containers Configs
initContainers:
  dbMigration:
    enabled: true
    schemaTable: "property_services_schema"
    image:
      repository: "property-services-db"
    env: |
        {{- if index .Values "property-ismultischema-enabled" }}        
        - name: SCHEMA_NAME
          value: {{ index .Values "property-schemas" | quote }}
        {{- end }}
        - name: "DB_URL"
          valueFrom: 
            configMapKeyRef: 
              name: egov-config
              key: db-url
        - name: "SCHEMA_TABLE"
          value: {{ .Values.initContainers.dbMigration.schemaTable | quote }}              
        - name: "FLYWAY_USER"
          valueFrom: 
            secretKeyRef: 
                name: db
                key: flyway-username
        - name: "FLYWAY_PASSWORD"
          valueFrom:
            secretKeyRef: 
                name: db
                key: flyway-password
        - name: "FLYWAY_LOCATIONS"
          valueFrom: 
            configMapKeyRef: 
                name: egov-config
                key: flyway-location

Only the - name: SCHEMA_NAME variable needs to be added and other fields can be copied from the common values.yml as it is without any changes. The above file contains an if-else condition with two new variables

{{- if index .Values "property-ismultischema-enabled" }}        
- name: SCHEMA_NAME
  value: {{ index .Values "property-schemas" | quote }}
{{- end }}

The "property-ismultischema-enabled" Boolean value to check if the feature is enabled and "property-schemas" to derive the value from respective environments YAML. This example of two variables should be named differently based on service-name to avoid conflicts.

1. Environments.yml

In the respective environment’s file add the two new variables, one for the if condition and the other field for actual values under the respective service names. Lines 6 and 7 are the sample values provided here.

eg :

property-services:
  property-schemas: 'public,statea,stateb'
  property-ismultischema-enabled: 'true'

4. Code Changes For Multi Schema Services

Any services that could potentially be commonly used by all environments in the central instance (refer to Multi Schema Service List for details).

Application.properties variables to be added.

1. state.level.tenantid.length=2 State-level tenant value will be picked from the full tenant-id separated by the '.' dot. once the tenant-id is separated by a dot the resulting array of sizes given above will be considered state level.

2. is.environment.central.instance=true

   Declares whether the environment in which the service is deployed belongs to a central-instance kind of setup.

3. The both above said variable has to be overridden in the values YAML file of the respective service to pick up the values from the environment.

  {{- if index .Values "global" "is-environment-central-instance" }}        
  - name: IS_ENVIRONMENT_CENTRAL_INSTANCE
    valueFrom:
      configMapKeyRef:
        name: egov-config
        key: is-environment-central-instance
  {{- end }}
  {{- if index .Values "global" "is-environment-central-instance" }}        
  - name: STATE_LEVEL_TENANTID_LENGTH
    valueFrom:
      configMapKeyRef:
        name: egov-config
        key: state-level-tenantid-length
  {{- end }}

1. The host of the state-specific services referred by this service should be changed to the internal gateway host for tenant-based(namespace) redirection.

  - name: EGOV_MDMS_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: internal-gateway

Sample values YAML file to refer to the above-said changes

1. If this service allows the search of data without tenant-id then the following validation should be added to all the search APIs belonging to the service. searches without state-level tenant-id (as described by this variable - state.level.tenantid.length) will render the application useless, so the following is mandatory

if(configs.getIsEnvironmentCentralInstance() && criteria.getTenantId() == null) 
  throw new CustomException("EG_PT_INVALID_SEARCH",
                                      " TenantId is mandatory for search ");
                                      
else if(configs.getIsEnvironmentCentralInstance() 
    && criteria.getTenantId().split("\\.").length < configs.getStateLevelTenantIdLength())
 throw new CustomException("EG_PT_INVALID_SEARCH",
       " TenantId should be mandatorily " + configs.getStateLevelTenantIdLength() + " levels for search");

1. Update the Kafka producer in the service with the following code to enable the service to post to a tenant(namespace) specific topic based on the tenant-id.

@Service
@Slf4j
public class Producer {

	@Autowired
	private CustomKafkaTemplate<String, Object> kafkaTemplate;
	
	@Autowired
	private PropertyConfiguration configs;

	public void push(String tenantId, String topic, Object value) {

		String updatedTopic = topic;
		if (configs.getIsEnvironmentCentralInstance()) {

			String[] tenants = tenantId.split("\\.");
			if (tenants.length > 1)
				updatedTopic = tenants[1].concat("-").concat(topic);
		}
		log.info("The Kafka topic for the tenantId : " + tenantId + " is : " + updatedTopic);
		kafkaTemplate.send(updatedTopic, value);
	}
} 

1. Replace all the table names in the queries present with the {schema} placeholder

private static String PROEPRTY_AUDIT_QUERY = "select property from {schema}.eg_pt_property_audit where propertyid=?";

1. Add the following Schema replacer utility method and use the same to replace all queries with the respective schema.

/* * add this variable to your constant class */
public static String SCHEMA_REPLACE_STRING = "{schema}"; /** * Method to fetch the state name from the tenantId * * @param query * @param tenantId * @return */
public String replaceSchemaPlaceholder(String query, String tenantId) {
    String finalQuery = null;
    if (tenantId.contains(".")) {
        String schemaName = tenantId.split("\\.")[1];
        finalQuery = query.replace(Constants.SCHEMA_REPLACE_STRING, schemaName);
    } else {
        finalQuery = query.replace(Constants.SCHEMA_REPLACE_STRING.concat("."), "");
    }
    return finalQuery;
} 

/* * Sample method example to replace query with schema */
public List < String > getPropertyIds(Set < String > ownerIds, String tenantId) {
    List < Object > preparedStmtList = new ArrayList < > ();
    String query = queryBuilder.getQuery(ownerIds, tenantId, preparedStmtList);
    query = util.replaceSchemaPlaceholder(query, tenantId);
    return jdbcTemplate.queryForList(query, preparedStmtList.toArray(), String.class);
}

1. Change the persister config to alter the Kafka topic names for the configs belonging to your respective multi-schema service. The Kafka topic name should be appended with the schema name of the respective state schema.

5. Central Instance Enabled Development

Whether a service is going to be deployed in a central instance or not, it should follow and integrate with the central instance util library of common services.

1. Refer to the common update document 3.1 General update for services to be Central-Instance compatible.

2. Make use of centralInstanceUtil class to perform any tenantId manipulations. Manual manipulation of tenantId is to be avoided for common purposes like getting state-level tenantId, and state-specific Kafka topics. Read the following methods from MultiStateInstanceUtil class found in the common-services package and make use of them as mentioned in the document.

1. New environment variables are to be added mandatorily for environments.

is.environment.central.instance=false
state.level.tenantid.length=2
state.schema.index.position.tenantid=1

1. The environment should be set to false when the current server is not for multi-state(non-central-instance), disabling and enabling this make the methods in the multiStateUtil class behave as required.

2. The state-level tenant length describes what part of the whole tenantId is representing the state part. for eg: in tenantId “in.statea.tenantx”. in.statea represents the state part so the value will be 2.

3. The schema index position points to the substring of the tenantId whose value represents the schema name of the database for the given state.

Release Summary

DIGIT 2.9 release includes the following changes:

• Citizen Consent Form

• Citizen Feedback Rating

• KPI List (National Dashboard)

  • Citizen Feedback Score

  • Citizen Service Delivery Index

  • Aggregated SLA

  • Pendancy

• mCollect Pdf -QR code bug fix/alignment issues.

• OBPS- bug fixes

• TL - bug fixes

• PT - bug fixes

• Finance - bug fix

• Central Instance-related changes for modules - Property Tax, Trade License, PGR, OBPS, Water and Sewerage, Fire NOC, Birth and Death, mCollect, Reports, Inbox.

New ‌Feature Additions

Enhancements

‌Document Resources & Links

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

DIGIT is an open-source platform licensed under the MIT license (https://opensource.org/licenses/MIT) 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:

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.

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

Service Builds 2.9

DIGIT Urban 2.9 release has a new following features:

• DIGIT Urban 2.9 Beta Features

• DIGIT as a Service

• Bug Fixes

NUDM Roll Out

NUDM Team has shared following requirements for upgrading UPYOG with Central Instance:

*Conditions for Upgrading UPYOG with Central Instance

• Role & Access Management at Cluster Level so that each State SI is able to do its scope of work

• Role & Access Management at Logs Level so that each State SI is able to do its scope of work

• Role & Access Management at Elastic Search & Kibana Level so that each State SI is able to do its scope of work

• Enhancement & verification of Product default Kafka with more nodes, partitions, etc so that it sustains and perform for National Level traffic

• Enhancement & verification of Product default ElasticSearch with more nodes, shards, etc so that it sustains and perform for National Level traffic

• Availability of all States data in its own DB schemas and same should apply with ElasticSearch

• Others enhancements so that State Infra & DevOps team should be able to manage their resources independently

Adoption Metrics

Success Metrics

National Dashboard New KPIs

Citizen Feedback

Citizen Consent Form

Central Instance

No additional test cases have been added for the central instance. The existing test cases should work for the central instance as is.

MDMS Changes

Config Changes

DevOps Changes

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

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

1. My Connections

2. My Applications

3. My Payments

4. My Bills

5. Search and Pay

6. Apply for a new connection

7. Apply for disconnection

8. View Connection Details

9. View Consumption Details

10. View Application Details

11. Pay Water and Sewerage Bill

12. Pay Application Fee

Employee

1. Water Inbox

2. Sewerage Inbox

3. Apply for a new connection

4. Modification of connection

5. Bill Amendment

6. Application Workflows

7. Search Connection

8. Search Application

9. View Connection Details

10. View Consumption Details

11. Add Meter Reading

12. View Application Details

13. Collect Application Fee

14. Collect Water and Sewerage Bill

Downloads/ PDFs

1. Connection Details

2. Application Acknowledgement/ From

3. Estimation Notice

4. Sanction Letter

New Features Added

1. Disconnection of water and sewerage connection.

2. Disconnection Notice PDF

3. Application acknowledgement/form PDF

Reports

1. Receipt Register

2. Collection Register

3. Defaulters Report

Data Privacy

1. Masking of PII data

2. Option to unmask the PII data

3. 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

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.

1. FAQs

   • List of FAQs for each module

2. How it works

   • List of user manuals, help videos etc (Also in local language)

3. Link to access service via WhatsApp

4. Helpline Numbers

5. Address of Service Centres

   • Link to navigate to google maps

6. Static data

   • Ex. Days to process applications/ Amount to pay while applying etc

7. 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

Related Doc Links

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.

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

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.

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

Creating Masters data

Reference Docs

Doc Links

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