1 of 21

Introducing Local Governance

The digital local governance solution

About Local Governance

The DIGIT-powered local governance solution catalyses digital transformation across towns and cities - changing how citizens interact with government bodies. As a digital public good, the DIGIT Local Governance stack fosters an open digital ecosystem, enabling co-creation and deployment of locally relevant solutions that enhance business operations and improve overall quality of life. By transforming local governance, this initiative not only elevates citizen well-being but also accelerates the nation's economic growth.

Useful Links

Contact Us

Release Notes

v2.9 - new release features, enhancements, and fixes

Release Summary

Local Governance 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 (demand-based revenue collection) Pdf -QR code bug fix/alignment issues
Residential Construction Permit System - bug fixes
Local Business License Issuing System - bug fixes
Property Tax System - bug fixes
Finance - bug fix
Central Instance-related changes for modules - Property Tax, Trade License, Citizen Complaint Resolution System, Residential Construction Permit System, Water and Sewerage Connections, Fire Safety Certification, Birth and Death, mCollect, Reports and Inbox.

New ‌Feature Additions

Feature

Description

Citizen Consent Form

This feature is to get a consent from the citizen during the citizen login

Citizen Feedback Rating

This feature is focused to get a citizen rating when a service is completed.

NDSS KPIs

This includes

Citizen Feedback Score
Citizen Service Delivery Index
Aggregated SLA
Pendancy

Central Instance

This feature includes changes related to central instance for modules - Property Tax, Trade License, PGR, OBPS, Water and Sewerage, Firenoc, Birth and Death, mCollect, Reports, Inbox

Enhancements

Updated Feature

Description

‌Document Resources & Links

UI Technical Documents

Backend Service Documents

New Docs

Master Migration Document

2.9 release master migration document

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:

Add the Service-request module
Add the new persister file: service-request-persister
Add the Helm chart
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"

Make the role action-mapping changes in the MDMS

AccessControl Actions Test

AccessControl Role Actions

Click on the Job-builder once the above steps are complete.
Restart the following services: egov-accesscontrol, egov-mdms-service, egov-persister
Deploy the service-request module build
For further details on how to use Citizen-feedback APIs refer to the Citizen Feedback service.
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.

Note: Service definition creation is a backend task that requires sending an API request using tools like Postman. This task is typically performed once during the initial setup process.

New KPIs

Refer to KPIs: Pendancy, Citizen Feedback and Pt-SLA changes and make changes as per the document.
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.

DIGIT SAAS Guideline - Central Instance

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

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

Persister Topic Name

State 1

State 2

save-property

state1-save-property

state2-save-property

update-property

state1-update-property

state2-update-property

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.

State 1

State 2

reportName: AssetImmovableRegister

state1_AssetImmovableRegister

state2_AssetImmovableRegister

- name: billswithaddranduser

state1_billswithaddranduser

state2_billswithaddranduser

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

Add Tracer 2.1.1 and above

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

Services-common 1.1.0 and above

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

MDMS-Client 0.0.4 and above

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

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 -

Billing-service
Collection-service
workflow-service
egov-apportion-service
egov-hrms
All the municipal registries
Property-services
TL-services
PGR-services
bpa-services
echallan-services
firenoc-services
land-services
noc-services
sw-services
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 the 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 (for instance: namespaces that want to make use of the centrally deployed services). To enable the above functionality the following changes are required.

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

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.

values.yaml - the full updated sample file can be found here

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

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.

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.
is.environment.central.instance=true
Declares whether the environment in which the service is deployed belongs to a central-instance kind of setup.
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 }}

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

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");

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);
	}
}

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=?";

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);
}

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.

Refer to the common update document 3.1 General update for services to be Central-Instance compatible.
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.

228KB

MultiStateInstanceUtil.pdf

PDF

Open

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

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.
The state-level tenant length describes what part of the whole tenantId represents the state part. for eg: in tenantId “in.statea.tenantx”. in.statea represents the state part so the value will be 2.
The schema index position points to the substring of the tenantId whose value represents the schema name of the database for the given state.

MDMS & Configuration Updates

MDMS & Configuration Updates for 2.9 Release

MDMS Changes

Feature

Service Name

Changes

Description

DIGIT 2.9 release changes.

Citizen Feedback & Citizen consent form

, , , , , ,

Config Changes

Feature

Service Name

Changes

Description

DIGIT 2.9 release changes.

Citizen Feedback & Citizen consent form

DSS

, , , , , , , , , , , , , , , , , , , ,

mCollect Pdf - QR Code Bug Fix

Internal Gateway Config

DIGIT 2.9 release changes.

DevOps Changes

Feature

Service Name

Changes

Description

DIGIT 2.9 release changes.

DSS

, , , , , , , , ,

Service Build Updates

Service build details for 2.9 Release

Service Builds 2.9

Test Cases

DIGIT 2.9 Release Test Cases

National Dashboard New KPIs

Citizen Feedback

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.

Gate 2 Release Checklist

DIGIT 2.9 Gate 2 Release Checklist

S.No.

Checklist

Yes/No/Partially

Reference Link

Owner

Reviewer

Remarks

Development is completed for all the features that are part of the release.

Yes

@Kaviyarasan P

Code is frozen by APR-2023

Test cases are documented by the QA team, and reviewed by the product owners and test results are updated in the test cases sheet.

Yes

@Gurjeet Singh

@Priyanka Samantaroy

No new test cases for central instance are there. All existing test cases should work as is.

The incremental demo of the features showcased during the sprint showcase and feedback incorporated. If possible list out the JIRA tickets for feedback.

Yes

@Kaviyarasan P

Demo given on 18-APR-2023 for Citizen Feedback Citizen Consent Form DSS New KPIs. Central Instance - No demo required.

UI/UX Audit review by UX Architect is completed along with feedback incorporation for any changes in UI/UX.

Yes

@Andrew Jones

@Vamshikrishna Kole

UI/UX audit is done and review comments are incorporated.

Incremental demos to the product owners are completed as part of the sprint and feedbacks are incorporated.

Yes

@Megha S @P. Sankar

@P. Sankar

Demo given on 18-APR-2023 for Citizen Feedback Citizen Consent Form DSS New KPIs. Central Instance - No demo required.

QA signoff is completed by the QA team and communicated to the product owners. All the tickets QA signoff status is updated in the JIRA.

Yes

@Gurjeet Singh

QA signoff was completed. Sign-off dates 14th April 2023 Citizen Feedback Citizen Consent Form DSS New KPIs Central Instance - 15th September 2023

UI, API Technical documents are updated for the release along with the configuration documents.

Yes

for central instance

@Kaviyarasan P

@Vamshikrishna Kole

UAT promotion and regression testing from the QA team is completed. QA team has shared the UAT regression test cases with the product owners.

Yes

@Gurjeet Singh

No new test cases for central instance are there. All existing test cases should work as is.

API Automation scripts are updated for new APIs or changes to any existing APIs for the release. API automation regression is completed on UAT, the automation test results are analyzed and necessary actions are taken to fix the failure cases. Publish the list of failure use cases with a reason for failure and the resolution taken to fix these failures for the release.

@Gurjeet Singh

Not picked up in this release due to lack of resources. We do not have QA resource who can write automation scripts.

The API backward compatibility testing is completed.

Yes

@Gurjeet Singh

@Kaviyarasan P

Tested on 25-AUG-2023

The communication is shared with the product owners for the completion of UAT promotion and regression by the QA team. The product owners have to give a Product signoff within one week of this communication.

Yes

@Gurjeet Singh

@KeerthiBhaskara-eGov

@Megha S

UAT signoff was completed. Sign-off dates 14th April 2023 Citizen Feedback Citizen Consent Form DSS New KPIs

Central Instance- No communication required

UAT Product Signoff communication is received from the Product owners along with the release notes and User guides (if applicable).

Yes

@Megha S

@P. Sankar

UAT product signoff for Citizen Feedback Citizen Consent Form DSS New KPIs

given on 19th April 2023

Central Instance - UAT product signoff not needed. Central Instance is a separate environment

The GIT tags and releases are created for the code changes for the release.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether the Release notes are updated

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether all UAT Builds are updated along with the GIT tag details.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether all MDMS, Configs, InfraOps configs updated.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether all docs will be Published to by the Technical Writer as part of the release.

Yes

@Kaviyarasan P,

@Pradeep Kumar,

@Ajay Rawat, @Megha S

@Anjoo Narayan

Verify whether all test cases are up to date and updated along with necessary permissions to view the test cases sheet. The test cases sheet is verified by the Test Lead.

Yes

@Gurjeet Singh

No new test cases for central instance are there. All existing test cases should work as is.

Verify whether the UAT credentials sheet is updated with the details of new Users and Roles if any

Yes

@Gurjeet Singh

No new credentials required for - Citizen Feedback Citizen Consent form DSS New KPIs

New credential for Central Instance Attached

Verify whether all the localization data was added in UAT including Hindi and updated in Release Kits.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

No new localization added for the central instance

Verify whether the product release notes and user guides are updated and published

Yes

Product Owners

The Demo of released features is done by the product team as part of the Sprint/Release showcase.

Yes

Demo given on 18-APR-2023 for Citizen Feedback Citizen Consent Form DSS New KPIs. Central Instance - No demo required.

Technical and Product workshops/demos are conducted by the Engineering and Product team to the implementation team (Implementation handover)

Yes

@Kaviyarasan P

Technical and Product workshops/demo conducted on 23-July-2023

Architect SignOff and Technical Quality Report

Yes

@Kaviyarasan P

@Ghanshyam Rawat

Signed off by @Kaviyarasan P on 31-July-2023

Success Metrics and Product Roadmap

Yes

@Ajay Rawat

Adoption Metrics

Yes

@Ajay Rawat

Program Roll-out Plan

Yes

@Ajay Rawat

@Pradeep Kumar

Implementation checklist

Yes

@Pradeep Kumar/@Vinoth

Prepared.

Implementation Roll-out plan

Yes

@Pradeep Kumar/@Vinoth

Gate 2

Yes

@Ajay Rawat

The Internal release communication along with all the release artefacts are shared by the Engineering/Product team.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Plan for upgrading the staging/demo instance with the release product - within 2-4 weeks based on the period where no demos are planned from staging for the previous version of the released product.

Yes

@Pradeep Kumar/@Vinoth

The Release communication to partners is shared by the GTM team and the Webinar is arranged by the GTM team after the release communication - within 2-4 weeks of the release.

Implementation Checklist

@Sl No

Checklist

Yes/No/Partially

Reference link

Owner

Date(mm/dd/yyyy)

Remarks

Product Release Notes

Yes

Kavi

List of services that needs to be upgraded

Yes

Kavi/Priyanka

Verified.

Verify Configs, MDMS, devOps Changes

Yes

Pradeep/Vinoth

Verified

Verify test cases for all enhancements/updates

Yes

Gurjeet

Verify performance testing report

Gurjeet

No report found

Verify backward compatibility testing report

Yes

Gurjeet

Verify the documents for released features

Yes

Pradeep/Vinoth

Backward compatibility testing by disabling central instance flag on existing environment

Yes

Vinoth/Gurjeet

Verified the backward compatibility in UAT environment by disabling the flag and deploying latest builds.

Setup fresh central instance from scratch for two states and verify

Yes

Vinoth

Verified documents and updated missing gaps in the document.

Impel-Singoff

Yes

Vinoth/Gurjeet

15/09/2023

Verified

Technical discussion on central instance with Partners

Yes

Vinoth/Pradeep

31/07/2023

Technical Discussion with NIUA and PWC team done on 31st July '23.

Demo on Release features to partners

Yes

Vinoth/Pradeep

18/05/2023

Demo Provided 18th May 2023 to Impel partners.

Staging upgradation plan

Yes

Vinoth

Deployment strategy for DIGIT 2.9

Yes

NIUA Team /Ajay

Address queries raised by partner on central instance

Queries raised by NIUA to be addressed post Gate 2 as additional effort is required.

NIUA Team /Ajay

Program Roll Out Plan

DIGIT Urban 2.9 release has a new following features:

DIGIT Urban 2.9 Beta Features
DIGIT as a Service
Bug Fixes

Task

Status

Owner

Upgrade of UPYOG with Beta features

15/05/2023

Pradeep Kumar

Session with NUDM team on Central Instance

31/07/2023

Ajay Rawat

Getting approval from partners for UPYOG upgrade with DIGIT as a Service

In Progress

Ajay Rawat

Effort Estimate for Upgrade created

Done

Vinoth

Gate 2

In Progress

Ajay Rawat

Release Communication Shared with Partners

To Do

Ajay Rawat

NUDM Roll Out

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

*Conditions for Upgrading UPYOG with Central Instance

Role & Access Management at Cluster Level so that each State SI can do its scope of work
Role & Access Management at Logs Level so that each State SI can do its scope of work
Role & Access Management at Elastic Search & Kibana Level so that each State SI can do its scope of work
Enhancement & verification of Product default Kafka with more nodes, partitions, etc so that it sustains and performs for National Level traffic
Enhancement & verification of Product default ElasticSearch with more nodes, shards, etc so that it sustains and performs for National Level traffic
Availability of all States data in its DB schemas and the same should apply with ElasticSearch
Other enhancements so that the State Infra & DevOps team can manage their resources independently.

Adoption Metrics

Feature

Metric

Estimate

Citizen Feedback

No. of states adopting feature and sharing data with National Dashboard

At least 2 states to implement the feature under NUDM in next 6 months

Consent form

Compliance to NUIS Assessment

Compliance report already shared post release of feature

Dashboard KPIs

No. of states sharing data on new KPIs

Citizen Feedback feature to be implemented in states, for KPIs to start reflecting data. 2+ states to implement the feature and share data on the KPIs

DIGIT as a Service

No. of accounts/projects using feature in all missions

At least 2 accounts use DIGIT as a Service in next 6 months

Success Metrics

Feature

Objective

Estimate

Citizen Feedback

Improvement in Citizen Satisfaction

Improvement in Metrics by 20% in first 3 years in state using the feature

Consent form

Compliance to NUIS Assessment

Compliance report already shared post release of feature

Dashboard KPIs

Improvement in Citizen Satisfaction

Improvement in Metrics by 20% in first 3 years in state using the KPIs

DIGIT as a Service

Optimizing resources for saving in infra costs

Saving to be estimated

Product Release Notes

Property Tax System Release Notes

Overview

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

Release Highlights

PRDs of 3 property tax features and bug fixes.

Property mutation bug fixes

Release Features

None

Known Issues

Bug

Upcoming Release Features

None

Reference Doc Links

Residential Construction Permit System UI/UX Revamp Release Notes

OBPS Release notes for Urban DIGIT 2.8 release.

Overview

This release offers the UI/UX revamp of the Residential Construction Permit System, workflow timeline changes and reports.

Release Highlights

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

Two reports were added for administrative purposes.

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

Notification 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

Residential construction permit 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 the action is marked as pending. The remaining status is marked as done or completed or in a submitted state.

Notification based on channels - The residential construction permit 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

Local Business License Issuing System - Release Notes

Release notes for local business license issuing system

Overview

A few reports are added to the TL module for administrative purposes.

Release Highlights

Daily collection report

Application status report

Trade license registry

Trade license renewal pending report

Release Features

Trade license daily collection report

Trade license application status report

Trade license registry

Trade license renewal pending report

Known Issues

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

Upcoming Release Features

None

Water & Sanitation UI/UX Revamp Release Notes

Overview

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

Release Highlights

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

Citizen

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

Employee

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

Downloads/ PDFs

Connection Details
Application Acknowledgement/ From
Estimation Notice
Sanction Letter

New Features Added

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

Reports

Receipt Register
Collection Register
Defaulters Report

Data Privacy

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

Release Features

Key Features

Description

Known Issues

Upcoming Release Features

None

Reference Doc Links

Link

Bill Amendment UI/UX Revamp Release Notes

Overview

UI/ UX revamp of bill amendment.

Release Highlights

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

Release Features

Key Features

Description

Inbox

UI/UX revamp of employee inbox and service wise separate inboxes.

View Application

UI/ UX revamp of the application details view.

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

Doc Links

Bill Genie UI/UX Revamp Release Notes

Overview

UI/ UX revamp of Bill Genie.

Release Highlights

UI/UX revamp of Bill Genie features.

Release Features

Features

Description

Search Bill

UI/UX revamps of searching a bill and then downloading the bill PDF. Bill amounts can also be collected.

Cancel Bill

UI/UX revamp of cancelling an active bill.

Group Bill

UI/ UX revamp of the grouping and merging of the multiple bills into single PDF.

Group W&S Bills

UI/ UX revamp of grouping and merging of related water and sewerage bill into single PDF.

Download Bill PDF

UI/ UX revamp of download PDF.

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

Doc Links

Birth & Death Reports Release Notes

Birth and death release note for Urban DIGIT 2.8.

Overview

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

Release Highlights

Birth count report

Death count report

Birth and death certificate payment records

Release Features

Birth count report

Death count report

Birth and death certificate payment report

Known Issues

Upcoming Release Features

None

National Dashboard Enhancement Release Notes

DSS release note for Urban DIGIT 2.8

Overview

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

Release Highlights

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

And 3 new KPIs were added for administrative purposes.

Release Features

About page

FAQ

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

Survey Release Notes

Overview

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

Release Highlights

The Survey module consists of the following

For Employees

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

For Citizens

Notification on Survey creation.
Survey Filling

Known Issues/ Upcoming Enhancements

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

Product Specific Pages Release Notes

Overview

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

Release Highlights

Product Specific Pages Module consists of the following:

For Citizen

For a module and tenant that is configured.

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

Known Issues/ Upcoming Features

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

DIGIT SAAS Guideline - Central Instance

Overview

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

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

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

Central MDMS - central MDMS repo

State 1 MDMS - state1 MDMS repo

2. Persister & Indexer

Persister Topic Name

State 1

State 2

save-property

state1-save-property

state2-save-property

update-property

state1-update-property

state2-update-property

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

State 1

State 2

reportName: AssetImmovableRegister

state1_AssetImmovableRegister

state2_AssetImmovableRegister

- name: billswithaddranduser

state1_billswithaddranduser

state2_billswithaddranduser

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

Add Tracer 2.1.1 and above

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

Services-common 1.1.0 and above

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

MDMS-Client 0.0.4 and above

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

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

Billing-service
Collection-service
workflow-service
egov-apportion-service
egov-hrms
All the municipal registries
Property-services
TL-services
PGR-services
bpa-services
echallan-services
firenoc-services
land-services
noc-services
sw-services
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

Migrate.sh

#!/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

values.yml

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

values.yaml - the full updated sample file can be found here

# 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

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

Environments.yml

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.

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.
is.environment.central.instance=true
Declares whether the environment in which the service is deployed belongs to a central-instance kind of setup.
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 }}

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

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");

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);
	}
}

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=?";

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);
}

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.

Refer to the common update document 3.1 General update for services to be Central-Instance compatible.
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.

228KB

MultiStateInstanceUtil.pdf

PDF

Open

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

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.
The state-level tenant length describes what part of the whole tenantId represents the state part. for eg: in tenantId “in.statea.tenantx”. in.statea represents the state part so the value will be 2.
The schema index position points to the substring of the tenantId whose value represents the schema name of the database for the given state.

Gate 2 Release Checklist

DIGIT 2.9 Gate 2 Release Checklist

S.No.

Checklist

Yes/No/Partially

Reference Link

Owner

Reviewer

Remarks

Development is completed for all the features that are part of the release.

Yes

@Kaviyarasan P

Code is frozen by APR-2023

Test cases are documented by the QA team, and reviewed by the product owners and test results are updated in the test cases sheet.

Yes

@Gurjeet Singh

@Priyanka Samantaroy

No new test cases for central instance are there. All existing test cases should work as is.

The incremental demo of the features showcased during the sprint showcase and feedback incorporated. If possible list out the JIRA tickets for feedback.

Yes

@Kaviyarasan P

Demo given on 18-APR-2023 for Citizen Feedback Citizen Consent Form DSS New KPIs. Central Instance - No demo required.

UI/UX Audit review by UX Architect is completed along with feedback incorporation for any changes in UI/UX.

Yes

@Andrew Jones

@Vamshikrishna Kole

UI/UX audit is done and review comments are incorporated.

Incremental demos to the product owners are completed as part of the sprint and feedbacks are incorporated.

Yes

@Megha S @P. Sankar

@P. Sankar

Demo given on 18-APR-2023 for Citizen Feedback Citizen Consent Form DSS New KPIs. Central Instance - No demo required.

QA signoff is completed by the QA team and communicated to the product owners. All the tickets QA signoff status is updated in the JIRA.

Yes

@Gurjeet Singh

QA signoff was completed. Sign-off dates 14th April 2023 Citizen Feedback Citizen Consent Form DSS New KPIs Central Instance - 15th September 2023

UI, API Technical documents are updated for the release along with the configuration documents.

Yes

for central instance

@Kaviyarasan P

@Vamshikrishna Kole

UAT promotion and regression testing from the QA team is completed. QA team has shared the UAT regression test cases with the product owners.

Yes

@Gurjeet Singh

No new test cases for central instance are there. All existing test cases should work as is.

@Gurjeet Singh

Not picked up in this release due to lack of resources. We do not have QA resource who can write automation scripts.

The API backward compatibility testing is completed.

Yes

@Gurjeet Singh

@Kaviyarasan P

Tested on 25-AUG-2023

Yes

@Gurjeet Singh

@KeerthiBhaskara-eGov

@Megha S

UAT signoff was completed. Sign-off dates 14th April 2023 Citizen Feedback Citizen Consent Form DSS New KPIs

Central Instance- No communication required

UAT Product Signoff communication is received from the Product owners along with the release notes and User guides (if applicable).

Yes

@Megha S

@P. Sankar

UAT product signoff for Citizen Feedback Citizen Consent Form DSS New KPIs

given on 19th April 2023

Central Instance - UAT product signoff not needed. Central Instance is a separate environment

The GIT tags and releases are created for the code changes for the release.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether the Release notes are updated

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether all UAT Builds are updated along with the GIT tag details.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether all MDMS, Configs, InfraOps configs updated.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Verify whether all docs will be Published to by the Technical Writer as part of the release.

Yes

@Kaviyarasan P,

@Pradeep Kumar,

@Ajay Rawat, @Megha S

@Anjoo Narayan

Verify whether all test cases are up to date and updated along with necessary permissions to view the test cases sheet. The test cases sheet is verified by the Test Lead.

Yes

@Gurjeet Singh

No new test cases for central instance are there. All existing test cases should work as is.

Verify whether the UAT credentials sheet is updated with the details of new Users and Roles if any

Yes

@Gurjeet Singh

No new credentials required for - Citizen Feedback Citizen Consent form DSS New KPIs

New credential for Central Instance Attached

Verify whether all the localization data was added in UAT including Hindi and updated in Release Kits.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

No new localization added for the central instance

Verify whether the product release notes and user guides are updated and published

Yes

Product Owners

The Demo of released features is done by the product team as part of the Sprint/Release showcase.

Yes

Demo given on 18-APR-2023 for Citizen Feedback Citizen Consent Form DSS New KPIs. Central Instance - No demo required.

Technical and Product workshops/demos are conducted by the Engineering and Product team to the implementation team (Implementation handover)

Yes

@Kaviyarasan P

Technical and Product workshops/demo conducted on 23-July-2023

Architect SignOff and Technical Quality Report

Yes

@Kaviyarasan P

@Ghanshyam Rawat

Signed off by @Kaviyarasan P on 31-July-2023

Success Metrics and Product Roadmap

Yes

@Ajay Rawat

Adoption Metrics

Yes

@Ajay Rawat

Program Roll-out Plan

Yes

@Ajay Rawat

@Pradeep Kumar

Implementation checklist

Yes

@Pradeep Kumar/@Vinoth

Prepared.

Implementation Roll-out plan

Yes

@Pradeep Kumar/@Vinoth

Gate 2

Yes

@Ajay Rawat

The Internal release communication along with all the release artefacts are shared by the Engineering/Product team.

Yes

@Priyanka Samantaroy

@Kaviyarasan P

Plan for upgrading the staging/demo instance with the release product - within 2-4 weeks based on the period where no demos are planned from staging for the previous version of the released product.

Yes

@Pradeep Kumar/@Vinoth

The Release communication to partners is shared by the GTM team and the Webinar is arranged by the GTM team after the release communication - within 2-4 weeks of the release.