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

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

Upcoming Release Features

None

Reference Doc Links

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

1. Surveys section on Home Page

2. Surveys inbox

3. Create survey

   • Meta Data - Title, Description, Survey start & end date/time

   • Questions

     • Short Answer

     • Paragraph

     • Single Answer

     • Multiple choice questions

     • Date

     • Time

4. Survey Results

   • Aggregated view of all survey results in specific charts for each question type

   • Download the excel report with the survey results

5. Modify surveys

   • Survey questions

   • Extend the Survey date and time.

For Citizens

1. Notification on Survey creation.

2. Survey Filling

Known Issues/ Upcoming Enhancements

1. Expansion to other types of questions

2. More notifications to citizens prior to survey start, and survey end.

3. Making surveys open. (Right now citizens need to be logged in to fill out the survey. This needs to be made open)

Mockups

Related Doc Links

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

Upcoming Release Features

None

Reference 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

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

Mockups

Related Doc Links

Overview

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

Pre-requisites

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

• Prior Knowledge of Java/J2EE.

• Prior Knowledge of Spring Boot.

• Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.

• Prior knowledge of Git.

• Advanced knowledge of how to operate JSON data would be an added advantage to understand the service.

Key Functionalities

• State Level Masters are maintained in a common folder.

• ULB Level Masters are maintained in separate folders named after the ULB.

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

Deployment Details

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

Configuration Details

State Level Master Configuration

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

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

ULB Level Master Configuration

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

Reference Docs

Doc Links

API List

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

Introduction

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

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

No data is needed from the state team for this.

Data Table

Not Applicable

Procedure

Not Applicable

Data Definition

Not Applicable

Steps to fill data

Not Applicable

Checklist

Not Applicable

Attachments

Not Applicable

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

Example Config JSON for “Billing Service”

Reference Docs

Doc Links

API List

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

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.

Service Builds 2.9

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.

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

MDMS Changes

Config Changes

DevOps Changes

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

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

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

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

Release Highlights

Birth count report

Death count report

Birth and death certificate payment records

Release Features

Birth count report

Death count report

Birth and death certificate payment report

Known Issues

Upcoming Release Features

None

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

Overview

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

Release Highlights

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

And 3 new KPIs were added for administrative purposes.

Release Features

About page

FAQ

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

Related Doc Links

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.

4. Property mutation bug fixes

Release Features

None

Known Issues

Bug

Upcoming Release Features

None

Reference Doc Links

Overview

UI/ UX revamp of bill amendment.

Release Highlights

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

Release Features

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

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

All content on this page by is licensed under a .

Learn how to setup DIGIT master data.

DIGIT environment setup is conducted at two levels.

Yearly Roadmap

Commitment and transparency are deeply ingrained values defining our product development approach. We are constantly developing new capabilities to facilitate the digital transformation of our cities. Take a glimpse into our DIGIT Urban Mission Roadmap to learn more about our upcoming tools and features.

Explore our urban roadmap detailed view below.

Key configurations at the state level include -

All content on this page by is licensed under a .

Introduction

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

Data Table

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning as given in this document under section 'Data Definition'.

3. Make sure all the headers, its data type, field size and its definition/ description are understood properly.

4. In case of any doubt, please reach out to the person who has shared this document with you and discuss the same to clear out the doubts.

5. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

6. Verify the data once again by going through the checklist by taking care of each and every point mentioned in the checklist.

Checklist

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

Common Checklist

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

Entity Specific Checklist

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

Attachments

Objective

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

Audience

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

1. State Team

2. eGov Onsite Team/ Implementation Team

3. ULB Team (Nodal and DEO)

4. Implementation Partners

Output Artefacts

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

All content on this page by is licensed under a .

Introduction

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

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

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

Data Table

Not applicable.

Procedure

Not applicable.

Checklist

Not applicable.

Attachments

Not applicable.

All content on this page by is licensed under a .

Introduction

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

This module facilitates payments and lookup of transaction status.

Data Table

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

Procedure

Data Definition

Steps to fill data

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

1. The client has to finalize a payment gateway vendor (for example PAYU, Paytm, HDFC, AXIS atc.) depending upon the requirements.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. After which the details/ documents mentioned in the template would be provided by the vendor.

5. These details are to be received separately for both prods as well as UAT.

6. Get the IP address for UAT and Production environments whitelisted from the vendor.

7. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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

Common Checklist

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

Entity Specific Checklist

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

Attachments

Introduction

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

Data Table

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

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Ask the state team/client to create an email account on Gmail.

5. Ask the client to log in to the google play console and make the required payment so that further tasks could be processed.

6. Ask the client to share the email id and password in the template.

7. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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

Common Checklist

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

Entity Specific Checklist

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

Attachments

Introduction

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

Data Table

Procedure

Data Definition

Steps to Fill Data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.

3. Make sure all the headers, its data type, field size and its definition/ description are understood properly.

4. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.

5. Identify all the departments in ULB well before start filling then into the template.

6. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

7. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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

Common Checklist

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

Entity Specific Checklist

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

Attachments

Introduction

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

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

Data Table

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

Procedure

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

Data Definition

Steps to fill data

Following are the steps which are to be followed:

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. If the state agrees to host the website on their server, provide them with the 2 columns mentioned in the attached template.

5. If the state disagrees to host on their server, then a domain name has to be purchased by any of the external vendors and the EXTERNAL-IP address has to be mapped with them.

6. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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

Entity Specific Checklist

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

Attachments

Introduction

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

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

Data Table

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

Procedure

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

Data Definition

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

Steps to fill Data

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

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. The SMS vendor has to provide the data in the data template attached.

5. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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

Common Checklist

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

Entity Specific Checklist

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

Attachments

Overview

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

Pre-requisites

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

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

Deployment Details

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

Configuration Details

Creating Master JSON

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

Configuring The Master Config File

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

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

Reference Docs

Doc Links

Introduction

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

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

1. Labels

2. Messages: Alert messages, success messages, validation messages and other notifications etc.

3. Help Texts

Data Table

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Present the client the full sheet of codes as well as the English language for which the localized texts are required.

5. Ask the client to fill the localized text in the last column which is the message(local language) column.

6. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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

Entity Specific Checklist

Not Applicable

Attachments

Introduction

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

Data Table

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.

3. Make sure all the headers, its data type, field size and its definition/ description are understood properly.

4. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.

5. Identify all the designations exists in the ULB, refer to governments gazette to define the designations in ULBs.

6. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

7. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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

Common Checklist

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

Entity Specific Checklist

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

Attachments

Introduction

This is the next step after collating all the boundary hierarchies which are being used in the state. In a hierarchy, there are certain types of boundary classification and in all the levels there will be a mapping which we could define as a parent-child mapping in order to link certain levels of the classification.

For example, a hierarchy could be:

Administration Hierarchy: City/ULB → Zone → Ward → Locality

In the above-mentioned hierarchy, a City/ULB is being divided into different into zones followed by zones into wards and at the end wards into the locality.

Data Table

Data has to be collected for every boundary hierarchy type and boundary type with a mapping between the boundary code and its parent boundary code. Following is the table which is to be used across all the hierarchy types.

Procedure

Data Definition

Following is the definition of the data columns which are being used in the template:

Steps to fill data

Following are the steps which should be used to fill the template:

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. After Identifying all the boundary hierarchy, get the sub-classification of all the hierarchies.

5. Figure out the codes for all the sub-classification for a particular city/ULB.

6. Start filling the template from the top of the hierarchy in a drill-down approach.

7. A parent-child mapping code has to be created for every boundary level except for the top level.

8. Follow the steps until you reach the last sub-classification.

9. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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

Common Checklist

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

Entity Specific Checklist

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

Attachments

Introduction

At times in the different modules, there is a need to capture the address of the user’s place of residence or where the person is doing a trade, for which the user has to enter his/her full address which creates a task. In order to simplify the process, we can have google map geolocation service in place which would help us get the exact coordinates of the place on the map and help us identify the place.

This service is paid and the client has to purchase the below items:

Data Table

Note:

Procedure

Data Definition

Steps to fill the data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Ask the clients to purchase the above-mentioned APIs in the Introduction section.

5. Get the details for the API URL and key from the client.

6. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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

Common Checklist

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

Entity Specific Checklist

Not Applicable

Attachments

Introduction

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

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

Data Table

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

Procedure

Data Definition

Steps to fill Data

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

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Ask the state to gather all the data related to the technical configuration from the email server settings.

5. Get the attached template filled from the state and a sample data is provided in the data table section for reference.

6. The data would be available in the POP and IMAP account settings at the server level.

7. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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

Common Checklist

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

Entity Specific Checklist

Not Applicable

Attachments