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

Desludging Operator

Urban Local Body

Treatment Operator

Citizen

Coming soon...

All content on this page by is licensed under a .

The DIGIT Sanitation roadmap below offers a snapshot of our upcoming tools and features:

The following modules and features are part of the product roadmap:

1. Treatment Quality Monitoring: The treatment quality module aims to set up a digital system to define, record and review parameters such as tests on the samples from treatment plants (TP) by enabling on-ground actors to record, review and compare test results (on samples from the treatment plant) in the system. The information will be delivered to relevant stakeholders to bring awareness and to take action. The system will allow for real-time automated monitoring (without human intervention), with IoT sensors. The following features will be provided as part of the module:

• Plant registry

• Recording of lab testing results

• Dashboards to monitor quality

• Anomaly detection and alerts for deviation

1. Calendaring/Scheduling: Desludging/emptying of septic tanks of certain commercial and institutional properties such as community toilets, temples, etc., is a scheduled activity and performed at regular intervals. These are usually scheduled by the urban local body (ULB), and assigned to a vendor who performs the service. In some cases, the ULB owns the vehicles and employs individuals, and these requests are served by them. The calendaring/scheduling functionality will allow for:

• Automated scheduling of services

• Tracking service delivery against scheduled services

• Tracking adherence to schedule

1. Sanitation Worker Welfare (v1.0)

Sanitation workers are an integral part of the waste management ecosystem. Currently, the product is limited to capturing only drivers that are involved in transportation of waste. As part of v1.0 of the sanitation worker welfare, we want to create a record of service delivery to provide enumeration and benefits to sanitation workers. This will include:

• Building a sanitation worker registry/database

• Mapping of vendor and sanitation workers

• Mapping sanitation workers and faccal sludge treatment plants (FSTPs)

• Assigning sanitation workers to service requests

• Capturing details of unregistered sanitation workers, if not available in the database

1. Vendor as a business user: There are multiple operating models across countries and waste streams. Private vendors contribute to service delivery in waste management across multiple service categories, such as request collection, transportation, or treatment plant management. We want to enhance the product by introducing vendors as business users. The following will be the scope:

• Integrating vendor registry from DIGIT in FSM

• Mapping of vendors to multiple urban local bodies

• Mapping vendors to multiple service categories

• Vendor collecting payments from citizens based on service categories

Contribute

We are actively seeking contributions from the community in enhancing the product. Check out how you can contribute .

Mission

Enabling Samaaj, Sarkar & Bazaar partners with a digital platform that would help ensure Zero deaths, disease, and environmental contamination resulting from poor sanitation - a reality for every citizen across the Global South.

DIGIT Sanitation aims to ensure zero untreated waste in 1,000 habitats in 1,000 days by catalysing open digital ecosystems.

Overview

DIGIT Sanitation is an open-source web and mobile-enabled platform designed to digitisze operations in the waste management value chain, from collection to treatment, and provides the ability to drive coordination across multiple independent and disconnected stakeholders. This ensures that there is a continued chain of custody of waste throughout.

According to a United Nations (UN) report, only 54% of the world population have access to safe sanitation. We believe that at the heart of the problems in sanitation are ineffective systems that fail to deliver. Hence, systems must be progressively reformed. To move habitats towards zero untreated waste, we will leverage the capabilities built by the Digital Infrastructure for Governance, Impact & Transformation (DIGIT), and ensure traceability of waste by enabling the ecosystem with the following features:

• Chain of custody: We will ensure a seamless and traceable chain of custody for waste. This will enable stakeholders to track waste from its source to its final destination, ensuring accountability and transparency in the waste management process.

• Actionable data: Our system will provide actionable data on waste management operations, which will enable stakeholders to make informed decisions. This data will be used to optimize waste collection and treatment processes, identify areas for improvement, and drive evidence-based decision-making.

• Code for innovation: We will foster innovation by providing a digital platform that encourages collaboration among stakeholders. Our system will facilitate the sharing of ideas, best practices, and innovative solutions for sanitation challenges, driving continuous improvement in the waste management ecosystem.

Need for DIGIT Sanitation - Case for Platform

Current digital efforts across geographies do not take a “whole of system view” and do not solve the cost of coordination and duplication issues. Such siloed, solution-centric approaches and tools create a new set of problems and inefficiencies for countries:

• Higher costs and time: This is incurred on creating or procuring and maintaining these systems, including the onboarding cost of the same actors in each programme.

• Data exists in multiple systems: They are not interoperable, leading to duplication, inconsistencies, poor adoption by on-ground workers, and sub-optimal decision-making.

• Limited reusability and innovation: Data and capabilities are intertwined and ‘locked,’ making it extremely hard for the wider ecosystem to innovate and build upon.

• Sub-scale: The tools are not able to scale for the national population and across waste streams.

Platform Scope

DIGIT Sanitation is built on the principles of societal platforms, envisioning a space where sanitation is supported by shared resources, curated knowledge, and evolving solutions that address the needs of the community. We recognise that the challenges of sanitation are systemic and require the collective efforts of all stakeholders to be effectively addressed. Drawing from our insights gained from our urban mission, we embrace the triple helix model, which emphasises partnerships among different stakeholders, including civil society (samaaj), government (sarkaar), and industry/market (bazaar), to generate innovation through synergistic collaboration. Leveraging our experience in building large-scale public digital infrastructure, we are well-positioned to create the foundation for this ecosystem and drive progress in solving the most pressing sanitation issues. We believe that by fostering cooperation and collaboration among all stakeholders, we can create sustainable solutions that meet the needs of communities and contribute to the transformation of the sanitation landscape.

While sanitation requirements and solutions may vary among local governments, there are commonalities in the value chain of sanitation waste streams, such as Faecal Sludge Management, Solid Waste Management, Plastic Waste Management, etc. These value chains typically involve steps such as generation, containment, collection, transport, treatment, and disposal/reuse. These similarities provide an opportunity to abstract and digitise various components of the service value chain, with the potential to encode standards and enable data-driven visibility into sanitation services.

The DIGIT Sanitation platform is specifically designed to allow for contextualisation and reuse of components across different waste streams and geographies. By incorporating standards into the platform and leveraging data registries and reusable building blocks in the technology stack, applications can be developed more efficiently and quickly at the solution layer, resulting in lower costs and faster implementation. This approach enables flexibility and scalability in addressing diverse sanitation needs, while also promoting interoperability and consistency in the digital solutions deployed. By leveraging the DIGIT Sanitation platform, stakeholders can build innovative applications tailored to local contexts, while adhering to standardised components and data structures, leading to more effective and sustainable sanitation services.

Following is a glimpse of how this would work:

The above image illustrates the core infrastructure services, and the enabling services that are built/configured for a Faecal Sludge Management (FSM) solution with the following functionality:

1. Allowing citizens to request fo r septic tank desludging services.

2. Scheduling desludging services for a certain set of property types/localities, etc.

3. Automated or manual assignment of vendors to perform requests.

4. Tracking sludge from collection to disposal at a treatment plant using internet of things (IoT).

5. Notifications to stakeholders at each point in the workflow.

6. Dashboards and reports.

Now, consider that instead of FSM, a solution needs to be built for Solid Waste Management:

The same set of infrastructure and enabling services could be used to configure the following functionalities:

1. Scheduling the collection of waste based on different categories.

2. Automated or manual assignment of vendors to perform requests.

3. Tracking adherence to the schedule.

4. Tracking waste movement from pickup to disposal at a treatment facility.

5. Notifications to stakeholders at each point in the workflow.

6. Dashboards and reports.

Further, only an additional service for segregation monitoring would have to be built.

To illustrate this further, imagine building a solution for sanitation worker welfare:

The same set of services can be used here as well, with the addition of a few components. The DIGIT Sanitation platform is built leveraging the DIGIT Core Services, which are customised into the following key building blocks:

1. Service Request Management

• Define pricing

• Record service requests

• Assign and manage service requests

• Provide subsidies

• Calculate service fees

• Track status

• Collect feedback

1. Transport Management

• Schedule pickup

• Assign vehicles and drivers

• Track status

1. Billing and Payments

• Generate demand

• Generate receipts

• Online payment gateway

1. Notifications

• SMS

• In app

1. Service Delivery Monitoring

• Dashboards

• Reports

Product

Faecal Sludge Management (FSM)

Programme

Click here to know more about our SUJOG-Faecal Sludge & Septage Management (FSSM) programme in Odisha.

Click here to know more.

Click here to know more.

See our test cases below:

Release Summary

The release provides the functionality of tagging the Gram Panchayat (GP) and Villages via Urban Local Bodies (ULBs). The ULB will be servicing desludging requests for households in the respective GP.

Release Highlights

The functionality included are:

• Adding GPs while creating an application

• Make the Amount per trip field editable for GPs

New Feature Additions

Document Resources and Link

Click to access the backend service document.

Click to know more about our platform features.

The QA test cases for Urban-Rural Convergence (URC) are given below:

Click for more details.

Release Summary

This patch release provides the enhancements in the search functionality and FSM registry. Part search is enabled in the entire application to enhance user experience. The fields in the FSM registry are made editable, mandatory, and unique as per its attributes.

The enhancements included are:

• To enable part search in the entire application.

• Modify the FSM registry to make fields as mandatory, editable, and unique.

Enhancements

Click here to access the document.

This section includes the following:

• FM Citizen UI

• FSM Employee UI

• FSM DSO UI

• FSM FSTPO UI

Localisations of GP Phase-1 & Phase-2

Here are the articles in this section:

• Backend developer guide

• UI developer guide

Why contribute to DIGIT Sanitation?

DIGIT is an open-source waste management service and governance platform. It is designed to streamline interactions between citizens, government employees, service providers, administrators, and policymakers. In low capacity national and sub-national areas, in particular, government agencies do not have the ability to develop systems that can deliver services in a scalable and reliable manner. They end up building systems that are closed, locking data into departmental silos. This makes it difficult for citizens to access data, market players to provide services, and administrators and policymakers to make decisions. Each system builds common functionalities such as authentication, authorisation, location, notification, demand, and payment. These issues impact the ability of government agencies to deliver coordinated services to citizens.

DIGIT Sanitation is architected on DIGIT, a Digital Public Infrastructure, that consists of reusable micro-services:

1. Common services: Authentication, authorisation, notification, payment, workflow, etc.

2. Domain services: Individual, household, property, beneficiary, programme, etc. These services store data and make them available through APIs to any applications securely.

3. Data exchange: To avoid point-to-point integrations, it is critical to build data exchange mechanisms and standards that enable agencies to exchange data in a trusted and non-repudiable manner. This will enable all agencies to deliver services in a coordinated fashion. For example, once a birth is registered in the civil registry, the health department should automatically schedule a vaccine. Data exchanges enable seamless flow of financial and services delivered data between funding and implementing agencies in the government, streamlining the flow of money which is critical for services delivery. Lack of information results in delays in payments to frontline workers, employees, pensioners, and vendors, impacting service delivery.

Building an open-source platform like DIGIT Sanitation can enable governments in low capacity countries to deliver and govern services delivery in a scalable and reliable manner.

How can you contribute?

Develop products on top of DIGIT Sanitation

1. Solutions for traceability of waste, from pickup to disposal, at a treatment site. These may be QR code-based tracking, or vehicle-based tracking.

2. Maintenance module for scheduled and on-demand maintenance of plants.

3. Improved dashboards for administrators/governing bodies.

4. Mobile app for drivers/frontline workers involved in sanitation.

5. IoT-based tracking of quality measurement data from plants.

We will keep adding more items here. If you are interested or have any questions you post it on Discussion Board (Coming soon).

Coming soon...

Overview

The following MDMS changes have been done as part of the Urban-Rural Convergence (URC) release:

MDMS Changes

Installation Pre-reads

• Know the basics of Kubernetes: https://www.youtube.com/watch?v=PH-2FfFD2PU&t=3s.

• Know the basics of kubectl commands.

• Know Kubernetes Kubernetes Resources via YAML, Deployments, Replica Sets, and Pods: https://www.youtube.com/watch?v=ohSUtEfDefc.

• Know how to manage env values, secrets of any service deployed in Kubernetes: https://www.youtube.com/watch?v=OW244LxB4oI.

• Know how to port forward to a pod running inside k8s cluster and work locally https://www.youtube.com/watch?v=TT3nd5n5Yus.

• Know sops to secure your keys/credentials: https://www.youtube.com/watch?v=DWzJ87KbwxA.

1. Choose the Cloud

Choose your cloud and follow the instructions to set up a Kubernetes cluster before moving on to the deployment.

2. Deployment

3. Destroy the Cluster

Finally, clean up the cluster setup if you wish, using the following command. This will delete the entire cluster and other cloud resources that were provisioned for the DIGIT setup.

cd DIGIT-DevOps/infra-as-code/terraform/my-digit-eks
terraformdestroy​

Conclusion

We have successfully created infra on cloud, and deployed DIGIT in the cluster.

Module Walkthrough Videos

A complete walkthrough of the DIGIT FSM module -

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

Overview

FSM Calculator is a system that enables the FSM aAdmin to create billing slabs for the FSM application(s) with different combinations of propertytype, slum, and tank capacity, among others. It generates the demand after calculating the charges for the given application using the billing slabs already configured.

Service Dependencies:

• billing-service

• mdms-service

• workflow-v2

• User-service

• fsm

API Specification

​Data Model

Overview

Vehicle Registry is a system that enables urban local body (ULB) employees to create and search vehicle entities and schedule vehicle trips for FSM applications, and track the vehicle trip.

Service Dependencies:

• egov-mdms-service

• egov-workflow-v2

• user-service

• egov-idgen

• vendor

API Specification

​Data Model

Web Sequence Diagram

The platform is built and designed as a Digital Public Good.

The source code for the platform is hosted .

To set up the platform, follow the installation steps listed .

The current version of FSM v1.3 provides the following features:

Service Request Management (urban and rural)

• Define pricing for desludging services based on the property type, sub-type and volume, and categories where services are free/subsidised.

• Interface for citizens to request for desludging services and track service delivery.

• Interface for urban local bodies (ULBs) to record service requests received via multiple channels, and track service delivery.

• Interface for Faecal Sludge Treatment Plant (FSTP) operators to record the entry of vehicles against service requests.

• Interface for FSTP operators to record the entry of vehicles without service requests.

• Collect feedback from citizens on the completion of service delivery.

• Define and monitor against SLAs.

Transport Management

• Assignment of requests to transportation vendors.

• Interface for transport vendors to manage requests and track the status of requests.

• Assignment of vehicles and drivers to service requests.

Billing and Payments

• Calculate service fees based on the defined pricing and the number of trips.

• Define the minimum amount payable at the ULB level while requesting for services.

• Collect part payments in advance and the rest as balance.

• Interface for citizens to make payments via a payment gateway.

• Interface for ULBs to collect and record payments.

• Generate receipts.

Notifications

• Send notifications via SMS.

• Send in-app notifications.

Service Delivery Monitoring

• Dashboards at the state and ULB levels.

- View KPIs (Total requests, trends in requests, SLAs, and capacity utilisation of FSTPs, and vendor performance).

- Filters (Time, ULB)

• Reports

The following masters are also maintained as part of the product:

• Vehicle master

• Driver master

• Vendor master

• Treatment plant master

MDMS Configuration

FSTP Plant Info

The FSTP plant info contains plant operational capacity per day of each ULB and other plant-related information. It is required to calculate the FSTP capacity utilization in percentage form. MDMS file details:

egov-mdms-data/FSTPPlantInfo.json at QA · egovernments/egov-mdms-data``

{
	"MdmsCriteria": {
		"tenantId": "pb",
		"moduleDetails": [{
			"moduleName": "dss-dashboard",
			"masterDetails": [{
				"name": "dashboard-config"
			}]
		}, {
			"moduleName": "FSM",
			"masterDetails": [{
				"name": "FSTPPlantInfo"
			}]
		}]
	}
}

Overview

This patch release provides the enhancements in the search functionality and FSM registry. Part search is enabled in the entire application to enhance user experience. Also, the fields in the FSM registry are made editable, mandatory and unique as per its attributes.

Release Highlights

The enhancements included are:

• To enable part search in the entire application

• Modify FSM registry to making fields as mandatory, editable and unique

Enhancements

Document Resources and Links

Backend Service Documents

https://docs.google.com/document/d/1zbVfCjrE499sJgqj3lwSZxBzmffSpFXom9tgbR--xXY/edit#heading=h.se24ugcdelwb

https://docs.google.com/document/d/1_WC_l5BaI65PHUGTrVOIUmAdzHjYzeei6ZGFVmmud9o/edit#

https://docs.google.com/document/d/1jX1YT30u8Ss2yBZBbatI8dFOy7xzIS0GXz0GQrMBLYw/edit#

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

Overview

Faecal Sludge Management (FSM) is a system that enables citizens to raise a request for septic tank cleaning with their urban local bodies (ULBs) directly or for reaching out to a ULB counter. Citizens can track the application, make a payment for the charges and rate the service.

Service Dependencies:

• billing-service

• mdms-service

• workflow-v2

• boundary-service

• user-service

• idgen-service

• user-events

• collection-service

• notification-service

• vendor

• vehicle

• fsm-calculator

• egov-url-shortener

• collection-service

• pdf-service

API Specification

FSM Swagger Link

Data Model

Web Sequence Diagrams

There are two new updates introduced in FSM v1.2.1 while creating a new application - Stepper Information and Vehicle Capacity Selection in the Service Request Screen.

Stepper Information

We are introducing stepper information in FSM while creating an application from the citizen side so that they have visibility on how many steps they need to go over to submit details regarding their tank.

Technical Implementations Details:

TLTimelineInFSM.js file is the common component and used for rendering the stepper information. The path of the file is:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/components/TLTimelineInFSM.js

The code snippets for defining the steps present in FSM application under case “APPLY”:

The code snippets to render the stepper information in each screen using the timeline component:

Service Request Screen

Citizens can now select vehicle capacity along with the number of trips required while creating an application. If nothing is selected, we will proceed by taking the minimum vehicle capacity available with the number of trips.

Technical Implementation Details:

Code path: frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pageComponents/SelectTripNo.js

The code snippet for rendering the Vehicle Capacity field in Service Request screen:

The code snippet for fetching the vehicles available under all DSO:

The code snippet for setting the default vehicle capacity to minimum:

Promotion of Encryption Service

Steps

• Choose values for the following fields:

- master-password: choose any string of any length (can contain alphanumerics and special characters)

- master-salt: choose any string of length 8 (can contain alphanumerics and special characters)

- master-initialvector: choose any string of length 12 (can contain alphanumerics and special characters)

- Ask devops to generate keys for above selected values,

- In environment secrets.yml file, add “egov-enc-service” subsection under 'secrets' section, and provide values for above three fields. For example: For dev environment https://github.com/egovernments/eGov-infraOps/blob/master/helm/environments/dev-secrets.yaml#L29 (Ask Devops to do it)

• Add field “state-level-tenant-id“ under “egov-enc-service:” section for state level tenantId in environment yml. Example: https://github.com/egovernments/eGov-infraOps/blob/master/helm/environments/qa.yaml#L525

• Promote egov-enc-service:4-master-f47bff2

• Make sure “egov-enc-service“ entry is present in “egov-service-host” in environment yml ,ex:- for dev https://github.com/egovernments/eGov-infraOps/blob/master/helm/environments/dev.yaml#L65 . If not, make changes and build and deploy zuul from master branch.

Data Migration

Steps

• Provide DB details in following environment variables

- DB_PASSWORD

- DB_HOST

- DB_PORT

- DB_USERNAME

- DB_NAME'

• Backup old tables

- Create table eg_user_backup_plaintext as (select * from eg_user)

- Create table eg_user_address_backup_plaintext as (select * from eg_user_address)

• Delete foreign key referenced on ‘eg_user’ from ‘eg_userrole_v1’ temporarily until the data is transformed

- ALTER TABLE eg_userrole_v1 DROP CONSTRAINT fk_user_role_v1

• Deploy user service build with encryption to run flyway migration (egov-user:11-user_changes_MT-800f319)

• Clean tables of all plain text data

- Delete from eg_user_address

- Delete from eg_user

• Run migration

- Script python package dependencies

- import psycopg2

- import sys

- import json

- import requests

- import configparser

- import logging

- import os

Commands to run for migration:

- python3 user_migration.py config_user_encryption.txt

- python3 user_migration.py config_address_encryption.tx

• Restore earlier deleted foreign key constraint

- ALTER TABLE eg_userrole_v1 ADD CONSTRAINT fk_user_role_v1 FOREIGN KEY (user_id, user_tenantid) REFERENCES eg_user(id, tenantid) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION

Service Builds

• User service: egov-user:11-user_changes_MT-800f319

- Set environment variable “DECRYPTION_ABAC_ENABLED” to false

• User service copy for chatbot: egov-user-chatbot:4-user_changes_MT-621fe60

Note: Promote only if Whatsapp chatbot is already running in the system. It uses another copy of user service named “egov-user-chatbot“. Not needed if Whatsapp- chatbot is not in the system.

• Report service: report:22-report-encryption-changes-e92c8ae

• enc-service: egov-enc-service:4-master-f47bff2

• MDMS: Copy the MDMS folder - https://github.com/egovernments/egov-mdms-data/tree/master/data/pb/DataSecurity

Overview

In this document, we will learn how to legacy index/re-index the fsm index.

Pre-Requisites

• Kubectl access to the required environment in which you want to run the re-indexing

• playground pod access

• Legacy index mapping/configuration done in the respective indexer-config ( in this case for FSM, legacy index configuration for fsm is done here, Similarly for VehicleTrip also exists )

Postman Collection

Postman collection to re-index the data for FSM, VehicleTrip, Vehicle, Vendor Services can be downloaded here

Steps to legacy-index FSM

1. After importing the postman collection downloaded from above section, you can find two request

   1. fsm-legacy : This request helps to get the data from fsm/plainsearch api and push data to fsm-enriched topic by indexer service

   2. fsm-legacy-kafkaconnector : This is the request to create a connector which can listen to the fsm-enriched topic and push data to the elastic search with the new index fsm-enriched

2. Run the fsm-legacy-kafkaconnector request in the playground pod, which would create a connector which would intern start listening to the topic fsm-enriched-sink

3. Run the fsm-legacy request in the playground pod, which would call indexer service to intiate the process of fetching the data from plainsearch and push the data prepared according to the legacy-index mapping and push the data to the fsm-enriched-sink topic

4. Whole process would take some time, mean while you can searc for the data in fsm-enriched index in the elastic search

5. we can go through the logs of the indexer pod, which would help to understand the job is done

6. Once the job is done, delete the kafka connector running the below curl in the playground curl --location --request DELETE 'http://kafka-connect.kafka-cluster:8083/connectors/fsm-enriched-es-sink'

7. Once reindexing is completed, please verfiy the count in fsm index and fsm-enriched index, then delete the fsm index and create alias for fsm-enriched index as fsm.Please use below command for alias creating.

POST /_aliases
{  "actions":
[  
  {      "add":
 {        "index": "fsm-enriched",    
   "alias": "fsm"    
  }    
}
 ]
}

Steps to legacy index VehicleTrip

1. After importing the postman collection downloaded from above section, you can find two request

   1. vehicleTrip-legacy : This request helps to get the data from vehicletrip/plainsearch api and push data to vehicletrip-enriched topic by indexer service

   2. vehicle-trip-legacy-kafkaconnector : This is the request to create a connector which can listen to the vehicletrip-enriched topic and push data to the elastic search with the new index vehicletrip-enriched

2. Run the vehicletrip-legacy-kafkaconnector request in the playground pod, which would create a connector which would intern start listening to the topic vehicletrip-enriched-sink

3. Run the vehicletrip-legacy request in the playground pod, which would call indexer service to intiate the process of fetching the data from plainsearch and push the data prepared according to the legacy-index mapping and push the data to the vehicletrip-enriched-sink topic

4. Whole process would take some time, mean while you can searc for the data in vehicletrip-enriched index in the elastic search

5. we can go through the logs of the indexer pod, which would help to understand the job is done

6. Once the job is done, delete the kafka connector running the below curl in the playground curl --location --request DELETE 'http://kafka-connect.kafka-cluster:8083/connectors/vehicletrip-enriched-es-sink'

7. Once reindexing is completed, please verfiy the count in vehicletrip index and vehicletrip-enriched index, then delete the vehicletrip index and create alias for vehicletrip-enriched index as vehicletrip.Please use below command for alias creating.

POST /_aliases
{  "actions":
[  
  {      "add":
 {        "index": "vehicletrip-enriched",    
   "alias": "vehicletrip"    
  }    
}
 ]
}

FSM uses several core components, and is built on top of these reusable building blocks to deliver citizen services as part of Faecal Sludge Management (FSM).

Core Components

To develop a new service, one needs to create a micro-service and make it available through the API gateway. The API gateway calls the User Service for authentication and the Access Service for authorisation. The service developer can configure the roles and map the roles and actions using the Master Data Management Service.

Citizen Dashboard: The service user interface can be developed as part of the Citizen Dashboard or can be an independent solution. The citizen can log in using a mobile number and OTP. They can apply for a new service using the service UI. The File Store Service allows users to upload relevant documentation.

The Persister Service stores the submitted application asynchronously into the registry. The PII data is encrypted using the Encryption Service before storing. All changes are digitally signed and logged using the Signed Audit Service (ongoing). The Indexer Service transforms and enriches the application data. The Indexer Service also strips the PII data and sends it to the Analytics Data Store(ElasticSearch).

The Dashboard Backend Service executes configured queries on the stripped data and makes the aggregated data available to the Dashboard Frontend for the administrator or employee view. The views are in accordance with the user role access which is also configurable.

The Billing Service generates a demand based on the calculation logic for the given service delivery. Based on this demand, a bill is generated against which the payment has to be made. The citizen can either make an online payment or can pay at the counter (offline payment). The Payment Gateway Service is called for online payments and this is integrated with third-party service providers. The service routes the citizen to the service provider's website and then back to the citizen's UI once the payment is successful.

The Collection Service is the payment registry and records all the successful payments. For offline payments, a record is made in the collection service after the collection of the Cash/Cheque/DD/RTGS. The allowed payment modes are configurable. The PDF service is used to generate receipts based on a configurable template. The service then triggers the Workflow Service to assign tasks for verification and approval. Workflows can be configured.

The Employee Service allows employee registrations and enables them to log in using the Employee Dashboard. The dashboard displays the list of pending applications as per the employee's role. The employee can perform actions on these applications using the employee UI for the service. As the status changes or actions are taken on the applications, the relevant SMS and Email Notification Service sends the updates to the applicant. Once the application is approved, the applicant can download the final certificate which is generated using PDF Service.

DIGIT has multi-tenant configuration capabilities. The Location Service allows the configuration of the tenant hierarchy and maps multiple tenants like country, state, district, or state, department, and sub-department. Each tenant can have their own configurations for service, roles, workflows etc. This allows for variations across different agencies in tune with the local context. The Language Service facilitates the support of multiple languages in DIGIT. This service stores the translations in multiple languages.

FSM Components

Faecal sludge management (FSM) is a system that enables citizens to raise a request for septic tank cleaning with their urban local bodies (ULBs) directly or by reaching out to the ULB counter. Citizens can track the application, make a payment for the charges and rate the service. Citizens can track the application, make a payment for the charges and rate the service.

The FSM calculator is a system that enables the FSM administrator to create billing slabs for the FSM application(s) with different combinations of property type, slum, tank and capacity. It generates the demand after calculating the charges for the given application using the billing slab already configured.

The vendor registry is a system that enables urban local body (ULB) employees to create and search for a vendor, that is, the desludging operator (DSO) and driver entities with appropriate vehicle entities for the FSM application. The vendor registry is a system that enables urban local body (ULB) employees to create and search for a vendor, that is, the desludging operator (DSO) and driver entities with appropriate vehicle entities for the FSM application.

The vehicle registry is a system that enables urban local body (ULB) employees to create and search vehicle entities, schedule vehicle trips for FSM application, and track vehicle trips. A vehicle registry is a system that enables ULB employees to create and search vehicle entities, schedule vehicle trips for FSM application, and track vehicle trips.

About FSM

Our mission is to build a digital tool that enables urban local body employees to deliver desludging services (emptying septic tanks) to citizens. The linear nature of feacal sludge value chains presents a clear framework for comprehending the optimal flow of sludge, but these value chains consist of diverse stakeholders and business models. The absence of coordination among value chain stakeholders and the lack of transparency to enforce standardised practices at each stage of the value chain lead to subpar sanitation outcomes. Furthermore, conflicts between stakeholders and the feasibility challenges of existing and emerging business models diminish the efficiency of the waste value chain.

The Faecal Sludge Management (FSM) application has been able to provide data and visibility to track service requests and understand the service delivery value chain, paving the way for process enhancements in FSM.

The product will provide the following benefits:

1. Reduce time taken for service delivery.

2. Establish a chain of custody of waste from the point of collection to disposal.

3. Digital record keeping of service deliveries.

4. Support data interoperability with other sanitation systems in the state.

5. Improve sustainability by providing visibility and control to the government.

Benefits to Value-Chain Stakeholders

All content on this page by is licensed under a .

The DIGIT-Faecal Sludge Management (FSM) allows citizens to raise service requests for desludging and pay the fees for the service delivery online. For governing bodies and vendors, it makes service delivery easier and captures information end-to-end, ensuring waste pick up and its disposal at the correct treatment plant. Real-time tracking of service delivery, along with the availability of rich transactional data allow decision makers to ensure a better citizen service experience and promote a cleaner/healthier environment.

Key Features

• Apply for desludging services

• Make payment for services

• Register desludging operators

• Update vehicle logs

• Manage vendors, vehicles and drivers

User Roles

Refer to the table below to understand the different user roles and the scope of action linked to each role. The manual provides a detailed description of how to use the system for each role.

Using FSM

This section guides you through the details of using the FSM module for each role. Click on the relevant role below to learn more about how to use the FSM system.

Complete Request

Fetching data from the MDMS

Customising Fields In A Form

The config can be found at CompleteApplication.js

File Path: frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/config/CompleteApplication.js

{
          label: "ES_NEW_APPLICATION_PROPERTY_TYPE",
          isMandatory: true,
          type: "component",
          route: "property-type",
          key: "propertyType",
          component: "SelectPropertyType",
          texts: {
            headerCaption: "",
            header: "CS_FILE_APPLICATION_PROPERTY_LABEL",
            cardText: "CS_FILE_APPLICATION_PROPERTY_TEXT",
            submitBarLabel: "CS_COMMON_NEXT",
          },
          nextStep: "property-subtype",
        },
        {
          label: "ES_NEW_APPLICATION_PROPERTY_SUB-TYPE",
          isMandatory: true,
          type: "component",
          route: "property-subtype",
          key: "subtype",
          component: "SelectPropertySubtype",
          texts: {
            headerCaption: "",
            header: "CS_FILE_APPLICATION_PROPERTY_SUBTYPE_LABEL",
            cardText: "CS_FILE_APPLICATION_PROPERTY_SUBTYPE_TEXT",
            submitBarLabel: "CS_COMMON_NEXT",
          },
          nextStep: "map",
        },
        {
          label: "ES_NEW_APPLICATION_PIT_TYPE",
          isMandatory: false,
          type: "component",
          route: "pit-type",
          key: "pitType",
          component: "SelectPitType",
          texts: {
            header: "CS_FILE_PROPERTY_PIT_TYPE",
            cardText: "CS_FILE_PROPERTY_PIT_TYPE_TEXT",
            submitBarLabel: "CS_COMMON_NEXT",
            skipText: "CORE_COMMON_SKIP_CONTINUE",
          },
          nextStep: "tank-size",
        },
        {
          route: "tank-size",
          component: "SelectTankSize",
          isMandatory: false,
          texts: {
            headerCaption: "",
            header: "CS_FILE_APPLICATION_PIT_SEPTIC_TANK_SIZE_TITLE",
            cardText: "CS_FILE_APPLICATION_PIT_SEPTIC_TANK_SIZE_TEXT",
            submitBarLabel: "CS_COMMON_NEXT",
          },
          type: "component",
          key: "pitDetail",
          nextStep: null,
          label: "ES_NEW_APPLICATION_PIT_DIMENSION",
        },

Upload Pit Photo Button

UploadPitPhoto.js molecule is available within the molecules folder in react-components.

File Path: frontend/micro-ui/web/micro-ui-internals/packages/react-components/src/molecules/UploadPitPhoto.js

Saving Image fileId in FSM service

const uploadImage = useCallback(async () => {
        if (uploadedImagesIds === null || uploadedImagesIds.length < 3) {
            const response = await Digit.UploadServices.Filestorage("FSM", image, props.tenantId);
            setUploadedImagesIds(addUploadedImageIds(response));
        } else {
            console.log("disabled")
        }
    }, [addUploadedImageIds, image]);

Filter Component On DSO Inbox Screen

The link for the MDMS changes made is given below.

egov-mdms-data/RoleStatusMapping.json at DEV · egovernments/egov-mdms-data

RoleStatusMappping.json

  {
            "userRole": "FSM_DSO",
            "statuses": [
                "DSO_INPROGRESS",
                "PENDING_DSO_APPROVAL",
                "COMPLETED",
            ],
            "zeroCheck": true,
            "fixed": false
        },

Schedule Action For Post Pay In DSO

Schedule Action is added for post-pay applications where DSOs can schedule the trip by entering the number of trips.

Code snippet for schedule window:

 case "SCHEDULE":
      case "ES_FSM_SCHEDULE":
        setFormValve(true);
        return setConfig(
          configScheduleDso({
            t,
            rejectMenu: Reason?.DeclineReason,
            setReason: setDeclineReason,
            reason: declineReason,
            applicationCreatedTime: applicationData?.auditDetails?.createdTime,
            vehicle,
            vehicleCapacity: applicationData?.vehicleCapacity,
            action,
            noOfTrips: applicationData?.noOfTrips
          })
        );

ScheduleDso.js is the file responsible for the schedule window pop up.

File path: frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/config/ScheduleDso.js

SUJOG-Feacal Sludge & Septage Management (FSSM)

The Government of Odisha (GoO) has initiated a programme called "SUJOG - Sustainable Urban Services in a Jiffy by Odisha Government" through the Housing and Urban Development Department (H&UDD). The primary objective of this programme is to implement e-governance services across the Urban Local Bodies (ULBs) in the state. Its aim is to ensure that urban services are delivered to citizens in a seamless, transparent, and trackable manner. The programme has successfully been implemented in 115 ULBs in Odisha, and citizens can access these services through the DIGIT platform.

Facilitating effective sanitation management, the DIGIT Sanitation platform is currently live in 70 ULBs in Odisha. This platform specifically focuses on managing Feacal Sludge Management (FSM) in these areas. The programme aims to bring a paradigm shift in the way urban governance happens in the state by way of digitalisation. Its beneficiaries include citizens, the ULB administration, various government departments, and several other actors involved in the service delivery value chain.

One of the leading states in the domain of urban Feacal Sludge and Septage Management (FSSM), Odisha has already demonstrated effective city-wide FSSM systems in several ULBs with the commissioning of 108 FSTPs across 107 cities by September 2022, with further scale-up across all 115 ULBs underway. To ensure the continued and efficient delivery of FSSM services to all its citizens, the state has partnered with eGov Foundation (eGov) to roll out a Digital FSSM platform for managing the ULB-level operations and monitoring the performance of the FSSM service delivery.

The SUJOG-FSSM platform was successfully piloted in the three ULBs of Berhampur, Balasore, and Dhenkanal in December 2021. After successfully demonstrating three pilot ULBs, the programme has been approved by the HUDD (vide Letter No. 8951, and dated 20.05.2022), and communicated to all the ULBs and the other stakeholders involved in the rollout. Subsequently, the platform has been scaled up to cover 70 ULBs in Phase-1 and Phase-2. The platform will be further scaled up across all the 115 ULBs of Odisha, covering 119 Faecal Sludge Treatment Plants (FSTPs) to bring efficiency, transparency, and speed in the delivery of faecal sludge management services to the citizens through an online interface.

The Pilot

The pilot journey of SUJOG FSSM in Odisha across three ULBs can broadly be categorised into two phases - a phase before and March 2022. During the first phase, the prime focus was on training the end users online and driving citizen adoption through IEC campaigns. However, after three months of consistent efforts, multiple factors hindering the change management on ground surfaced. During the meeting held towards the end of February with HUDD and the key stakeholders involved in implementation, it was decided to investigate the reasons for low adoption rates across ULBs, and put in dedicated efforts towards enhancing the same.

Multiple field visits were conducted by various team members from the SUJOG FSSM implementation unit and following actions were taken towards enhancing the adoption:

• Infrastructure procurement: One of the key gaps observed was the lack of connectivity for various users, especially the ones at FSTP. Following this observation, government orders were issued by the special secretary for the procurement of infrastructure. A constant monitoring mechanism with commissioners/EOs and the special secretary led to a quick infrastructure procurement across all three FSTPs & ULB offices .

• In-person refresher training across all ULBs: One learning was that online training was not as effective as in-person, especially with the users in the FSM value chain. There was a spike in the number of requests being logged in the system by the employees as soon as the in-person refresher trainings were conducted across the 3 ULBs.

• Daily adoption monitoring helped enhance the ownership among various users. This also helped establish a stronger support system for the quick resolution of issues.

• The team identified the product enhancements that needed to be implemented to further improve the adoption. Two major enhancements that happened as a result are the option for recording the payment post the service, and multi-trip capabilities for each request.

• Following the above efforts and enhancements, adoption across pilot ULBs has improved drastically. The number of requests before March 2022 (since December 2021) stood at 237 for all three pilot ULBs. The requests between March 2022 and May 2022 were nearly five times higher at 1,167. Given the significant improvement in adoption, a letter was issued to prepare the ULBs for a phased implementation of a statewide rollout of SUJOG FSSM in May 2022.

Phase 1 roll-out:

Preparations for the phase 1 rollout emerged from the learnings the implementation team had during the pilot phase. Phase 1 ULBs were selected following multiple discussions with the state officials & TSU. Following steps ensured the sustained adoption of the application across all ULBs:

Infrastructure readiness: Infrastructure assessment was conducted across all these ULBs before the data collection process. Letters were issued to expedite the infrastructure procurement, and ensure all the ULBs and FSTPs were equipped sufficiently for recording the requests and closing them on a real-time basis.

Involving DUDA officials in configuration: Data collection for configuring the application happened through DUDA officials, who were responsible for data collection and verification in their respective districts. This ensured that the data collection process was quicker and error-proof.

Partnership with OWA for training: Train-the-trainer approach was taken for ensuring successful knowledge transfer to all the potential end users of the application. OWA master trainers were trained to conduct the training sessions with the end users. This smoothened the interactions between trainers and trainees as all the master trainers were well versed with the users skillset and also training in the state language, Odia.

Extensive training sessions were conducted over a span of three days to ensure successful knowledge transfer to over 100+ end-users across 37 ULBs. Interactive sessions by the master trainers helped the end-users understand the steps quickly and start using the application themselves. All the trainees were able to demonstrate the application's usage by the end of the training session. This eased the efforts towards driving adoption among the phase 1 ULBs.

Weekly monitoring of adoption and support for the ULBs: All the state officials involved in the rollout of SUJOG FSSM were part of weekly mentoring sessions. These sessions acted as a channel where the ULBs could discuss insights, ground level challenges, and issues related to the platform and obtain quick resolution. This also ensured sustained adoption. Over 90% of the applications are being recorded on the platform across ULBs, keeping in view the current feature availability on the platform.

Bi-weekly reviews with ULB representatives: The EOs and COs were involved in the bi-weekly calls which were chaired by the additional secretary and engineer-in-chief. The calls revolved mostly around discussing and identifying the gaps in FSM service delivery and SUJOG-FSSM adoption. These calls were also leveraged to discuss policy level changes, identify issues, and challenges from the ULB SPoCs and executives, or TRPs, for immediate action.

Field visits: The eGov team visited 29 ULBs to understand the on-ground situation. The purpose of the visits was to comprehend the FSM value chain and the operational status of FSTPs. The visits were planned and shared with the ULBs, and the team met with FSSM SPocS (sanitation experts/sanitation nodal officers), executives, and EOs/COs during the visits to clarify their viewpoints. All 29 FSTPs were visited, and in-depth discussions with SHG members and technical resource personnel were held. We were able to see things more broadly and understand the gaps that was impeding adoption and service delivery. The state was then informed of the learnings for them to take the necessary action.

Product Features, Roadmap, and Data Captured in SUJOG-FSSM:

The platform enables multiple stakeholders to interact: Citizens, ULB FSSM executives, cesspool operators, and technical resource personnel from FSTPs. This allows a citizen to raise a desludging request by providing minimum information, and a ULB FSSM executive to take action on the raised request or log in request on behalf of a citizen. In the process, citizens are regularly informed of the status of their requests. The role of the technical resource person is to then close all the requests raised once the cesspool operators dispose of the septage in the FSTPs. This ensures the maintenance, monitoring, and tracking of the entire FSM value chain.

Expected Outcomes

The expected outcomes after optimal and efficient usage of the SUJOG-FSSM platform are mentioned below:

• Access to quality e-service delivery of FSSM that is consistent and supported by local governance systems at ULBs (and also at FSTPs).

• Inclusion of private players within the ambit of the FSSM transformation, besides providing oversight to the ULB administration.

• Revenue generated from the FSSM services is captured in the platform. It will help in devising enhanced revenue models for operation and maintenance.

• The dashboard must be accessible to all stakeholders, and any warning signs about implementing the FSSM in any geographic area can be promptly and efficiently handled.

• The data and details recorded in the platform can be used for an in-depth study of the cities' FSSM effort by focusing on areas that need improvement or improved enforcement.

• Greater transparency in the entire value chain, such as real-time tracking of cesspool vehicles (GPS integration), payment systems, etc.

• The robust monitoring system in the platform will help city administrators to implement scheduled desludging of septic tanks for all properties and design performance-based contracts for the private DSOs.

Here are the articles in this section:

• Functional customisation

• Technical customisation

• Program rollout plan

• Adoption metrics

• Implementation plan

• Implementation guide

• Implementation checklist

The Septage Treatment Plant Operator (SeTPO) receives multiple vehicles servicing various desludging requests in the urban local body (ULB) and adjacent gram panchayats (GPs) through the day, each day. Some of these trips made by some vehicles may be associated with the applications raised and serviced through the platform. Additionally, incoming vehicles may come in independently, without corresponding applications.

SeTPO can‌:

• Update the status of applications and trips in “Waiting for Disposal” stage at the FSTP/STP as disposed

• Log vehicle(s) requests that are not in the system

Login

FSTP operators are provided credentials to login to the system.

User Actions

On this page, the following actions can be performed:

• Enter username and password

• Select the city for login

• Reset password by clicking on the “Forgot Password” link

On clicking continue, FSTP operators are redirected to the FSM homepage.

User Actions

• Click on Inbox to view incoming vehicles for disposal against applications and perform actions

• Record incoming vehicle that has not come in via an application

• View reports

• Change language

• Edit profile details by clicking on the user icon on the top right hand corner

• Logout by clicking on the user icon on top right hand corner

On this page, the following actions can be performed:

Updating Disposal Status of Trips

To view incoming vehicles for disposal against applications, the user can navigate to the inbox. The inbox displays a list of trips along with the vehicle number that is pending to be disposed off at a specific plant.

User Actions

The following actions can be performed:

• Search for an active trip using the “Application No.”, Vehicle no. and DSO name.

• Clear search by clicking on “Clear Search”

• View and update trip details by clicking on a trip ID or vehicle log

• Sort applications and trips by the application date

On clicking on an application number or vehicle log ID, the user is redirected to the update trip page.

Confirming Disposal

User Actions

• View trip details such as Vehicle no., DSO Name, and Locality.

• Update vehicle in time and out time.

• Update septage dumped (in litres)

• Add additional details and attachments.

• Submit form or decline vehicle by clicking on the “Take Action” button

The following actions can be performed:

The take action button has the following options:

• Decline Vehicle

• Submit

On clicking the Submit button, the application is updated successfully and a snack bar will appear for confirmation. The application will also be removed from the Inbox.

Declining Vehicle

There are multiple reasons why a vehicle may be declined at the treatment plant, such as due to the quality of waste or if the plant is under maintenance. In such cases, the treatment plant operator may decline the incoming vehicle. This can be done from the application details page where the “Take Action” button has the option for Decline. On clicking on this, the following pop-up will appear.

User Actions

The following actions can be performed:

• Select the reason for declining

• Close pop-up by clicking on the Close button on the pop up.

• Close pop-up by clicking on the cross icon on the top right of the pop up.

• Confirm decline by clicking on Decline Vehicle.

On clicking on Decline Vehicle, there will be a snack bar confirming the action and the user will be redirected to the home screen.

Log Vehicle Requests that are Not in the System

Incoming vehicles that have not come in via an application can be recorded by the user using the add ‘New’ button on the FSM home screen. On clicking on the New button, the user will be redirected to the following screen:

User Actions

The following actions can be performed:

• Enter Vehicle Number

• Click on Next

Once vehicle number is entered, the ‘Next’ button will be highlighted and the user will be redirected to the Vehicle Log screen.

User Actions

The following actions can be performed:

• Update DSO Name and Locality

• Update Vehicle In time and Out time.

• Update volume of waste.

• Update Additional Details and Attachments.

• Submit the form by clicking on Submit.

A snack bar will confirm submission and the user will be redirected to the FSM homepage.

In FSTP, we are trying to decouple the vehicle dispose from the FSM application. Whether vehicle is attached to any FSM application or not, we allow the vehicle to dispose in the FSTP plant.

FSTP Home UI:

After logging as a FSTP user, we have now the home button option:

Technical Implementation Details:

Code changes path are:

DIGIT-Dev/frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/components/FsmCard.js

FSTP Operations UI:

After moving into “home” option, an FSTP user can choose from the following options:

• FSTP can choose Add Vehicle Log option if he/she wants to check whether a vehicle is linked to any application and dispose.

• FSTP can choose Inbox if he/she wants to check all the applications that are is ready to dispose.

Technical Implementation Details:

The path for code:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpOperations.js

The code snippet for populating the options:

The code snippet for rendering the icon:

ULBHomeCard.js is the common component used to populate options in the screen.

The paths:

frontend/micro-ui/web/micro-ui-internals/packages/react-components/src/atoms/ULBHomeCard.js

FSTP Add Vehicle Log UI:

FSTP can add vehicle log using vehicle number (in proper format with spaces, e.g. AB 00 CD 1234). An improper format will throw an error.

Techincal Implementation Details:

The path for the code:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpAddVehicle.js

The code snippet for populating the add vehicle log field and its validation:

The code snippet for rendering the screen:

FSTP Service Request Screen:

After entering the vehicle number in the add vehicle log screen, we are fetching the FSM application, which is linked to that specific vehicle number. The data is rendered as shown below:

Technical Implementation Details:

The path for the code:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpServiceRequest.js

The code snippets for fetching the FSM application linked to vehicle number:

Fetching the vehicle Id using vehicle number

Fetching the vehicle log using vehicle Id

Extracting out the FSM application number from vehicle log:

Fetching the FSM application details using FSM application number

The code snippets to render the data:

Mobile view

Desktop view

Vehicle Log screen:

After selecting the application, FSTPO can dispose the vehicle log in the vehicle log screen.

Additional details and attachment fields are introduced in new updates in FSM v1.2.1 .

The screen for the existing vehicle log:

The screen for new vehicle log if no application is found for vehicle is shown below. FSTPO can dispose the new vehicle log by providing all the details below.

Technical Implementation Details:

The path for the code:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpOperatorDetails.js

The code snippet for additional details and attachments field:

For new vehicle log:

The code snippets to render input field for new vehicle log:

Overview

Vehicle Registry is a system that enables urban local body (ULB) employees to create and search vendors, that is, Desludging Operators (DSO) and driver entities with appropriate vehicle entities for the FSM application.

Service Dependencies:

• egov-mdms-service

• egov-user-service

• boundary-service

• Egov-idgen

• egov-workflow-v2

• vehicle

API Specification

Data Model

Web Sequence Diagrams

Overview

Every service integrated with egov-workflow-v2 service needs to first define the workflow configuration which describes the states in the workflow, the action that can be taken on these states, who all can perform those actions, SLA, etc. This configuration is created using APIs and is stored in DB. The configuration can be created either at the state-level or tenant-level based on the requirements.

Pre-requisites

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

• egov-workflow-v2 service is up and running

• Role Action mapping is added for the BusinessService API’s

Key Functionalities

• Create and modify the workflow configuration.

• Configure the state level as well the BusinessService-level SLA.

• Control access to workflow actions from configuration.

• Validate if the flow defined in configuration is complete during creation.

Deployment Details

1. Deploy latest version of egov-workflow-v2 service.

2. Add role action mapping for BusinessService API’s (preferably add create and update only for SUPERUSER. Search can be added for a CITIZEN and required employee roles like TL_CEMP, etc.).

3. Overwrite the egov.wf.statelevel flag (true for state-level and false for tenant-level).

4. Add businessService persister yaml path in persister configuration.

Confuiguration Details

1. Create the businessService JSON based on the product requirement. Following is a sample json of a simple 2-step workflow where an application can be applied by a citizen or counter employee, and then can be either rejected or approved by the approver.

{
      "tenantId": "pb",
      "businessService": "PGR",
      "business": "pgr-services",
      "businessServiceSla": 432000000,
      "states": [
        {
          "sla": null,
          "state": null,
          "applicationStatus": null,
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "APPLY",
              "nextState": "PENDINGFORASSIGNMENT",
              "roles": [
                "CITIZEN",
                "COUNTER_EMPLOYEE"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "APPLIED",
          "applicationStatus": "APPLIED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": false,
          "actions": [
            {
              "action": "APPROVE",
              "nextState": "APPROVED",
              "roles": [
                "APPROVER"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "APPROVER"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "REJECTED",
          "applicationStatus": "REJECTED",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true
        },
        {
          "sla": null,
          "state": "APPROVED",
          "applicationStatus": "APPROVED",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true
        }
      ]
    }

2. Once the businessService json is created, add it in request body of _create API of the workflow, and call the API to create the workflow.

3. To update the workflow, search the workflow object using _search API, and then make changes in the businessService object and then call _update using the modified search result. (States cannot be removed using _update API as it will leave the applications in that state in an invalid state. In such cases, first all the applications in that state should be moved forward or backward, and then the state should be disabled through DB directly).

Integration

Integration Scope

The workflow configuration can be used by any module which performs a sequence of operations on an application/entity. It can be used to simulate and track processes in organisations to make it more efficient, and increase the accountability.

Integration Benefits

Integrating with the workflow service provides a way to have a dynamic workflow configuration which can be easily modified according to the changing requirements. The modules do not have to deal with any validations regarding the workflow such as authorisation of the user to take an action, if documents are required to be uploaded at certain stage, etc., as they will be automatically handled by egov-workflow-v2 service based on the configuration defined. It automatically keeps updating the SLA for all applications, which provides a way to track the time taken by an application to get processed.

Steps to Integration

1. To integrate, the host of egov-workflow-v2 should be overwritten in the helm chart.

2. /egov-workflow-v2/egov-wf/businessservice/_search should be added as the endpoint for searching the workflow configuration. (Other endpoints are not required once the workflow configuration is created).

3. The configuration can be fetched by calling _search API.

Reference Docs

API List

Note: All APIs are in the same postman collection. Hence, the same link has been added in each row.

DIGIT Sanitation started with Faecal Sludge Management (FSM) and in future, we will pick up Solid Waste Management (SWM). Beyond that, we believe that the platform can be leveraged for other waste streams but the nature of our intervention will be evolve.

Overview of Faecal Sludge Management

The waste we flush down the toilet does not always go into a sewer. Approximately 70% of the households in India have toilets connected to septic tanks or soak pits, technically known as on-site containment systems. They accumulate and store faecal matter over a long period. In sewers, the faecal matter travels daily with a lot of water through long concrete pipes. But in the case of on-site systems, it stays stored for about 3-5 years. Once the storage is full, the waste is emptied and transported to the treatment plant through vacuum trucks. The end-to-end value chain of safe storage, collection, transport, treatment, and end-use or disposal of faecal matter is called Faecal Sludge and Septage Management or FSSM. ‘Faecal Sludge’ and ’Septage’ are used to describe faecal matter in a specific physical and chemical state after prolonged storage.

Why FSM matters - It is the way forward in sanitation

FSSM has emerged as a cost-efficient population scale alternative to the networked sewer, which has been the traditional method of wastewater management.

1. Cost-effective: FSSM is 10 times cheaper than sewer systems.

2. Coverage: Less than one-third of urban toilet users are connected to sewer systems. The rest are more or less dependent on FSSM systems. Targeting FSSM will help us impact the maximum number of citizens.

3. Scale: In India's Swachh Bharat mission, 11 crore toilets were constructed across the country. Most are connected to on-site systems, which again increases the need for FSSM.

Our current understanding of the problems in septage management is based on our interactions with stakeholders and thorough published reports, and whitepapers. We are aware that FSSM systems have interdependent parts, and each stage of the FSSM value chain impacts how effectively the next stage functions. For instance, if the septic tanks do not have proper access, they will add to the cost of emptying, adding time and cost burden on desludging operators (DSOs). Similarly, it becomes unviable for the DSOs to dump the waste at the treatment plant if it is far from the city which is often the case.

While the linear sanitation value chain provides an understanding of the flow of faecal sludge, it does not capture all stakeholders in the process that control and influence the current effectiveness of sanitation systems.

Systems Map

We will use a systems mapping approach to outline the different factors and interactions within the sanitation value chain. We will explore systemic challenges at each part of the value chain that result in poor sanitation outcomes.

Reference Link

Part 1 - Toilets and containment units

Problems faced by key stakeholders

City managers, central/state governments

While sanitation is a priority of the central and state governments, city administrators have been strapped due to deficiencies in standards, building codes, municipal processes, and contracting and monitoring capabilities. These make it difficult to ensure the adequacy, usability, and safety of the toilets provisioned by public funds.

Masons

Masons are fundamental in proper construction of toilets and containment units. But a majority of masons currently lack the necessary training on construction standards. They are rarely employed using formal contracts, contributinb to the lack of traceability and accountability during the construction of toilets.

Citizens

Lack of awareness of the impact of improper construction of toilets and containment tanks, or constraints of affordability and space, leads citizens to influence masons to build containment units that do not follow technical standards. It is difficult to identify trained masons and services are procured through social networks and word of mouth.

Part 2 - Emptying and transport

Problems faced by key stakeholders

Desludging operators

• Lack of proper access to the containment systems adds time-cost to service.

• Treatment plants are located far from the city, making safe dumping unviable.

• While the payment from citizens is a clear incentive for emptying the tanks or pits, there are no incentives to ensure the safe transport of the faecal sludge to the treatment plant.

• Operations remain inefficient without timely and useful information for service delivery. Working conditions are risky, but provisions for personal protection equipment and emergency healthcare services are rare.

Citizens

• It is difficult to identify and book desludging services and service delivery is not reliable.

• Low-income households are denied service since they are not able to afford the full cost.

City managers, central/state governments

• Challenging to regulate the market for safe dumping without compromising service delivery.

• Lack of clear and actionable information in terms of safe or unsafe dumping of faecal sludge.

• Lack of pricing policies, infrastructure standards, licensing processes, and contracting and monitoring capacity limit the ability of decision-makers to take action.

Part 3 - Treatment

City managers, centre/state governments

• Difficult to regulate the market across various stages of construction and operations.

• Operational data of the treatment plant and process is often recorded offline and used for post-facto auditing. There is a pervasive lack of actionable information.

• Lack of rational pricing policies, comprehensive service benchmarks and infrastructure standards, contracting and monitoring tools hamper corrective action.

Plant operators

• The supply of desludging load varies in an unreliable and unpredictable manner, and over time, leads to system failure.

• Treatment plant management and maintenance is difficult and costly, and the payments are often not linked to performance.

• The performance is not directly causally linked to the environmental impact.

• Operations are not monitored to facilitate preventive action within the plant, and lack any binding linkages with standard operating procedures and service level agreements.

Part 4 - Ecosystem

Civil society and academia

• In the absence of data, researchers struggle to create new knowledge around the failures, risks, and opportunities, as well as give recommendations for improvement.

• Since policy and standards are not mapped to operational data, it is difficult for the ecosystem to translate knowledge to action, impact and access.

Government

• Inability to trace the impact and proper usage of grants and subsidies for sanitation.

• Limited state capacity in terms of budget, skilled human resources, tools, and technology. Coordination across multiple functions, such as standard-setting, policy-making, contracting, audit, monitoring, is needed to keep sanitation systems functional.

• Limited penetration of technology, innovation, and competition in the sanitation sector, makes it difficult for the government to enforce accountability across internal processes and market interactions.

Critical Problems in FSSM

At the core of all systemic challenges, there are problems that hinder a systemic change, limit stakeholders from implementing changes, or even cause the system to collapse. The identified problems are explained below:

Absence of well-defined standards for sanitation

• Current standards do not cover all aspects of sanitation and service delivery - such as standards of treated human waste, treatment plant technologies, and benchmarks, among others.

• The ecosystem has created many standards, which are not formally notified or enforced.

• Where standards exist, awareness and compliance are dismal for the following reasons:

1. Many actors in the value chain do not have the necessary knowledge, skills, or standard operating procedures.

2. Complexities in service delivery result in incomplete or improper service.

3. Poor requirement specifications in the Request for Proposals (RFPs) documents.

4. Model contracts exist but are not followed.

5. Delays in corrective action since contracts are not tightly coupled with monitoring.

Broken chain of custody from waste generation to reuse

• Systemic data either does not exist or remains disjointed to understand how much waste exists, where, when, with whom, and why.

• Feacal sludge tends to drop out of the value chain, untreated.The unavailability of the information - who dropped it, when, how, or where it ended up polluting the environment - hampers the process of taking corrective and preventive measures

Lack of verifiable, trusted data at various levels

• Data around faceal sludge (how much, where, when, who is responsible) is too little.

• Required data is not created, available, or shared across relevant ecosystem actors. As a result, the performance of sanitation systems remains opaque and unobservable.

Inability to convert waste to value

• Current systems are not structured to maximise the value from faceal sludge and related services.

• The policy framework may not recognise treated human excreta as compost. Unclear and fragmented demand for treated waste contributes to lax operations upstream.

Overview

The enc-client library is a supplementary Java library provided to support encryption-related functionalities so that every service does not need to pre-process the request before calling the encryption service.

Pre-requisites

• MDMS Service

• Encryption Service

• Kafka

Note: The MDMS configurations explained below are fetched by this library at boot time. After you make changes in the MDMS repo and restart the MDMS service, you will need to RESTART THE SERVICE which has imported the enc-client library. For example, the report service is using the enc-client library, so after making configuration changes to the security policy pertaining to any report, you will have to restart the report service.

Key Functionalities

• Encrypt a JSON Object - The encryptJson function of the library takes any Java object as an input and returns an object which has encrypted values of the selected fields. The fields to be encrypted are selected based on an MDMS configuration. This function requires the following parameters:

1. Java/JSON object - The object whose fields will get encrypted.

2. Model - It is used to identify the MDMS configuration to be used to select fields of the provided object.

3. Tenant Id - The encryption key will be selected based on the passed tenantId.

• Encrypt a Value - The encryptValue function of the library can be used to encrypt single values. This method also required a tenantId parameter.

• Decrypt a JSON Object - The decryptJson function of the library takes any Java Object as an input and returns an object that has plain/masked or no values of the encrypted fields. The fields are identified based on the MDMS configuration. The returned value(plain/masked/null) of each of the attribute depends on the user’s role and if it is a PlainAccess request or a normal request. These configurations are part of the MDMS. This function required following parameters:

1. Java/JSON object - The object containing the encrypted values that are to be decrypted.

2. Model - It is used to select a configuration from the list of all available MDMS configurations.

3. Purpose - It is a string parameter that passes the reason of the decrypt request. It is used for Audit purposes.

4. RequestInfo - The requestInfo parameter serves multiple purposes:

- User Role - A list of user roles are extracted from the requestInfo parameter.

- PlainAccess Request - If the request is an explicit plain access request, it is to be passed as a part of the requestInfo. It will contain the fields that user is requesting for decryption and the id of record.

• While decrypting Java object, this method also audits the request.

Configurations

All configurations related to enc-client library are stored in the MDMS. These master data are stored in DataSecurity module. It has two types of configurations:

1. Masking patterns

2. Security policy

Masking Patterns

The masking patterns for different types of attributes (mobile number, name, etc.) are configurable in MDMS. It contains the following attributes:

1. patternId - It is the unique pattern identifier. This id is referred to in the SecurityPolicy MDMS.

2. pattern - This defines the actual pattern according to which the value will be masked.

Click to see a sample of the masking patterns master data.

Security Policy

The security policy master data contains the policy used to encrypt and decrypt JSON objects. Each security policy contains the following details:

1. model - This is the unique identifier of the policy.

2. uniqueIdentifier - The field defined here should uniquely identify records passed to the decryptJson function.

3. attributes - This defines a list of fields from the JSON object that needs to be secured.

4. roleBasedDecryptionPolicy - This defines attribute-level role-based policy. It will define visibility for each attribute.

Visibility

The visibility is an enum with the following options:

1. PLAIN - Show text in a plain form.

2. MASKED - The returned text will contain masked data. The masking pattern will be applied as defined in the masking patterns master data.

3. NONE - The returned text will not contain any data. It would contain string like “Confidential Information”.

It defines what level of visibility should the decryptJson function return for each attribute.

Attribute

1. name - This uniquely identifies the attribute out of the list of attributes for a given model.

2. jsonPath - It is the json path of the attribute from the root of the model. This jsonPath is NOT the same as Jayway JsonPath library. This uses / and * to define the Json paths.

3. patternId - It refers to the pattern to be used for masking which is defined in the masking patterns master.

4. defaultVisibility - It is an enum configuring the default level of visibility of that attribute. If the visibility is not defined for a given role, then this defaultVisibility will apply.

The attribute defines a list of attributes of the model that are to be secured. The attribute is defined by the following parameters:

Unique Identifier

This parameter is used to define the unique identifier of that model. It is used for the purpose of auditing the access logs. (This attribute’s jsonPath should be at the root level of the model).

Role-Based Decryption Policy

It defines attribute-level access policies for a list of roles, and has the following parameters:

1. roles - It defines a list of role codes for which the policy will get applied. Make sure not to duplicate role codes anywhere in the other policy. Otherwise, any one of the policies will get chosen for that role code.

2. attributeAccessList - It defines a list of attributes for which the visibility differs from the default for those roles. There are two levels of visibility:

   1. First-level visibility: It applies to normal search requests. The search response could have multiple records.

   2. Second-level visibility: It is applied only when a user explicitly requests for plain access of a single record with a list of fields required in plain. The second-level visibility can be requested by passing plainAccessRequest in the RequestInfo.

   Plain Access Request

Any user will be able to get plain access to the secured data (citizen’s PII) by requesting through the plainAccessRequest parameter. It takes the following parameters:

1. recordId - It is the unique identifier of the record that is requested for plain access.

2. fields - It defines a list of attributes that are requested for plain access.

Audit Service

Every decrypt request is audited. Based on the uniqueIdentifier defined as part of the security policy, it lists out the identifiers of the records that were decrypted as part of the request. Each audit object contains the following attributes:

Actor Interaction Mapping

The above diagram illustrates the integration between each actor. A brief description of each role is provided below:

DIGIT UI Implementaton: Guidelines & FAQs

Development Setup

Repo:

Use the dev branch as the base branch for development.

Clone the repo and start using the following steps:

## install

yarn install

## start dev server

yarn start

Adding or modifying modules

• Modules are enabled by the MDMS config at.

• To add and enable any module in the new UI, src/App.js needs to be changed.

• Till PGR, we used to export the module and links were added to the registry. Now, adding to the registry is part of the modules themselves. We export only the init function of the module to take care of all the initialisations. Going forward, these init functions will have to be called. We will create the init function of PGR as well. These init modules must be called after initLibraries.

Changing CS

CSS classes are published over CDN and can be seen at: https://unpkg.com/@egovernments/digit-ui-css/dist/index.css

Any class can be overwritten. Make changes in the src/index.css file.

Customising Fields in a Form

Add any new component created in the registry,

Digit.ComponentRegistryService.setupRegistry({

SelectName: SelectName

});

• If API calls are failing, the do the following:

Check src/setupProxy.js for proxy url in dev mode.

• If API calls are failing with no authorisation token, then do the following:

Create a .env file with following:

REACT_APP_USER_TYPE=

REACT_APP_CITIZEN_TOKEN=a3e5f0a2-4ff0-4680-855e-75051fb3e8f7

REACT_APP_EMPLOYEE_TOKEN=061bad07-c0d5-4200-a74f-ca5ed090cf30

REACT_APP_GRO_TOKEN=43af4c18-6418-4a35-8484-31f0700f465a

REACT_APP_LME_TOKEN=fa9f4184-dc64-495d-bded-31674c71b09e

FSM UI Implementation: Guidelines & FAQs

Enable FSM

Modules are enabled by the MDMS config at: .

It is done on dev via:

Create a new branch for the state if already doesn’t exist from the master of repo:

.

To add and enable any module in the new UI, src/App.js needs to be changed.

We only export the init function of the module to take care of all the initialisations:

import { initFSMComponents } from "@egovernments/digit-ui-module-fsm";

const enabledModules = ["FSM"];

initFSMComponents();

Changing CSS

CSS classes are published over CDN and can be seen at: https://unpkg.com/@egovernments/digit-ui-css/dist/index.css

Any class can be overwritten. Make changes in the src/index.css file.

Customising Fields in a Form

Add any new component created in the registry,

Digit.ComponentRegistryService.setupRegistry({

SelectName: SelectName});

Application config: The default config can be found at.

The config has different items in the application form. The new config, if made, needs to be initialised at Digit.Customizations.FSM.applicationFormConfig

• label: is the employee side label

• texts: is used for citizen side step form

• component: the component that is to be rendered here. Any component can be created to show here; examples can be seen at, These components are passed following params:

- t: translate function to be used to convert a key to localized text. e.g., t("CS_CREATECOMPLAINT_MOHALLA")

- config: current step config as shown above

- onSelect: on clicking of next or input, this handled to be called to save the data in the form state

- userType: employee or citizen

- formData: the current form state

Similarly, in case of Applicant Details, MDMS config is located at:

The Trip Details MDMS config is located at:

Customising Views

Application details can be customised via defining: Digit.Customizations.FSM.getApplicationDetailsTableRows

The function will be passed following params:

• id: application id

• service: application response object

• role: currently logged in user role CITIZEN or EMPLOYEE

• t: function used for translation

Customising Inbox Status Filter

Status can be filtered and rendered by MDMS config located at:

Following customisations are available:

• userRole : Role of the logged in user for application of customisation.

• statuses : List of statuses that needs to be shown for the specified user.

• zeroCheck : Check if the total application count for any status is 0 to hide or rearrange the list.

• fixed : Limits the status filter list to the specified list.

Implementation Approach

This section presents an outline of the methodology used for implementing Feacal Sludge Management (FSM) on a state-wide level. The implementation process is divided into seven distinct stages, each with specific entry and exit criteria, as well as designated roles and responsibilities. These measures are put in place to ensure objective monitoring and decision-making, ultimately contributing to the overall success of the programme. The document provides detailed information about each stage.

The estimated timeline for completing the implementation programme is approximately 38 to 42 weeks. It is, however, essential to accomplish the activities and meet the exit criteria established for each stage in order to adhere to this timeline.

FSM Implementation Stages

Stage 0: Programme Setup/Onboarding

This set of initial crucial activities is initiated after receiving an enrolment letter or a Memorandum of Understanding (MoU) from the state. Successfully completing these activities ensures that the programme begins with essential personnel, teams, and funding.

• Duration: 4-6 weeks

• Entry criteria: Acceptance letter/MoU from the state

• Exit criteria:

- Finalise the FSM programme vision

- Secure funding for the programme

- Establish the state-specific procurement process

- Complete team sign-up and onboarding

Stage 1: Programme Kick-Off

This stage may require multiple interactions/meetings with different interest groups. The principal objective of these interactions is to identify the scope and planning strategies for phasing/rollout, create an active collaboration and governance approach, as well as agree on a high-level timeline for the engagement.

• Duration: 4-6 weeks

• Entry criteria:

- Programme setup (Stage 0) is complete

- Implementation partner is signed-up

• Exit criteria:

- Publish the programme charter

- Implementation plan agreement with priority features and broad timelines

- Programme governance model

- Programme success metrics

- Capacity building

- Data preparation/collection kick-off from the pilot urban local bodies (ULBs)

- Cloud infrastructure procured

• Key activities:

- Project kick-off meeting and consultation with stakeholders

- Identify and agree on a high-level scope and exclusions

- Identify pilot ULBs

- Product walkthroughs

- Define the project steering committee structure and the project governance process

- Define the phases of rollout/deployment

- Agreement on deployment priorities and high-level delivery timelines

- Identify and study all FSM processes

- Citizen services/channels around it

- Finalise the programme success metrics for rollout, adoption, and governance adhering to the vision of the programme

- Internal capacity building, programme logistics at the state-level and ULBs, as per the current scenario

- Collection of baseline data to measure end-line target for the product (revenue generated, total properties in ULBs, etc.)

- Circulation of baseline data collection templates to the state

Stage 2: Solution Design

During this stage, it is expected that key state officials and subject matter experts will collaborate with the implementation team by sharing state acts and policies, and providing interpretation. This stage serves as a foundation for incorporating the state-specific product features into the product configuration report.

• Duration: 4-6 weeks

• Entry criteria:

- Programme charter

• Exit criteria:

- State sign-off and the publication of FSM processes, data templates, and workflows

- Finalisation of the rollout plan in different phases

- Product configuration report sign-off

- Agreement on necessary state-specific product customisations

- Finalisation and state sign-off on the programme tracking mechanism

- Establishment of an initial reporting structure

- Definition of dashboard key performance indicators (KPIs)

- Sign-off on the data approach, including collection, migration, correction, sync-up, and validation

- Completion of a detailed project plan

• Key activities:

- Standardisation of all FSM processes

- Initiation of policy changes, if necessary, based on the defined processes

- Definition of success criteria

- Conducting a product familiarisation workshop

- Initiation of master data collection from pilot ULBs

- Finalisation of data migration, collection, and sync-up approach as per requirements

- Finalisation of the data validation approach

- Finalisation of dashboard design for programme tracking

Stage 3: Configuration & Customisation

This stage involves a series of developments, according to the detailed project plan, to ensure the smooth functioning of the customised product. It includes activities such as master data collection and environment setup. Additionally, monitoring and maintenance strategies are implemented.

• Duration: 6-8 weeks

• Entry criteria:

- The product configuration report has been signed off by the state

- Sign-off on the data approach (data collection, migration, correction, sync-up, and validation)

- State sign-off and publication of FSM processes, data templates, and workflows

- Detailed project plan

• Exit criteria:

- Configured/customised product ready for User Acceptance Testing (UAT)

- Establishment of monitoring, support, and maintenance for dashboards

- Finalisation of initial reporting and dashboard key performance indicators (KPIs)

- Identification of participants for the UAT session

• Key activities:

- Setting up development environments

- Development/customisation of reports and dashboards

- Development/integration of the portal

- Integration with third-party systems (Example: payment gateway, handheld/POS device)

- Updating user manuals and other key documents

- Preparation and execution of test cases

- Setting up monitoring, support, and maintenance processes, tools, and dashboards

- Identifying nodal officers at the ULB level for day-to-day support

- Migration and verification of pilot ULB data in accordance with the data agreement signed off by the state

Stage 4: UAT & Go-Live

During this stage, a product demonstration followed by a hands-on session is conducted for ULB officials. The necessary training for ULB officials and identification of resources required for User Acceptance Testing (UAT) take place. Additionally, the establishment of the state support team, and the initiation of the required processes occur.

• Duration: 2-3 weeks

• Entry criteria:

- Configured/customised product ready for UAT

- Availability of pilot ULB officials associated with FSM for UAT and training

• Exit criteria:

- UAT sign-off & go-live for pilot ULBs

- Setup of review and monitoring cadence

• Key activities:

- UAT environment setup

- Identification and resolution of issues/bugs

- Regression UAT and sign-off from pilot ULBs/state

- Setting up of the production environment

- Establishing the support centre and related processes (helpdesk)

- Conducting training sessions for users and trainers

- Identifying master trainers from the ground for simultaneous training

- Training the support resources

- Implementing marketing and promotion activities

- Conducting the go-live and launch event

- Setting up of the review and monitoring cadence/team

- General FSM implementation activities link

Stage 5: Rollout

After a successful go-live in the pilot ULBs, and subsequent fine-tuning to stabilise the product, the solution will be gradually rolled out to the remaining ULBs in phases. The state team's guidance and support will be necessary to create rollout plans and ensure the availability of the required infrastructure for training and deployment in each ULB.

• Duration: 5-6 weeks

• Entry criteria:

- Successful pilot implementation in the state

- Less than 3 open critical incidents (issues) related to the product, implementation, and data

• Exit criteria:

- Operational adoption tracking and review cadence established

- Effectiveness of the helpdesk assured

- Resolution of critical bugs

- Initiation of programme success metrics tracking

• Key Activities:

- Configuring ULBs phase-wise according to the project plan

- Verifying and migrating ULB data phase-wise based on the data agreement sign-off provided by the state

- Implementing a bug ticketing tool for resolving ground-level issues by the state team

- Conducting user training at the district-level

- Rolling out the solution pan-state in phases

Stage 6: Sustenance and Ongoing Improvement

The final stage involves implementing strategies to ensure the long-term sustainability of the product in the state. Systems are established to continuously track data, and provisions are made to enhance the product based on new insights from the data.

• Duration: Ongoing process

• Entry criteria:

- Rollout phase 1 (First set of ULBs where the rollout will occur after the pilot

• Key activities:

- Conducting adoption review meetings in line with the programme's vision, chaired by the programme head

- Implementing plans for ongoing sustenance, including:

a. Funding arrangements

b. IT support

c. Assessing process effectiveness and making improvements as needed

Roles & Responsibilities

Steering Committee: The steering committee comprises the senior bureaucrats and leaders from the state, HUDD, EY, PwC, eGov, and Janaagraha. They are responsible for the overall programme guidance, and fulfill the domain advisory role.

Project Management Unit (PMU): This unit will be responsible for the execution of the programme on behalf of the state team. They work in close collaboration with the ULBs, the technical partner (eGov), and other stakeholders.

eGoV team: The eGoV team is the technical partner of the project, and it will provide all necessary support to the state concerning implementation, programme design, etc.

Resource requirements for the PMU required to be formed by the state:

The technical implementation team should have the following technical skill-sets to work on FSM:

Development team skill-set

• Java and REST APIS

• Postgres

• Maven

• Spring framework

• Basics of 2D CAD Drawings

• Git

• Postman

• YAML/JSON

DevOps team skill-set

• Strong working knowledge of Linux, command, VM Instances, networking, storage.

• The session, cache, and token handling (Redis-server).

• Understanding of VM types, Linux OS types, LoadBalancer, VPC, Subnets, Security Groups, Firewall, Routing, DNS.

• Experience setting up CI like Jenkins and creating pipelines.

• Artifactory - Nexus, verdaccio, DockerHub, etc.

• Experience in setting up SSL certificates and renewal.

• Gitops, Git branching, PR review process. Rules, Hooks, etc.

• JBoss Wildfly, Apache, Nginx, Redis and Postgres.

Overview

Workflows are a series of steps that moves a process from one state to another by actions performed by different kind of actors - humans, machines, time-based events, etc., to achieve a goal such an onboarding an employee, or approving an application or granting a resource, among others. The egov-workflow-v2 is a workflow engine which helps in performing these operations seamlessly using a predefined configuration.

Pre-requisites

Before you proceed with the documentation, the following pre-requisites must be met:

• Java 8

• Kafka server is up and running.

• egov-persister service is running and has workflow persister config path added in it.

• PSQL server is running and the database is created to store workflow configuration and data.

Interaction Diagram

Key Functionalities

• Always allow anyone with a role in the workflow state machine to view the workflow instances and comment on it.

• On the creation of workflow, it will appear in the inbox of all employees who have roles which can perform any state transitioning actions in this state.

• Once an instance is marked to an individual employee, it will appear only in that employee's inbox. Point 1 will still hold true and all others participating in the workflow can still search it and act if they have the necessary action available to them

• If the instance is marked to a person who cannot perform any state transitioning action, they can still comment/upload and mark it to anyone else.

• Overall SLA : SLA for the complete processing of the application/entity.

• State level SLA: SLA for a particular state in the workflow.

Deployment Details

1. Deploy latest version of egov-workflow-v2 service.

2. Add businessService persister yaml path in persister configuration.

3. Add role action mapping for BusinessService API’s.

4. Overwrite the egov.wf.statelevel flag (true for state level and false for tenant level).

5. Create businessService (workflow configuration) according to product requirements.

6. Add role action mapping for /processInstance/_search API.

7. Add workflow persister yaml path in persister configuration.

Configuration Details

For configuration details, refer to the links in reference docs.

Integration

Integration Scope

The workflow configuration can be used by any module which performs a sequence of operations on an application/entity. It can be used to simulate and track processes in organisations to make it more efficient to and increase the accountability.

Integration Benefits

• Role-based workflow.

• Easy way of writing rule.

• File movement within workflow roles.

Steps to Integration

1. To integrate, host of egov-workflow-v2 should be overwritten in helm chart.

2. /process/_search should be added as the search endpoint for searching workflow processsInstance object. The search endpoint provides pagination with default value configurable. Pagination is controlled by passing limit and offset in query parameter.

3. /process/_transition should be added to perform an action on an application. (It’s for internal use in modules and should not be added in role action mapping)

4. The workflow configuration can be fetched by calling _search API to check if data can be updated or not in the current state.

Reference Docs

API List

Note: All the API’s are in the same postman collection, therefore, the same link is added in each row.

The Desludging Operators or DSOs are responsible for initiating and completing action on citizen requests for desludging services. The requests are routed to the respective DSOs by the urban local body (ULB) officials. The DSOs update the application status once the services are delivered and the payments are collected.

DSOs can do the following:

• ​Assign vehicles for desludging services​

• Decline service requests​

• Complete service requests​

Login

DSOs operators are provided with credentials to log in to the system.

User Actions

On this page, the following actions can be performed:

• Enter username and password

• Select city for login

• Reset password by clicking on the “Forgot Password” link

On clicking continue, DSOs are redirected to the FSM homepage.

User Actions

On this page, the following actions can be performed in the FSM card:

• Click on Inbox to view assigned requests

• Search for historical requests serviced

• Change language

• Edit profile details by clicking on the user icon on top right hand corner

• Logout by clicking on the user icon on the top right hand corner

Approve requests

Requests assigned to the DSO can be viewed by clicking on the Inbox link in the FSM homepage.

Requests pending for acceptance will be viewable in the status: Pending for DSO Approval.

User Actions

The following actions can be performed:

• Search for an active application using “Application No.” and “Mobile No.”

• Clear search by clicking on “Clear Search’”

• View and update applications by clicking on an application number

• Filter applications by locacilty using the ‘Locality’ dropdown

• Filter applications by ‘Status’

• Search for past applications by using “Search Application”

• Sort applications by Application date.

On clicking on an application number, application details are displayed.

User Actions

The following actions can be performed:

• View application details

• Click on the “Take Action” button

The take action button has the following options:

• Assign Vehicle

• Decline Request

A request can be approved by assigning a vehicle. Clicking on “Assign Vehicle’’ will display the following pop-up:

User Actions

The following actions can be performed:

• Update Vehicle Registration No.

• Close pop-up by clicking on the Close button on the pop-up.

• Close pop-up by clicking on the cross icon on the top right of the pop-up

• Confirm decline request by clicking on the “Assign Vehicle” button

A snack bar will confirm assignment of vehicle and the application timeline will be updated to DSO in Progress.

Update/Schedule Trips

Once DSO is in progress, the number of trips can be updated.

User Actions

The following actions can be performed:

• Search for an active application using “Application No.” and “Mobile No.”

• Clear search by clicking on “Clear Search”

• View and update applications by clicking on an application number

• Filter applications by ‘Locacilty’ using the locality dropdown

• Filter applications by ‘Status’

• Search for past applications by using “Search Application”

On clicking on an application number, application details are displayed.

User Actions

The following actions can be performed:

• View application details

• Click on the ‘Take Action’ button

The take action button has the following options:

• Complete Request

• Update/Schedule Trips

On clicking on Update/Schedule trips, the following pop up is displayed:

User Actions

The following actions can be performed:

• Increase the number of trips by clicking on the + button

• Decrease the number of trips by clicking on the - button

• Close pop-up by clicking on the Close button on the pop-up.

• Close pop-up by clicking on the cross icon on the top right of the pop-up

• Confirm update/schedule trips by clicking on the “Update/schedule” button

A snack bar will confirm that the number of trips have been updated

Complete Request

Once the service request has been completed and all pending payments have been collected, the same has to be confirmed in the system. This can be done by selecting the “Complete Request” button in the “Take Action” button. On clicking on Complete Request, the following pop up is displayed:

User Actions

The following actions can be performed:

• Confirm/Update service date

• Confirm/Update Volume of waste collected

• Confirm/Update pit details

• Upload pit photo

• Close pop-up by clicking on the Close button on the pop-up.

• Close pop-up by clicking on the cross icon on the top right of the pop-up

• Confirm details by clicking on the ‘Completed’’ button

A snack bar will confirm that request has been completed and the status will be updated to “Waiting for Disposal”.

Decline Request

DSOs can choose to decline unserviceable service requests. Applications can be rejected by a DSO in the “Pending for DSO Approval” stage.

User Actions

The following actions can be performed:

• Search for an active application using “Application No.” and “Mobile No.”

• Clear search by clicking on “Clear Search”

• View and update applications by clicking on an application number

• Filter applications by ‘Locacilty’ using the locality dropdown

• Filter applications by ‘Status’

• Search for past applications by using “Search Application”

On clicking on an application number, application details are displayed.

User Actions

The following actions can be performed:

• View application details

• Click on the “Take Action” button

The take action button has the following options:

• Assign Vehicle

• Decline Request

Clicking on “Decline Request’’ will display the following pop-up:

User Actions

The following actions can be performed:

• Reason for declining

• Enter comments

• Close pop-up by clicking on the Close button on the pop up.

• Close pop-up by clicking on the cross icon on the top right of the pop-up

• Confirm decline Request by clicking on the “Decline Request” button

A snack bar will confirm decline and the application timeline will be updated to DSO Rejected.

There are three main updates in FSM v1.2.1 for employee UI:

1. Application timeline

2. Photo viewed by employee/DSO

3. Payment mode while completing request

1. Application Timeline:

An employee can see the application status in application timeline with provider details.

Technical Implementation Details:

The path for the code:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/index.js

The code snippet to render application timeline:

The code snippet for extracting the provider info for each status:

2. Photo viewed by employee/DSO

An employee/DSO can view the photo uploaded by the employee/DSO in complete request action.

Technical Implementation Details:

The path for the code:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/index.js

The code snippets to render the field:

ViewImages.js are the common component used to fetch and render the Image file id. The path is shown below:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/components/ViewImages.js

3. Payment mode while completing request

An employee has to select the payment mode while completing the request.

Technical Implementation Details:

File path:

frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/config/CompleteApplication.js

The code snippet to render the field.

MDMS file fetch for payment mode:

Sujog-FSM is implemented as a part of SUJOG for the state of Odisha. Odisha is currently on v1.3 of DIGIT Sanitation. The following is the list of changes made to the product for implementation:

1. Localisations:

The localisation changes done according to the application flow:

2. Additional Builds: Urban-rural convergence is an initiative that aims to ensure access of sanitation services to all gram panchayats (GPs) via urban local bodies (ULBs) located closest to them. With efforts in implementing decentralised waste management across 114 ULBs as well as enabling the rural population to avail sanitation facilities from urban areas located nearby, eGov with CPR (post-field observations and research) decided to include gram panchayats in SUJOG FSSM as part of this initiative. See details of the customisation here.

3. The following MDMS have been configured.

• Property-type

• Property Sub-type

• Slum Names

• GP List

• Village List

• FSTP details

4. The following user categories/roles have been created:

5. FSM Related builds deployed

6. URL and Credentials of SUJOG-UAT environment for reference.

ULB employee URL : https://sujog-dev.odisha.gov.in/employee/user/login

Citizen URL : https://sujog-dev.odisha.gov.in/citizen/user/login

Credentials:

ULB employee Username : EMP-AND-000167

FSTPO Username : EMP-AND-000168

Password : eGov@123

Overview

Initiative to provide access to sanitation services to all gram panchayats (GPs) via Urban Local Bodies (ULBs) located closest to them.

Objective

DIGIT Sanitation plans to provide a provision of sanitation services to rural areas to their nearby cities.

Author

Document History