FSM Service
Learn how to setup and configure FSM service
Overview
Faecal sludge management (FSM) is a system that enables citizens to raise a request for septic tank cleaning with their urban local bodies (ULBs) directly or by reaching out to the ULB counter. Citizens can track the application, make a payment for the charges, and rate the service. This document contains details on how to set up FSM, and describes the functionalities it provides. It contains the details about the feature enhancements being released as part of FSM v1.3.
As part of the FSM v1.4, a new worker registry concept is being introduced. The creation of a worker, updation of details, searching and tagging a worker for different operations on sanitation programmes will be covered. While assigning vehicle for the application, we have the functionalities which will provide the ability to assign multiple sanitation workers for the application.
Plant User Mapping
The fsm service enables mapping plant codes to FSTP employee, ensuring that each is only authorised to manage to their account, enhancing control and accountability. In the mapping process need to check below mention things
PlantCode
: Unique plant code which is configured in the mdmsemployeeUuid
: Unique user id of the employee which have the type of fsm-fstp.
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 fsm-persister config path added in it
PSQL server is running and a database is created to store FSM Application data
(Optional) Indexer config for FSM is added in egov-indexer yaml paths to index the generated data. An index is required for data visualisation in kibana or in DSS.
Following services should be up and running:
egov-user
egov-workflow-v2
egov-perister
egov-localisation
egov-notification-sms
egov-mdms
egov-idgen
egov-url-shortening
vehicle
vendor
fsm-calculator
billing-service
collection-services
individual-services
Key Functionalities
Citizens can file, track, and rate the application for cleaning the septic tank.
A ULB employee can file application for cleaning the septic tank on behalf of a citizen.
A ULB employee can assign a DSO to the given application with a possible service date.
A DSO can accept or reject the application.
A DSO or a ULB employee can complete the FSM application after cleaning the septic tank.
The FSM admin in a ULB can cancel the application at any stage before completing the application.
A ULB employee or an admin can view the audit log of the given application.
Capture citizen gender information if not present or pre-populate the gender information when a citizen is creating the FSM application.
Add citizen's choice for payment.
Introducing pre-pay and post-pay service.
Post-pay service: Workflow changes (Desludging application and vehicle trip).
Post-pay service: Employee flow enhancements.
Add payment selection for DSO.
Post-pay service: Number of trips is editable, and price calculation will be now based on the number of trips entered by the DSO.
Capture DSO and FSTPO gender.
Show citizen gender on FSM DSS.
Select vehicle capacity instead of vehicle make.
Citizen Notifications | Payment Options | Timeline Enhancements.
FSTPO vehicle log inbox enhancements.
FSTPO can decline the vehicle trip.
Add owner attribute for vehicles.
Add ULB contact details in the FSM application flow.
DSO can edit pit and property usage details.
Show vehicle trip status in employee inbox along with the desludging application.
Unrestricted assignment of service requests to a single vehicle.
Vehicle logging at FSTP decoupled from the FSM module.
Photo and attachment view in the application of the ULB employee UI.
Dashboard enhancement.
Advance pay service: Employee flow enhancements.
Introduced two new workflows in the system:
- FSM_ADVANCE_PAY_SERVICE and FSM_ZERO_PAY_SERVICE .
Advance pay service: The number of trips is made editable (increase or decrease based on the requirement), and price calculation will be now based on number of trips entered by the DSO or ULB.
Allowed to pay part payment while creating the application.
ULB and DSO are allowed to decrease the number of trips if not required and if full payment is not done.
ULB and DSO are allowed to increase or decrease the number of trips n number of times.
With the updated number of trips, an updated bill will be generated.
Delink the payment from DSO in progress state.
Zero pay service: Employee flow enhancements.
Zero pay service: System now skips the collection, and will not generate the demand for zero price application.
Demand generation process: Generating demand every time the trip is updated.
Demand generation process: Added validation not to complete the application from ULB side before completing all payment.
Enhancement of FSM receipt.
Enhancement of assigning sanitation-worker to fsm application
Enhancement of assigning driver to fsm application
Feature Enhancement
As part of the FSM v1.4, Creation of fstp plant user mapping configuration we moved PlantInfo from mdms v1 to mdms v2 . For the changes follow below steps.
For a new environment these changes are required.
path:- deploy-as-code/helm/charts/sanitation/fsm/values.yaml - link
Create plantInfo in PQM.Plant schema .
Use the existing collection to create,update and search
Kafka Topic Details
Users
User with userType employee and role FSM_CREATOR_EMP role.
Integration
Idgen changes - Link
Integration Scope
FSM can be integrated with any ULB or system which wants to track the FSM application. The organisations can customise the workflow depending on their product requirements.
Integration Benefits
Easy tracking and resolution of the FSM application.
Configurable workflow according to client requirement.
Steps
Citizen/ULB employee can file application request using the /fsm/v1/_create.
An organisation or system can search the FSM Applications using /fsm/v1/_searchendpoint.
Once the application is filed, the organisation or system can call /fsm/v1/_update endpoint to move the application further in the workflow until it gets resolved.
Inbox API
Introduced new inbox service to get the FSM applications in registered ULB employee inbox. With this, a ULB employee can track the application or perform the actions based on employee role.
ULB employees can also apply the filter to check the particular state or applications or any other filter as required.
Changes for FSMv1.4
Inbox V2 API
Inbox v2 provide same feature what ever have in inbox v1 .
Introduced new inbox service to get the FSM applications in registered ULB employee inbox. With this, a ULB employee can track the application or perform the actions based on employee role.
ULB employees can also apply the filter to check the particular state or applications or any other filter as required.
Integration
Add the mdms changes in the given path and restart the mdms service .
Path: data/pg/inbox-v2/InboxConfiguration.json
Add the indexer file in the given path and restart the services.
Path: sanitation/egov-indexer/fsm-inbox-indexer.yml
File: file which need to add click here
FSM Apply As A Service
Currently, we provide FSM as an adhoc service.To avoid multiple times, a user has to create the FSM request every time. In the system itself after some days, we will create the same FSM application and if the user wants a service, he/she will pay the amount.
MDMS Changes
As mentioned above, we need to define the time parameter in order to create a periodic application. For that, we added the periodic service master where we configure the time limit and whether the schedular is enabled or not. Find the configuration and location below
cronjob will read the cron job’s configured in the cronjobapiconfig.json, and based on the schedular time, it will call the API which is configured. Find the configuration and file location below:
We are using the fsm/v1/_schedular API. This API will read the master data for each tenant and based on the time limit configured for that tenant, it will get all eligible applications and create periodic applications for those FSM applications.
data/pb/FSM/AdvancePayment.json
SM-499 : mdms file for advanceBalance and cancellationfee · egovernments/egov-mdms-data@3b3233e
Update AdvancePayment.json · egovernments/egov-mdms-data@a864a90
Update CancellationFee.json · egovernments/egov-mdms-data@3a614e5
master-config.json
SM-499 adding advancepayment and cancellationfee · egovernments/egov-mdms-data@c4efb2e
Infra changes
We added a new chart called mdms-read-cronjob. Find the chart location below:
Interaction Diagram
1. Advance Amount Workflow
2. Zero Price Application Workflow
Sequence Diagram
Reference Docs
Doc Links
API List
test
Last updated