Desludging Operator

Urban Local Body

Treatment Operator

Citizen

Coming soon...

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

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:

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

Programme

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

Overview

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

MDMS Changes

See our test cases below:

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

The QA test cases for Urban-Rural Convergence (URC) are given 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

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

FSM Components

Installation Pre-reads

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.

Conclusion

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

Pre-read:

Prerequisites

7. ​

   1. You will get a Secret Access Key and Access Key ID. Save them.

   2. Open the terminal and run the following command. You have already installed the AWS CLI, and you have the credentials saved. (Provide the credentials. You can leave the region and output format blank).

   Copy

   aws configure --profile egov-workshop-account 
   
   AWS Access Key ID []:<Your access key>
   AWS Secret Access Key []:<Your secret key>
   Default region name []: ap-south-1
   Default output format []: text

   The above will create the following file in your machine as /Users/.aws/credentials.

   Copy

   [egov-test-account] 
   aws_access_key_id=*********** 
   aws_secret_access_key=****************************

Before we provision cloud resources, we must understand what resources need to be provisioned by Terraform to deploy DIGIT.

The following picture shows the key components (EKS, Worker Nodes, Postgress DB, EBS Volumes, Load Balancer).

EKS Architecture for DIGIT Setup

Considering the above deployment architecture, the following is the resource graph we will provision using Terraform in a standard way so that every time and for every env, it will have the same infra.

• EKS control plane (Kubernetes master)

• Work node group (VMs with the estimated number of vCPUs, memory)

• EBS volumes (Persistent volumes)

• RDS (PostGres)

• VPCs (Private network)

• Users to access, deploy, and read-only

Understand the resource graph in Terraform script:

• Here, we have already written the Terraform script that provisions the production-grade DIGIT infra and can be customised with the specified configuration.

git clone --branch release https://github.com/egovernments/iFix-DevOps.git
cd iFix-DevOps/infra-as-code/terraform


└── modules
    ├── db
    │   └── aws
    │       ├── main.tf
    │       ├── outputs.tf
    │       └── variables.tf
    ├── kubernetes
    │   └── aws
    │       ├── eks-cluster
    │       │   ├── main.tf
    │       │   ├── outputs.tf
    │       │   └── variables.tf
    │       ├── network
    │       │   ├── main.tf
    │       │   ├── outputs.tf
    │       │   └── variables.tf
    │       └── workers
    │           ├── main.tf
    │           ├── outputs.tf
    │           └── variables.tf
    └── storage
        └── aws
            ├── main.tf
            ├── outputs.tf
            └── variables.tf

Example:

• VPC Resources:

  • VPC

  • Subnets

  • Internet Gateway

  • Route Table

• EKS Cluster Resources:

  • IAM Role to allow EKS service to manage other AWS services.

  • EC2 Security Group to allow networking traffic with the EKS cluster.

  • EKS Cluster.

• EKS Worker Nodes Resources:

  • IAM role allowing Kubernetes actions to access other AWS services.

  • EC2 Security Group to allow networking traffic.

  • Data source to fetch the latest EKS worker AMI.

  • AutoScaling Launch Configuration to configure worker instances.

  • AutoScaling Group to launch worker instances.

• Database

  • Configuration in this directory creates a set of RDS resources, including DB instance, DB subnet group, and DB parameter group.

• Storage Module

  • Configuration in this directory creates EBS volume and attaches it together.

  ​

• The following main.tf with create s3 bucket to store all the state of the execution to keep track.

  iFix-DevOps/Infra-as-code/terraform/sample-aws/remote-state

provider "aws" {
  region = "ap-south-1"
}

#This is a bucket name that you can name as you wish
resource "aws_s3_bucket" "terraform_state" {
  bucket = "try-workshop-yourname" 

  versioning {
    enabled = true
  }

  lifecycle {
    prevent_destroy = true
  }
}

#This is a bucket name that you can name as you wish
resource "aws_dynamodb_table" "terraform_state_lock" {
  name           = "try-workshop-yourname"
  read_capacity  = 1
  write_capacity = 1
  hash_key       = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

1. The following main.tf contains the detailed resource definitions that need to be provisioned.

   Dir: iFix-DevOps/Infra-as-code/terraform/sample-aws

# master configs, terraform state helps to maintain the flow of the execution
terraform {
  backend "s3" {
    bucket = "try-workshop-yourname"
    key = "terraform"
    region = "ap-south-1"
  }
}

# Network Module
module "network" {
  source             = "../modules/kubernetes/aws/network"
  vpc_cidr_block     = "${var.vpc_cidr_block}"
  cluster_name       = "${var.cluster_name}"
  availability_zones = "${var.network_availability_zones}"
}

# PostGres DB
module "db" {
  source                        = "../modules/db/aws"
  subnet_ids                    = "${module.network.private_subnets}"
  vpc_security_group_ids        = ["${module.network.rds_db_sg_id}"]
  availability_zone             = "${element(var.availability_zones, 0)}"
  instance_class                = "db.t3.medium"
  engine_version                = "11.5"
  storage_type                  = "gp2"
  storage_gb                    = "100"
  backup_retention_days         = "7"
  administrator_login           = "egovdev"
  administrator_login_password  = "${var.db_password}"
  db_name                       = "${var.cluster_name}-db"
  environment                   = "${var.cluster_name}"
}

# **********  Uses with various access like Admin, Dev, Deploy
module "iam_user_deployer" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-user"

  name          = "${var.cluster_name}-kube-deployer"
  force_destroy = true  
  create_iam_user_login_profile = false
  create_iam_access_key         = true

  # User "egovterraform" has uploaded his public key here - https://keybase.io/egovterraform/pgp_keys.asc
  pgp_key = "${var.iam_keybase_user}"
}

module "iam_user_admin" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-user"

  name          = "${var.cluster_name}-kube-admin"
  force_destroy = true  
  create_iam_user_login_profile = false
  create_iam_access_key         = true

  # User "egovterraform" has uploaded his public key here - https://keybase.io/egovterraform/pgp_keys.asc
  pgp_key = "${var.iam_keybase_user}"
}

module "iam_user_user" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-user"

  name          = "${var.cluster_name}-kube-user"
  force_destroy = true  
  create_iam_user_login_profile = false
  create_iam_access_key         = true

  # User "test" has uploaded his public key here - https://keybase.io/test/pgp_keys.asc
  pgp_key = "${var.iam_keybase_user}"
}



# ********** EKS Cluster (Control Plane) **********
data "aws_eks_cluster" "cluster" {
  name = "${module.eks.cluster_id}"
}

data "aws_eks_cluster_auth" "cluster" {
  name = "${module.eks.cluster_id}"
}
provider "kubernetes" {
  host                   = "${data.aws_eks_cluster.cluster.endpoint}"
  cluster_ca_certificate = "${base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)}"
  token                  = "${data.aws_eks_cluster_auth.cluster.token}"
  load_config_file       = false
  version                = "~> 1.11"
}

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "${var.cluster_name}"
  cluster_version = "${var.kubernetes_version}"
  subnets         = "${concat(module.network.private_subnets, module.network.public_subnets)}"

  tags = "${
    map(
      "kubernetes.io/cluster/${var.cluster_name}", "owned",
      "KubernetesCluster", "${var.cluster_name}"
    )
  }"

  vpc_id = "${module.network.vpc_id}"

  # ********** Worker Nodes
  worker_groups_launch_template = [
    {
      name                    = "spot"
      subnets                 = "${concat(slice(module.network.private_subnets, 0, length(var.availability_zones)), slice(module.network.public_subnets, 0, length(var.availability_zones)))}"
      override_instance_types = "${var.override_instance_types}"
      asg_max_size            = 4
      asg_desired_capacity    = 4
      kubelet_extra_args      = "--node-labels=node.kubernetes.io/lifecycle=spot"
      additional_security_group_ids = ["${module.network.worker_nodes_sg_id}"]
      spot_allocation_strategy= "capacity-optimized"
      spot_instance_pools     = null
    },
  ]

  map_users    = [
    {
      userarn  = "${module.iam_user_deployer.this_iam_user_arn}"
      username = "${module.iam_user_deployer.this_iam_user_name}"
      groups   = ["system:masters"]
    },
    {
      userarn  = "${module.iam_user_admin.this_iam_user_arn}"
      username = "${module.iam_user_admin.this_iam_user_name}"
      groups   = ["global-readonly", "digit-user"]
    },
    {
      userarn  = "${module.iam_user_user.this_iam_user_arn}"
      username = "${module.iam_user_user.this_iam_user_name}"
      groups   = ["global-readonly"]
    },    
  ]
}

# ********** EBS Volumes for the statefulsets (PVCs)
module "es-master" {

  source = "../modules/storage/aws"
  storage_count = 3
  environment = "${var.cluster_name}"
  disk_prefix = "es-master"
  availability_zones = "${var.availability_zones}"
  storage_sku = "gp2"
  disk_size_gb = "2"

}
module "es-data-v1" {

  source = "../modules/storage/aws"
  storage_count = 3
  environment = "${var.cluster_name}"
  disk_prefix = "es-data-v1"
  availability_zones = "${var.availability_zones}"
  storage_sku = "gp2"
  disk_size_gb = "25"

}

module "zookeeper" {

  source = "../modules/storage/aws"
  storage_count = 3
  environment = "${var.cluster_name}"
  disk_prefix = "zookeeper"
  availability_zones = "${var.availability_zones}"
  storage_sku = "gp2"
  disk_size_gb = "2"

}

module "kafka" {

  source = "../modules/storage/aws"
  storage_count = 3
  environment = "${var.cluster_name}"
  disk_prefix = "kafka"
  availability_zones = "${var.availability_zones}"
  storage_sku = "gp2"
  disk_size_gb = "50"

}

Custom variables/configurations:

You can define your configurations in variables.tf and provide the env-specific cloud requirements so that using the same Terraform template, you can customise the configurations.

├── iFix-dev
│   ├── main.tf 
│   ├── outputs.tf
│   ├── providers.tf
│   ├── remote-state
│   │   └── main.tf
│   └── variables.tf

Following are the values you need to mention in the following files. The blank ones will be prompted for inputs during execution.

## Add Cluster Name
variable "cluster_name" {
  default = "<Desired Cluster name>"  #eg: my-digit-eks
}

## Add vpc_cidr_block
variable "vpc_cidr_block" {
  default = "CIDR" 
}

# If you want prod grade N/W, you can define HA, DRS with multi zone
variable "network_availability_zones" {  
  default = ["ap-south-1b", "ap-south-1a"]
}

# Which zone, it matters
variable "availability_zones" {
  default = ["ap-south-1b"]
}

variable "kubernetes_version" {
  default = "1.18"
}

# instance type for your worker nodes like r5a.large is 8 vCPU and 16GB RAM
variable "instance_type" {
  default = "r5a.large"
}

# spot instance configuration
variable "override_instance_types" {
  default = ["r5a.large", "r5ad.large", "r5d.large", "t3a.xlarge"] 
}

# number of machines as per estimate
variable "number_of_worker_nodes" {
  default = "3"
}

##Add ssh key in case you want to ssh to nodes
variable "ssh_key_name" {
  default = "ssh key name"
}

# terraform users ssh public key, you need to one for you, refer below to create yours
variable "iam_keybase_user" {
  default = "keybase:egovterraform"
}

# will be prompted to provide during the execution
variable "db_password" {}

​

Important: Create your keybase key before you run the terraform

Run Terraform

Now that we know what the Terraform script does, the resources graph that it provisions, and what custom values should be given to your env, let us begin to run the Terraform scripts to provision infra required for deploying DIGIT on AWS.

1. First CD into the following directory, run the following command 1-by-1, and watch the output closely.

cd DIGIT-DevOps/infra-as-code/terraform/sample-aws/remote-state
terraform init
terraform plan
terraform apply


cd DIGIT-DevOps/infra-as-code/terraform/sample-aws
terraform init
terraform plan
terraform apply

Upon successful execution, the following resources get created, which can be verified by the command "terraform output".

• s3 bucket: to store terraform state.

• Network: VPC, security groups.

• EKS cluster: with master(s) & worker node(s).

• Storage(s): for es-master, es-data-v1, es-master-infra, es-data-infra-v1, zookeeper, kafka, kafka-infra.

aws sts get-caller-identity

# Run the below command and give the respective region-code and the cluster name
aws eks --region <region-code> update-kubeconfig --name <cluster_name>

1. Finally, verify that you can connect to the cluster by running the following command.

kubectl config use-context <your cluster name>

kubectl get nodes

NAME                                             STATUS AGE   VERSION               OS-Image           
ip-192-168-xx-1.ap-south-1.compute.internal   Ready  45d   v1.15.10-eks-bac369   Amazon Linux 2   
ip-192-168-xx-2.ap-south-1.compute.internal   Ready  45d   v1.15.10-eks-bac369   Amazon Linux 2   
ip-192-168-xx-3.ap-south-1.compute.internal   Ready  45d   v1.15.10-eks-bac369   Amazon Linux 2   
ip-192-168-xx-4.ap-south-1.compute.internal   Ready  45d   v1.15.10-eks-bac369   Amazon Linux 2

You are all set to deploy the product.

Here are the articles in this section:

This guide offers a systematic view of how to create the application screens on DIGIT.

UI Development Pre-requisites

Technical pre-requisites

• Knowledge of the DIGIT UI framework

• Prior knowledge of React JS

• Prior knowledge of Redux/Hooks

• Prior knowledge of SCSS/React StoryBook

• Prior knowledge of Git

• Prior knowledge of Queries and Mutations

Citizen Module Setup

This section of the guide enables developers to create their own front-end citizen module from scratch which they can deploy on top of DIGIT UI. The new module will be visible as a ‘card’ in the DIGIT citizen portal.

Steps to build a citizen portal for a module:

Create Project Structure:

Project Structure

Front-end module project structure

Follow the steps detailed in this doc.

Create Project Structure

• Go to micro-ui--internals → packages → modules.

• Inside the module, create a folder and provide a name for the service. For instance, the service name here is birth registration.

• Create folder fsm (you can give any name).

• Add the package.json to the created folder. Mention the module name and other dependencies here.

{
 "name": "@egovernments/digit-ui-module-fsm",
 "version": "1.6.1",
 "license": "MIT",
 "main": "dist/index.js",
 "description": "Digit FSM Module",
 "module": "dist/index.modern.js",
 "source": "src/Module.js",
 "files": [
   "dist"
 ],
 "scripts": {
   "start": "microbundle-crl watch --no-compress --format modern,cjs",
   "build": "microbundle-crl --compress --no-sourcemap --format cjs",
   "prepublish": "yarn build"
 },
 "peerDependencies": {
   "react": "17.0.2",
   "react-router-dom": "5.3.0"
 },
 "dependencies": {
   "@egovernments/digit-ui-react-components": "^1.6.1",
   "microbundle-crl": "0.13.11",
   "react": "17.0.2",
   "react-dom": "17.0.2",
   "react-hook-form": "6.15.8",
   "react-i18next": "11.16.2",
   "react-query": "3.6.1",
   "react-router-dom": "5.3.0",
   "react-time-picker": "4.2.1"
 }
}

After creating the package.json for FSM, the project structure (as seen in the image below) is created:

Install Dependency:

Add MDMS (Master Data Management Service) Configuration.

When creating a new module, the module needs to be enabled in citymodule.json. A sample module is available for reference here: .

For the purpose of illustration here, add the following module (birth registration) as given below:

{
 "tenantId": "pb",
 "moduleName": "tenant",
 "citymodule": [
   {
     "module": "FSM",
     "code": "FSM",
     "bannerImage": "https://egov-uat-assets.s3.amazonaws.com/FSM.png",
     "active": true,
     "order": 2,
     "tenants": [
       {
         "code": "pb.jalandhar"
       },
       {
         "code": "pb.amritsar"
       }
     ]
   }

The FSM UI module needs to be registered in three places so that it will be available for the developer at run-time as well as at the time of deployment.

Below are the three places where the module needs to be registered:

micro-ui/web/micro-ui-internals/package.json

micro-ui/web/micro-ui-internals/example/package.json

micro-ui/web/micro-ui-internalsWeb/package.json

Micro-ui-internals:

Open the micro-ui-internals package.json file and add this module as a dependency.

"dev:fsm": "cd packages/modules/fsm && yarn start",

"build:fsm": "cd packages/modules/fsm && yarn build",

In the example/package.json, add the following line:

"@egovernments/digit-ui-module-fsm":”1.6.1”,

In the web/package.json, add the following line:

"@egovernments/digit-ui-module-fsm":”1.6.1”,

Import Required Components:

DIGIT comes with common re-usable libraries that can be imported for use in a new module. CSS , libraries , common , react components can be imported by adding into package.json.

"@egovernments/digit-ui-css": "1.5.3",

"@egovernments/digit-ui-libraries":"1.5.3",

"@egovernments/digit-ui-module-common":"1.5.3",

"@egovernments/digit-ui-module-fsm":"1.5.0",

"@egovernments/digit-ui-module-dss":"1.5.3",

"@egovernments/digit-ui-react-components":"1.5.3",

Common components live in micro-ui/web/micro-ui-internals/packages/react-components micro-ui/web/micro-ui-internals/packages/css. DIGIT components that we are reusing:

1. FormComposer

2. ActionBar

3. Banner

4. Card

5. CardText

6. Loader

7. SubmitBar

8. AppContainer

9. BackButton

10. PrivateRoute

11. Icons

12. CitizenHomecard

Write Citizen Module Code

This section will walk you through the code that needs to be developed for the application. Detailed user screen wireframes should be available at this point for development.

Following are the steps:

1. Create Application Form:

We need to create a form where users can enter all required information and submit the form. Create a file called index.js in the path below:

/web/micro-ui/internals/packages/module/br/src/pages/citizen/create/index.js

index.js will import the Formcomposer. Inside that, add the heading, label, and form components. The configuration file that will contain the actual form schema is mapped below in the following two lines. The newConfig.json file details are mentioned in the below sections:

import { newConfig } from "../../../components/config/config";

const configs = newConfig?newConfig:newConfig;

import { FormComposer } from "@egovernments/digit-ui-react-components";
import React from "react";
import { useTranslation } from "react-i18next";
import { newConfig } from "../../../components/config/config";


const Create = () => {
 const { t } = useTranslation();
 const configs = newConfig?newConfig:newConfig;
 return (
   <FormComposer
   heading={t("Create New Desludging Application")}
   label={t("ES_COMMON_APPLICATION_SUBMIT")}
   config={configs.map((config) => {
     return {
       ...config,
       body: config.body.filter((a) => !a.hideInEmployee),
     };
   })}
    fieldStyle={{ marginRight: 0 }}
 />
 );
};


export default Create;

2. Filling in config.js:

Create a file called config.js under the following path:

/micro-ui/web/micro-ui-internals/packages/modules/br/src/components/config.js

This file defines the form meta-data and structure. The form heading goes into the "head" field. Components inside the form go into the body field. This form config has already been mapped in the index.js file, and therefore, will be rendered onto the screen:

const newConfig = [
 {
   head: "ES_TITLE_APPLICANT_DETAILS",
   body: [
     {
       label: "ES_NEW_APPLICATION_APPLICATION_CHANNEL",
       isMandatory: true,
       type: "component",
       key: "channel",
       component: "SelectChannel",
       nextStep: "applicantName",
     },
     {
       type: "component",
       key: "applicationData",
       withoutLabel: true,
       component: "SelectName",
     },
     {
       type: "component",
       key: "paymentPreference",
       withoutLabel: true,
       component: "SelectPaymentType",
     },
   ],
 },
];


export default newConfig;

Components used in the newConfig.js:

3. Routing:

After adding the config.js and create/index.js, add routing for the birth registration form. Create the index.js into fsm/src/pages/citizen/index.js, where the private route will be added. In index.js, mention the path and component name, the component one needs to show or render when one hits that route.

import { AppContainer, BackButton,PrivateRoute } from "@egovernments/digit-ui-react-components";
import React from "react";
import {  Switch, useRouteMatch } from "react-router-dom";


import { useTranslation } from "react-i18next";






const App = () => {
 const { path, url, ...match } = useRouteMatch();
 const { t } = useTranslation();


 const Create = Digit?.ComponentRegistryService?.getComponent("Create");
 const Response = Digit?.ComponentRegistryService?.getComponent("Response");
  return (
   <span className={"pt-citizen"}>
     <Switch>
       <AppContainer>
       <BackButton>Back</BackButton>
      
         <PrivateRoute path={`${path}/new-application`} component={Create} />
         <PrivateRoute path={`${path}/response`} component={Response} />
       </AppContainer>
     </Switch>
   </span>
 );
};


export default App;

4. Filling in module.js:

module.js is the entry point of every module, so one needs to register all the components, links, code, etc.

import {  CitizenHomeCard, PTIcon } from "@egovernments/digit-ui-react-components";
import React, { useEffect } from "react";
import { useTranslation } from "react-i18next";
import { useRouteMatch } from "react-router-dom";
import CitizenApp from "./pages/citizen";
import Create from "./pages/citizen/create/index";
import EmployeeApp from "./pages/employee";
import Response from "./pages/citizen/create/Response";




const componentsToRegister = {
 Response,
 FSMCreate : Create,
};


export const FSMModule = ({ stateCode, userType, tenants }) => {
 const { path, url } = useRouteMatch();


 const moduleCode = "FSM";
 const language = Digit.StoreData.getCurrentLanguage();
 const { isLoading, data: store } = Digit.Services.useStore({ stateCode, moduleCode, language });


 if (userType === "citizen") {
   return <CitizenApp path={path} stateCode={stateCode} />;
 }


 return <EmployeeApp path={path} stateCode={stateCode} />;
};


export const FSMLinks = ({ matchPath, userType }) => {
 const { t } = useTranslation();




 const links = [
    {
     link: `${matchPath}/new-application`,
     i18nKey: t("FSM Registration”),
   },
 
 
 ];


 return <CitizenHomeCard header={t("FsmRegistration")} links={links} Icon={() => <PTIcon className="fill-path-primary-main" />} />;
};


export const initFSMComponents = () => {
 Object.entries(componentsToRegister).forEach(([key, value]) => {
   Digit.ComponentRegistryService.setComponent(key, value);
 });
};

5. Enable Module in the UI framework:

After registering all components, links and module code, enable it in two places:

1. Web/Src/app.js : In app.js we import the FSMModule, initFSMComponents, and FSMLinks and enable the FSM module.

import React from 'react';


import { initDSSComponents } from "@egovernments/digit-ui-module-dss";
import { PaymentModule, PaymentLinks, paymentConfigs } from "@egovernments/digit-ui-module-common";
import { DigitUI } from "@egovernments/digit-ui-module-core";
import { initLibraries } from "@egovernments/digit-ui-libraries";
import { initEngagementComponents } from "@egovernments/digit-ui-module-engagement";
import {initCustomisationComponents} from "./Customisations";
import { initCommonPTComponents } from "@egovernments/digit-ui-module-commonpt";
import { FSMModule ,initFSMModuleComponents ,FSMModuleLinks} from "@egovernments/digit-ui-module-br";


initLibraries();
//"WS" removed the ws enabledModules ;
const enabledModules = ["Payment","QuickPayLinks", "DSS","Engagement", "FSM"];
window.Digit.ComponentRegistryService.setupRegistry({
 ...paymentConfigs,
 PaymentModule,
 PaymentLinks,
 FSMModule,
 FSMLinks,


});


initFSMComponents();
initDSSComponents();
initEngagementComponents();


initCustomisationComponents();


function App() {
 const stateCode = window.globalConfigs?.getConfig("STATE_LEVEL_TENANT_ID") || process.env.REACT_APP_STATE_LEVEL_TENANT_ID;
 if (!stateCode) {
   return <h1>stateCode is not defined</h1>
 }
 return (
   <DigitUI stateCode={stateCode} enabledModules={enabledModules}  />
 );
}


export default App;

1. web/micro-ui-internals/example/src/index.js:

In index.js, we will import the FSMModule, initFSMComponents, and FSMLinks and enable the FSM module.

import React from "react";
import ReactDOM from "react-dom";
import { initLibraries } from "@egovernments/digit-ui-libraries";
import { FSMModule, initFSMComponents ,FSMLinks} from "@egovernments/digit-ui-module-br";
import { initDSSComponents } from "@egovernments/digit-ui-module-dss";
import { PaymentModule, PaymentLinks, paymentConfigs } from "@egovernments/digit-ui-module-common";
import { initEngagementComponents } from "@egovernments/digit-ui-module-engagement";
import { DigitUI } from "@egovernments/digit-ui-module-core";
import "@egovernments/digit-ui-css/example/index.css";






var Digit = window.Digit || {};


const enabledModules = [ "Payment","QuickPayLinks", "DSS","Engagement","FSM"];


const initTokens = (stateCode) => {
 const userType = window.sessionStorage.getItem("userType") || process.env.REACT_APP_USER_TYPE || "CITIZEN";


 const token =window.localStorage.getItem("token")|| process.env[`REACT_APP_${userType}_TOKEN`];
 const citizenInfo = window.localStorage.getItem("Citizen.user-info")
 const citizenTenantId = window.localStorage.getItem("Citizen.tenant-id") || stateCode;


 const employeeInfo = window.localStorage.getItem("Employee.user-info");
 const employeeTenantId = window.localStorage.getItem("Employee.tenant-id");


 const userTypeInfo = userType === "CITIZEN" || userType === "QACT" ? "citizen" : "employee";
 window.Digit.SessionStorage.set("user_type", userTypeInfo);
 window.Digit.SessionStorage.set("userType", userTypeInfo);


 if (userType !== "CITIZEN") {
   window.Digit.SessionStorage.set("User", { access_token: token, info: userType !== "CITIZEN" ? JSON.parse(employeeInfo) : citizenInfo });
 } else {
   // if (!window.Digit.SessionStorage.get("User")?.extraRoleInfo) window.Digit.SessionStorage.set("User", { access_token: token, info: citizenInfo });
 }


 window.Digit.SessionStorage.set("Citizen.tenantId", citizenTenantId);
if(employeeTenantId && employeeTenantId.length) window.Digit.SessionStorage.set("Employee.tenantId", employeeTenantId);
};


const initDigitUI = () => {
 window?.Digit.ComponentRegistryService.setupRegistry({


   PaymentModule,
   FSMModule,
   PaymentLinks,
   FSMLinks,
 });




 initDSSComponents();
 initEngagementComponents();
 initFSMComponents();






  const stateCode = window?.globalConfigs?.getConfig("STATE_LEVEL_TENANT_ID") || "pb";
 initTokens(stateCode);


 const registry = window?.Digit.ComponentRegistryService.getRegistry();
 ReactDOM.render(<DigitUI stateCode={stateCode} enabledModules={enabledModules} />, document.getElementById("root"));
};


initLibraries().then(() => {
 initDigitUI();
});

Once the link is added to the homepage, one can see the FSM module on our Digit-UI Homepage. Next, add the homepage card for the citizen module.

import {
 Calender, CardBasedOptions, CaseIcon, ComplaintIcon, DocumentIcon, HomeIcon, Loader, OBPSIcon, PTIcon, StandaloneSearchBar, WhatsNewCard
} from "@egovernments/digit-ui-react-components";
import React from "react";
import { useTranslation } from "react-i18next";
import { useHistory } from "react-router-dom";


const Home = () => {
const { t } = useTranslation();
const history = useHistory();
const tenantId = Digit.ULBService.getCitizenCurrentTenant(true);
const { data: { stateInfo } = {}, isLoading } = Digit.Hooks.useStore.getInitData();


const conditionsToDisableNotificationCountTrigger = () => {
 if (Digit.UserService?.getUser()?.info?.type === "EMPLOYEE") return false;
 if (!Digit.UserService?.getUser()?.access_token) return false;
 return true;
};


const { data: EventsData, isLoading: EventsDataLoading } = Digit.Hooks.useEvents({
 tenantId,
 variant: "whats-new",
 config: {
   enabled: conditionsToDisableNotificationCountTrigger(),
 },
});


if (!tenantId) {
 history.push(`/digit-ui/citizen/select-language`);
}


const allCitizenServicesProps = {
 header: t("DASHBOARD_CITIZEN_SERVICES_LABEL"),
 sideOption: {
   name: t("DASHBOARD_VIEW_ALL_LABEL"),
   onClick: () => history.push("/digit-ui/citizen/all-services"),
 },
 options: [
 
 
   {
     name: t("FSM"),
     Icon: <OBPSIcon />,
     onClick: () => history.push("/digit-ui/citizen/FSM-home"),
   },
 
 ],
 styles: { display: "flex", flexWrap: "wrap", justifyContent: "flex-start", width: "100%" },
};
const allInfoAndUpdatesProps = {
 header: t("CS_COMMON_DASHBOARD_INFO_UPDATES"),
 sideOption: {
   name: t("DASHBOARD_VIEW_ALL_LABEL"),
   onClick: () => {},
 },
 options: [
   {
     name: t("CS_HEADER_MYCITY"),
     Icon: <HomeIcon />,
   },
   {
     name: t("EVENTS_EVENTS_HEADER"),
     Icon: <Calender />,
     onClick: () => history.push("/digit-ui/citizen/engagement/events"),
   },
   {
     name: t("CS_COMMON_DOCUMENTS"),
     Icon: <DocumentIcon />,
     onClick: () => history.push("/digit-ui/citizen/engagement/docs"),
   },
   {
     name: t("CS_COMMON_SURVEYS"),
     Icon: <DocumentIcon />,
     onClick: () => history.push("/digit-ui/citizen/engagement/surveys/list"),
   },
 
 ],
 styles: { display: "flex", flexWrap: "wrap", justifyContent: "flex-start", width: "100%" },
};


return isLoading ? (
 <Loader />
) : (
 <div className="HomePageWrapper">
   <div className="BannerWithSearch">
     <img src={stateInfo?.bannerUrl} />
     <div className="Search">
       <StandaloneSearchBar placeholder={t("CS_COMMON_SEARCH_PLACEHOLDER")} />
     </div>
   </div>


   <div className="ServicesSection">
     <CardBasedOptions {...allCitizenServicesProps} />
     <CardBasedOptions {...allInfoAndUpdatesProps} />
   </div>


   {conditionsToDisableNotificationCountTrigger() ? (
     EventsDataLoading ? (
       <Loader />
     ) : (
       <div className="WhatsNewSection">
         <div className="headSection">
           <h2>{t("DASHBOARD_WHATS_NEW_LABEL")}</h2>
           <p onClick={() => history.push("/digit-ui/citizen/engagement/whats-new")}>{t("DASHBOARD_VIEW_ALL_LABEL")}</p>
         </div>
         <WhatsNewCard {...EventsData?.[0]} />
       </div>
     )
   ) : null}
 </div>
);
};


export default Home;

6. Integration with Backend API:

This section will explain how to integrate the UI part for the citizen module with the backend API.

import Urls from '@egovernments/digit-ui-libraries/src/services/atoms/urls';
import { Request } from '@egovernments/digit-ui-libraries/src/services/atoms/Utils/Request';


export const FSMService = {
 search: (tenantId, filters = {}) =>
   Request({
     url: Urls.fsm.search,
     useCache: false,
     method: "POST",
     auth: true,
     userService: false,
     params: { tenantId, ...filters },
   }),
 create: (details, tenantId) =>
   Request({
     url: Urls.fsm.create,
     data: details,
     useCache: true,
     userService: true,
     method: "POST",
     params: { tenantId },
     auth: true,
   })
};
export default FSMService;

In Request, pass the URL so that the URL is mentioned or added into the service/atoms/url.js

fsm: {
 create: "https://62f0e3e5e2bca93cd23f2ada.mockapi.io/user",
 get:"https://62f0e3e5e2bca93cd23f2ada.mockapi.io/user",
}

Hooks

Once FSMService is created with all requests, create a hook and that hook will be used in the code to pass the data to the backend.

import { useQuery, useMutation } from "react-query";


import FSMService from "../../services/elements/FSM";


export const useFSMCreate = (tenantId, config = {}) => {
 return useMutation((data) => BRService.create(data, tenantId));
};


export default useFSMCreate;

After creating Service and Hooks, register it into packages/ libraries/src/index.js

import Enums from "./enums/index";
import mergeConfig from "./config/mergeConfig";
import { useStore } from "./services/index";
import { initI18n } from "./translations/index";
import { Storage, PersistantStorage } from "./services/atoms/Utils/Storage";
import { UserService } from "./services/elements/User";
import { ULBService } from "./services/molecules/Ulb";
import Hooks from "./hooks";
import { subFormRegistry } from "./subFormRegistry";
import FSMService from "./services/elements/FSM";


const setupLibraries = (Library, props) => {
 window.Digit = window.Digit || {};
 window.Digit[Library] = window.Digit[Library] || {};
 window.Digit[Library] = { ...window.Digit[Library], ...props };
};


const initLibraries = () => {
 setupLibraries("SessionStorage", Storage);
 setupLibraries("PersistantStorage", PersistantStorage);
 setupLibraries("UserService", UserService);
 setupLibraries("ULBService", ULBService);


 setupLibraries("Config", { mergeConfig });
 setupLibraries("Services", { useStore });


 setupLibraries("FSMService", FSMService);


 return new Promise((resolve) => {
   initI18n(resolve);
 });
};


export { initLibraries, Enums, Hooks, subFormRegistry };

Once the backend is set up, the hooks or service will be used to send the data to the backend after submitting the form. Add the onSubmit function in this file: (fsm/src/pages/citizen/create/index.js) and in that function, pass the user’s entered data to the BRService that has been created.

import { FormComposer, Loader } from "@egovernments/digit-ui-react-components";
import React, {  useState } from "react";
import { useTranslation } from "react-i18next";
import { useHistory } from "react-router-dom";
import { newConfig } from "../../../components/config/config";


const Create = () => {
 const tenantId = Digit.ULBService.getCurrentTenantId();
 const { t } = useTranslation();
 const history = useHistory();


 const onSubmit = (data) => {


   let Users = [
     {


       user: {
         firstName: data?.FSMSelectName?.firstName,
         lastName: data?.FSMSelectName?.lastName,
         tenantId: tenantId,
       },
      
     },
   ];
     /* use customiseCreateFormData hook to make some chnages to the Employee object */
    Digit.FSMService.create(Users, tenantId).then((result,err)=>{
      let getdata = {...data , get: result }
      onSelect("", getdata, "", true);
      console.log("daaaa",getdata);
    })
    .catch((e) => {
    console.log("err");
   });


   history.push("/digit-ui/citizen/fsm/response");


   console.log("getting data",Users)
  
 };
  /* use newConfig instead of commonFields for local development in case needed */


 const configs = newConfig?newConfig:newConfig;


 return (
   <FormComposer
   heading={t("FSM Registration")}
   label={t("ES_COMMON_APPLICATION_SUBMIT")}
   config={configs.map((config) => {
     return {
       ...config,
       body: config.body.filter((a) => !a.hideInEmployee),
     };
   })}
   onSubmit={onSubmit}
   fieldStyle={{ marginRight: 0 }}
 />
 );
};


export default Create;

Once the integration is done, the data will be saved into the database.

Local Development Setup

The following tools have to be installed before development. Make sure to install the specific versions provided below. If no version is provided, it is assumed that the latest version can be installed.

Install Visual Studio Code. VS Code Extensions to be installed from the marketplace:

​​​​Install NodeJS 14.20.0

​version 1.22.19

Clone the DIGIT-OSS repository locally from your organization's umbrella. This contains the frontend code under the frontend folder.

Build & Deploy

Go to the Jenkins build page. Click on SANITATION under the folder path mentioned below. frontend/sanitation-ui

Click on Build with parameter. Select the feature branch name by searching for it in the search box on the right side of the screen. Click on Build.

Once the build is successful, open the console output and find the docker image that has been built. Copy the docker image ID.

Deploy

Copy the docker image IDs from the previous step and paste in the above box. Click on ‘Build’. Once the image is deployed, you will see a message as shown below:

Run the Application

After the application is built and deployed, run and test it in the local environment.

Configure Environment File - Citizen To run the application in the local environment, add the .env file in the example folder - If the user is a citizen, configure the .env file as shown below:

SKIP_PREFLIGHT_CHECK=true

REACT_APP_USER_TYPE=CITIZEN

REACT_APP_EMPLOYEE_TOKEN=c835932f-2ad4-4d05-83d6-49e0b8c59f8a

REACT_APP_CITIZEN_TOKEN=7cd58aae-30b3-41ed-a1b3-3417107a993c

REACT_APP_PROXY_API=https://dev.companyname.org

REACT_APP_PROXY_ASSETS=https://dev.companyname.org

REACT_APP_GLOBAL=https://path/to/public/s3/bucket/globalConfigs.js

REACT_APP_CENTRAL_GLOBAL=https://path/to/public/s3/bucket/statebglobalConfigs.js

REACT_APP_QA_GLOBAL=https://path/to/public/s3/bucket/egov-dev-assets/globalConfigs.js

REACT_APP_UAT_GLOBAL=https://path/to/public/s3/bucket/egov-uat-assets/globalConfigs.js

REACT_APP_STATEB_GLOBAL=https://path/to/public/s3/bucket/statebglobalConfigs.js

staging=https://staging.companyname.org

Configure Environment File - Employee

SKIP_PREFLIGHT_CHECK=true

REACT_APP_USER_TYPE=EMPLOYEE

REACT_APP_EMPLOYEE_TOKEN=c835932f-2ad4-4d05-83d6-49e0b8c59f8a

REACT_APP_CITIZEN_TOKEN=7cd58aae-30b3-41ed-a1b3-3417107a993c

REACT_APP_PROXY_API=https://dev.companyname.org

REACT_APP_PROXY_ASSETS=https://dev.companyname.org

REACT_APP_GLOBAL=https://path/to/public/s3/bucket/globalConfigs.js

REACT_APP_CENTRAL_GLOBAL=https://path/to/public/s3/bucket/statebglobalConfigs.js

REACT_APP_QA_GLOBAL=https://path/to/public/s3/bucket/egov-dev-assets/globalConfigs.js

REACT_APP_UAT_GLOBAL=https://path/to/public/s3/bucket/egov-uat-assets/globalConfigs.js

REACT_APP_STATEB_GLOBAL=https://path/to/public/s3/bucket/statebglobalConfigs.js

Open Terminal in micro-UI-internals and run the following command:

yarn start

The application will start after you run the command.

Login

There are two types of login:

• Employee:

Homepage Employee: After the login is successful for employees, users are redirected to the employee home page.

On the homepage, users can see the cards for FSM. These cards need to be added. Go through the link to create an employee card. Homepage Citizen: After the login is successful for citizens, users are redirected to the citizen homepage.

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

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

The user interface (UI) design is broken up into the following sections:

1. Login

2. Raise a Desludging Request

3. View Applications

4. Accept Applications

5. Payments

6. Assign Desludging Operator

7. Assign Vehicle

8. Complete Request

9. Rate Services

10. Manage Vendor, Driver and Vehicle Details

1. Login

Citizen Login

Find the mock-ups below:

Language Selection

When the user opens the application, it first asks them to select the language. The selected language is highlighted in orange color. Once the user selects a language, he/she must click on the ‘Continue’ button which opens the login page.

Location Selection

Users are redirected to this screen once they select the preferred language in the previous screen. The city field will be a list with radio buttons based on the tenants that are configured in the instance, and the selected radio button is highlighted in orange. The selection of the city will determine the urban local body (ULB) where the application request is raised.

Once the user selects a location and clicks on continue, the user is redirected to the following screen:

The mobile number entered in the application is for all communication purposes. All SMS communication will be sent to the user on the entered number. A user can also access the history of all past and active transactions using this number. The next button will only be deactivated and will be highlighted once the user has entered a valid number. An error message will be displayed if the number is not 10 digits, or alphabets/special characters are entered.

On clicking ‘Next’, an OTP will be sent to the user, and the user will be redirected to the following screen:

The screen will prompt the user to enter the OTP sent to the registered mobile number. A counter will be displayed on the screen with a countdown on the number of seconds pending post which the OTP has be re-quested. After 30 seconds, a resend button will be visible to the user. The next button will only be deactivated and will be highlighted once the user has entered an OTP. On clicking ‘Next’, the user will be redirected to the FSM landing page. On entering the incorrect OTP, the user will see an error message that says “Invalid OTP”.

Employee Login

Language Selection

When the user opens the application, it asks them to first select the language. The selected language is highlighted in orange color. Once the user selects a language, he/she must click on the ‘Continue’ button which opens the login page.

Login

The user will be provided with a unique system-generated ID and password manually for login.

For an incorrect password, it should show the message “incorrect password” below the password field. If an existing user does not remember his/her password, they must click on “Forgot Password”. This will open a pop-up asking the user to contact the administrator. The ‘OK’ button will collapse the pop-up.

The city field is a dropdown based on the tenets created in the instance. Once all fields are filled, the user can click on ‘Continue’. If any field is not filled, the user will be prompted to fill all fields.

2. Raise a Desludging Request

Citizen Interface

A landing page is available to a citizen on login.

Applying for a Desludging Request

The citizen can apply for desludging requests by clicking on “Apply for Emptying Septic Tank/Pit”. This will redirect the user to the service request page.

The user is prompted to enter the “No. of Trips” and the “Vehicle Capacity”. If the user knows the details, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.

Once the user clicks on ‘Next’, the user is redirected to “Choose Property Type”. A workflow on the top will show the user in which step of the request form he/she is. The radio button for the selected property type will be highlighted with orange. The next button will only be deactivated and will be highlighted once the user has selected a property type.

Based on the property type selected, an information box is displayed to the user informing them about the approximate cost of desludging. On clicking next, the user is prompted to “Choose Property Sub-Type”:

The radio button for the selected property type will be highlighted in orange. The next button will only be deactivated and will be highlighted once the user has selected a property type.

The user is prompted to select the pincode for the property location using the map or search a location using the search bar. The user can also drag the point on the map to the selected location. If the user knows the pin location, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”. If the pin location is not selected, the user is redirected to enter the pincode.

The user can enter a 7-digit pincode. If any alphabets/special characters are entered, the user will be prompted with an invalid pincode error. If the user knows the pincode, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.

After this, the user will be redirected to the property address page and he/she will have to select a city and a mohalla. Both of these are dropdowns. The city dropdown is populated based on the tenants created in the system. The list of localities/mohallas will be from the MDMS. The next button will be deactivated and will be highlighted once the user has filled in the details. Once a property address is provided, the user is asked to select whether the property is a slum.

The radio button for the selected option will be highlighted in orange. The next button will only be deactivated and will be highlighted once the user has selected an option. If yes is selected, the user will be redirected to enter the slum name.

The slum name can be selected from a dropdown. The next button will only be deactivated and will be highlighted once the user has selected a slum name. On clicking ‘Next’, the user is redirected to the property address screen.

After this, the user will be redirected to the property address page where he/she will have to enter the “Street Name” and “Door/House No”. The ‘Next’ button will be deactivated and will be highlighted once the user has filled in the details. Once a property address is provided, the user is asked to provide a landmark.

The landmark can be entered by typing in the text box. If the user knows the landmark, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.

The user will be prompted to “Choose Pit type”. The radio button for the selected option will be highlighted in orange. If the user knows the pit type, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.

The user will be prompted to “Upload Pit Photos” by clicking on the camera icon. Once the button is clicked on, the user can choose the camera or select a photo from the gallery. If the user has the photo, he/she can upload the photo and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.

The user will be asked to select gender. The radio button for the selected option will be highlighted in orange. If the user wants to declare their gender, the user can select from Male/Female/Transgender/Others, and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.

The user is redirected to the “Payment Details” page. If an advance has been configured in the backend by the ULB, the advance amount is displayed on the screen. The user can enter the advance amount. If an amount below the advance amount is entered, then an error is displayed. To confirm, the user can click on ‘Next’. The user is then prompted to “Check the Answers”.

A change option is displayed beside each answer. In case the user wants to edit any details, the user can click on the change button and the user will be redirected to that part of the workflow. If not, the user can click on ‘Submit’.

The user is displayed a confirmation message for application submission along with an application number. A download button can be used to download the application receipt as displayed below. The user can also go back home by clicking on the “Go back to home page” button.

Employee Interface

A landing page is available to the ULB employee on login.

Applying for a Desludging Request

The employee can apply for desludging requests on behalf of the citizen by clicking on “New Desludging Request”. This will redirect the user to a form.

The user is prompted to enter the mandatory and non mandatory fields. The “Amount per Trip”, “Total Amount” and “Advance Collection” fields are empty, and will be autopopulated once the “Property Type, “Property Sub-type”, “No. of Trips” and “Vehicle Capacity” are filled.

The following validations will be present in the page:

1. Mobile number to be 10 digits and cannot be alphanumeric or contain special characters.

2. Advance amount edited cannot be greater than total amount or lesser than minimum amount.

The submit button is greyed out and will only show as active when all mandatory fields are filled.

Once the user submits the form, the user is redirected to a confirmation page. The confirmation page will display a unique application number. A download option to download the application receipts displayed below is also available. The user can go back to the landing page using the “Go Back to Home” button.

3. View Applications

Citizen Interface

A citizen can view his/her applications by redirecting to “My Applications” from their landing page.

The “My Applications” page lists down all the ongoing applications and will display the Application No., Service Category and Application Status. A view button will be made available along with each application. Once the user clicks on ‘View’, they are redirected to the following page:

The user can view all details of the application on the screen. There is an option to download the application receipt and payment receipts using the Download button.

The application timeline below the application shows the history of the application along with details of the date when the workflow step was completed. If the application is in the “Pending for Payment”, the same will be displayed and a corresponding link will be displayed in the “Application Timeline”.

Similarly, if the application is in the “Pending Citizen Feedback” stage, the same will be displayed and a corresponding link will be displayed in the “Application Timeline”.

Employee Interface

To view the applications, an employee can navigate to the inbox from the Landing page. The inbox shows a list of all active applications along with their SLAs.

The user can search for an active application using “Application No.” and “Mobile No.” and click on search. This will return the application with the corresponding “Application Number” or the list of applications with the corresponding mobile number. The user can further filter applications based on the criteria on the left hand side, that is, Locality or Status.

To view Past Applications, the user can navigate to Search Applications. Here, users can search for both Active and past applications with the following fields: Application Number, Mobile Number, Status and Locality. On clicking on an application number, the user is redirected to the Application details page.

The user can view all details of the application on the screen. The application timeline below the application shows the history of the application along with details of the date when the workflow step was completed.

4. Accept Applications

The ULB employee can accept and update application details when a citizen has raised a request or rejected it.

This can be done by clicking on the “Update Application” button. Details such as locality, number of trips and capacity will be displayed. Clicking on “Update application” will update the status of the application as “Pending for Payment”.

Clicking on “Reject Application’ will reject the application and the user will be prompted to select a reason for rejection and click on submit. Once the application is updated, it will move to pending for payment status if advance payment is applicable.

5. Payments

Citizen Interface

If the application is on the “Payment Pending” stage, the user will have the option to make a payment from the “View Applications” page.

The user can make a payment by clicking on the “Make Payment” button. The user is redirected to the bill details page which displays the total, advance and due amount.

Here, the amount due is prefilled and displayed to the user. If the user is aligned, they can proceed by clicking on “Proceed to Pay”.

All payment methods available and configured will be available here as radio buttons. The selected radio button will be filled in orange to display the selection. The user also receives an intimation that they will be redirected to a third-party site. On completion of the payment, the user is redirected to a payment confirmation page. A ‘Print’ receipt option is available to download the payment receipt.

Employee Interface

Desludging applications pending for payment are accessible in the inbox of the user assigned the collector role. The status of the application is reflected in the status column.

By clicking on the application number, the user can view application details.

The user will be able to view details of the application along with details of the Amount Per Trip, Total Amount and amount to be collected. The application details will also display the status as “Pending for Payment”. The user can proceed to collect payment by clicking on the “Collect Payment” button and the user will be redirected to the “Collect Payment” page.

The user will see information about the amount to be collected and further will be required to fill the following information:

1. Payer Name

2. Payer Phone number

Additionally, the user will be prompted to select the payment mode using radio buttons. The selected radio button will be highlighted with orange. If the user is getting a physical receipt, then the receipt number can be recorded under the Gen/G8 receipt details.

On clicking the submit button, the user is redirected to the payment confirmation screen. The user can download the payment receipt using the ‘Print’ receipt button or go back to the landing page using the “Take Action” button.

6. Assign Desludging Operator

Once the payment (if any) is collected, the ULB employee can assign a desludging operator. Applications where DSO needs to be assigned will be shown as “Pending for DSO Assignment” in the inbox.

By clicking on the application number, the user can view application details.

The user can start the process of assigning a DSO by clicking on the “Assign DSO” button. This will display the following pop-up to the user:

The user can select the DSO via a dropdown. The list of DSOs is populated by matching the vehicle capacity requested to the DSOs with vehicles with the required capacity. An expected date of completion is to be selected. Once all fields are filled, the user can assign the selected DSO. An error message will be displayed if a field is left blank. The user can also go back to the application details page by clicking on the ‘Close’ button.

Once the user clicks on ‘Assign’, the status in the workflow timeline will reflect “Pending for DSO Approval”. For any reason, if the DSO is unavailable to service the request, the request can be reassigned to another DSO. This can be done by clicking on the “Take Action” button and clicking on reassign DSO.

The same fields need to be filled as that for “Assign DSO”. However, the user is required to select a reason for rejection from a list preconfigured in the backend. An error message will be displayed if a field is left blank. On re-assigning a DSO, the user is displayed a snack bar with confirmation.

The user can also go back to the application details page by clicking on the ‘Close’ button.

7. Assign Vehicle

A vehicle can be assigned by both the ULB and the DSO (or basis roles configured) when the application is in the “Pending for DSO Approval” stage. By clicking on the application number, the user can view application details.

The user can start the process of assigning a vehicle by clicking on the “Assign Vehicle” button. This will display the following pop up to the user.

The user can select the “Vehicle no.” via a dropdown. The list of vehicles is populated by matching the vehicle capacity requested with the required capacity. The vehicle capacity and number of trips are displayed on the pop up. An error message will be displayed if the vehicle registration number field is left blank. The user can also go back to the application details page by clicking on the ‘Close’ button.

Once the user clicks on ‘Assign”, the status in the Workflow timeline will reflect the “DSO InProgress” stage.

At any point during service, the DSO or ULB can update the number of trips. This can be done by clicking on the “Take Action” button and selecting the “Update/Schedule Trips” option.

The user can increase or decrease the number of trips by clicking on the plus or minus sign. The number of trips will increase or decrease and be displayed based on the user action. The user can confirm the updated number of trips by clicking on the Update/Schedule button. The user can also go back to the application details page by clicking on the ‘Close’ button.

A snack bar will confirm the updated number of trips.

8. Complete Request

Once the service request has been completed and all pending payment has 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:

The user is required to fill the following details:

1. Date of Service (selected from a calendar)

2. Volume of Waste collected

Additionally, the user can add optional details such as Pit Type and Pit Dimensions and upload a photo of the Pit. An error message will be displayed if all mandatory fields are not filled.

The user can confirm the completion by clicking on the ‘Completed’ button. The user can also go back to the application details page by clicking on the ‘Close’ button.

9. Rate Services

if the application is on the Payment Pending stage, the user will have the option to make a payment from the “View Applications” page.

On clicking on ‘View’, the user is redirected to the application details page. The workflow timeline will reflect that the application is pending for citizen feedback and a clickable “Rate Us” option is displayed to the user.

Once the user clicks on rate us, the user will be redirected to the following page:

The user can provide feedback by selecting one out of 5 stars and selecting safety gears used via a multi-select box. If either of these fields are not filled, the user is displayed an error when clicking on the submit button. Additional comments may be added by the user.

On clicking the submit button, the user will be redirected to a confirmation page. The user can use the ‘Download’ button to download any payment or acknowledgement receipts from the users.

Manage Vendor, Driver and Vehicle Details

The FSM Registry allows for the following actions from the frontend for a particular urban local body (ULB):

• Add new driver, vehicle, vendor

• Edit driver, vehicle, vendor details

• Enable and disable drivers, vehicles and vendors

• Tag driver and vehicle to vendors.

The user can access the ULB registry by clicking on the FSM Registry link in the landing page.

View Vendor List

The landing page of the FSM registry is defaulted to show the list of vendors in the system. A particular vendor can be searched for by entering the Vendor name in the search bar. Search can be cleared by clicking on the “Clear Search” button.

The user can view the number of associated total and active vehicles and drivers against a vendor. The user can view the details of the tagged vehicles and drivers by clicking on the number. The user can enable/disable the vendor using the toggle.

Add a Vendor

A new vendor, vehicle or driver can be added by clicking on the plus button on the top right of the page.

On clicking the plus button, the user will be prompted to select whether he/she/it/they/them want to add a Vendor, Driver or Vehicle. To add a new Vendor, the user can click on Vendor and the user will be redirected to the “Add Vendor” page.

A new vendor can be added by entering details such as Vendor Name, personal details, including Gender, Date of Birth, Email and Phone number and Address details such as Door No, Pincode and landmark. Each vendor is created with a unique mobile number and hence, an error message will be displayed if the mobile number has been used to create other vendors. An error message will be displayed if all mandatory fields are not filled.

The user can confirm the completion by clicking on the ‘Submit’ button. The user can also go back to the FSM Registry landing page by using the breadcrumbs.

Once the user submits an application, a snack bar will confirm the successful addition of a vendor and details of the added vendor will be displayed in the vendor list.

View and Edit Vendor Details

Vendor details can be viewed by clicking on the vendor name. This will display details such as name, number and address. Details of vehicles and drivers tagged to the vendor will be visible on the screen. The user can go back to the FSM Registry landing page by using the breadcrumbs.

Vendor details can be edited by clicking on the “Take Action" button and selecting edit. Add or edit information and click on “Submit Application”. The changes will reflect on the vendor details page.

A vendor can be deleted by clicking on the “Take Action” button and selecting delete.

A pop-up will be displayed for confirmation. The user can confirm delete by clicking on ‘Delete’ or go back to the vendor details by clicking on ‘Cancel’.

On clicking delete, the user will be redirected to the FSM registry landing page and a snack bar will be displayed confirming that the vendor has been deleted.

Tagging Vehicles and Drivers to a Vendor

Multiple vehicles can be tagged to a vendor. It is necessary that a vehicle exists in the system before it can be tagged. A vehicle can be tagged to a vendor by clicking on the “Add Vehicle” button in the vendor details page.

A pop-up will be displayed with a dropdown to select a vehicle. Only vehicles that are not tagged to any vendor are to be displayed. The user can select the vehicle number and click on submit or go back to the vendor details page by clicking on close.

The added vehicle details will be displayed. The vehicle can be untagged from the vendor by clicking on the delete button against the vehicle details.

Multiple drivers can be tagged to a vendor. It is necessary that a driver exists in the system before it can be tagged. A driver can be tagged to a vendor by clicking on the “Add Driver” button in the vendor details page.

A pop-up will be displayed with a dropdown to select a driver. Only drivers that are not tagged to any vendor will be displayed. The user can select the driver name and click on submit or go back to the vendor details page by clicking on close.

The added driver details will be displayed. The driver can be untagged from the vendor by clicking on the delete button against the driver details.

View Vehicle List

To view the list of Vehicles, the user can navigate to the Vehicle tab from the FSM Registry landing page.

The user can view the creation date, tagged vendor and status for a vehicle in this page. A particular vehicle can be searched for by entering the vehicle number in the search bar. Search can be cleared by clicking on “Clear Search”. Vehicles can be sorted by creation date, by clicking on the arrow beside the column heading. The user can enable/disable the vehicle using the toggle.

Add a Vehicle

To add a new vehicle, the user can click on vehicle near the plus button and the user will be redirected to the “Add Vehicle” page.

A new vehicle can be added by entering details such as Vehicle Registration number, Model, Type, Capacity, details of pollution certificate, insurance and road tax. Each vehicle is created with a unique registration number and hence, an error message will be displayed if the registration number has been used to create other vehicles. An error message will be displayed if all mandatory fields are not filled.

The user can confirm the completion by clicking on the ‘Submit’ Button. The user can also go back to the FSM Registry landing page by using the breadcrumbs. Once the user submits an application, a snack bar will confirm the successful addition of a vehicle.

Details of the added vehicle will be displayed in the vehicle list.

View and Edit Vehicle Details

Vehicle details can be viewed by clicking on the vehicle name. This will display details such as the registration number, vehicle type, make, model, capacity etc. The vendor that the vehicle is tagged to and whether it is active is also displayed in the details.

Vehicle details can be edited by clicking on the “Take Action” button and selecting edit. Add or edit information and click on submit application. The changes will reflect in the vehicle details page.

A vehicle can be deleted by clicking on the “Take Action” button and selecting delete.

A pop-up will be displayed for confirmation. The user can click on delete to confirm to cancel to go back to vehicle details. The vehicle will be deleted.

Tagging a Vehicle to a Vendor

Apart from tagging a vehicle to a vendor from the vendor details page, tagging can also be done from the vehicle details page by clicking on the add vendor button. The tagging can be edited by clicking on the edit icon beside Vendor name, in case a vendor is already added.

A pop-up will be displayed with a dropdown to select a vendor. The user can select the vendor and click on submit or go back to the vehicle details page by clicking on ‘Cancel’.

The added vendor details will be displayed. The vehicle can be untagged from the vendor by clicking on the delete button against the vendor name. The edit (pencil) button allows you to change the vendor tagging.

View Driver List

To view the list of drivers, the user can navigate to the drivers tab.

The user can view the creation date, tagged vendor, and status for a driver in this page. A particular driver can be searched for by entering the driver name in the search bar. Search can be cleared by clicking on “Clear Search”.

Drivers can be sorted by creation date, by clicking on the arrow beside the column heading. The user can enable/disable the vehicle using the toggle. The user can change the tagging of the Vendor by using the drop down in the “Vendor Name” column.

Add a Driver

To add a new driver, the user can click on Driver from the plus button and the user will be redirected to the “Add Driver” page.

A new driver can be added by entering details such as Driver Name, and License number. Each vehicle is created with a unique license number and hence, an error message will be displayed if the license number has been used to create other vehicles. An error message will be displayed if all mandatory fields are not filled.

The user can confirm the completion by clicking on the ‘Submit’ button. The user can also go back to the FSM Registry landing page by using the breadcrumbs. Once the user submits an application, a snack bar will confirm the successful addition of a driver. Details of the added driver will be displayed in the driver list.

View and Edit Driver Details

Driver details can be viewed by clicking on the driver name. This will display details such as the Name, phone number and license number. The vendor that the driver is tagged to is also displayed in the details.

Driver details can be edited by clicking on the “Take Action” button and selecting edit. The user can add or edit information and click on submit application. The changes will reflect in the driver details page.

A driver can be deleted by clicking on the “Take Action” button and selecting delete.

A pop-up will be displayed for confirmation. The user can click on delete to confirm or view driver details by clicking on cancel. The vehicle will be deleted.

Tagging a Driver to a Vendor

Method 1: Apart from tagging a driver to a vendor from the vendor details page, tagging can also be done from the driver details page by clicking on the add new vendor button.

A pop-up will be displayed with a dropdown to select a vendor. The user can select the vendor and click on submit or go back to the driver details page by clicking on ‘Cancel’.

The added vendor details will be displayed. The vehicle can be untagged from the vendor by clicking on the delete button against the vendor name. The edit (pencil) button allows you to change the vendor tagging.

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.

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.

Actor Interaction Mapping

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

Overview

The vendor registry is a system that enables urban local body (ULB) employees to create and search a vendor, that is, the desludging operator (DSO) and driver entities with appropriate vehicle entities for the FSM application. This document contains the details about how to set up the vendor and describe the functionalities provided.

Pre-requisites

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

• Java 8

• Kafka server is up and running.

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

• PSQL server is running and database is created to store FSM application data.

• Following services should be up and running:

- egov-mdms-service

- egov-user-service

- boundary-service

- vehicle-service

Key Functionalities

EXISTING

1. Added payment payment preference and agency attributes for DSO.

2. Added gender attribute in the create and update APIs for vendor.

3. Updated the vendor search API to add vehicleCapacity in the search parameter to search all vendors matching the vehicle capacity specified in the search parameter.

4. Introduced the vendor tab.

5. Option to add/remove/update vendors individually.

6. User can add vehicle and driver.

7. Search for the list of all vehicles not associated with any vendors.

8. Users can enable or disable the vendor.

9. Introduced the driver tab.

10. Option to add/remove/update driver individually.

11. User should be able to create/update/enable/disable a driver from the driver screen.

12. Functionality to add/remove directly driver to vendor.

ENHANCEMENT

Part Search :

FSM Registry Vendor Tab

The vendor tab now supports part search by vendor name. This means that users can enter a partial vendor name and retrieve all relevant results that contain that specific portion.

For instance, if the vendor name is "Shambala corporation", users can search for any part of the vendor name, such as "sham" or "Shambala", and retrieve all relevant results which contain that specific portion.

FSM Registry Driver Tab

The driver tab now supports part search by driver name. This means that users can enter a partial driver name and retrieve all relevant results which contain that specific portion.

For instance, if the driver name is "Rajesh Ranjan", users can search for any part of the driver name, such as "raj" or "ranjan", and retrieve all relevant results which contain that specific portion.

Updating Registry Information

In the vendor tab, the admin has the ability to update certain vendor information, such as Gender, Mobile number, and Locality/Mohalla.

In the driver tab, the admin has the ability to update certain driver information, such as Gender, Driver, and License Number.

Deployment Details

1. Deploy the latest version of the vendor.

2. Add vendor-persister.yml file in the config folder in git and add that path in persister (the file path is to be added in the environment yaml file in param called persist-yml-path), and restart egov-persister-service.

Configuration Details

MDMS Configuration

Business Service / Workflow Configuration

NA

Actions & Role Action Mapping

After adding actions and role action mappings, restart the egov-mdms-service

Actions

Role Action Mapping

Infra Ops Configuration

Configurations that we can manage through values.yml vehicle in infra-ops repo are listed below. values.yml for the vehicle is available below.

Configurations sample in Values.yml

Data Setup

The DSO for the FSM system is a vendor. For every city/ULB, a DSO should be created with the representative details as owner, associated vehicles and drivers.

Sample Curl

Integration

Integration Scope

Any system or DIGIT module can be integrated with the vendor service. It helps to manage the vendor with the vehicles, drivers, and owner for representatives, and login for the representative/owner to login into the system to carry our role-specific operations.

Integration Benefits

• Validation of DSO/vendor availability.

• Fetch the vehicle assigned to the DSO.

• Fetch the drivers assigned to the DSO.

Steps to Integration

• FSM to call vendor/v1/_search to fetch the DSOs.

• FSM can call vendor/v1/_search to fetch the DSO’s and the respective vehicles and drivers.

Interaction Diagrams

Reference Docs

Doc Links

API List

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.