FSM v1.1.0

Overview

Faecal sludge management (FSM) is a system that enables citizen to raise a request for septic tank cleaning with there ULB’s directly or reaching out to ULB counter. Citizen can track the application, make a payment for the charges and rate the service. This document contains the details about how to setup the fsm and describes the functionalities it provides.

This document contains the details about the features enhancements being released as part of FSM v1.1 release.  For core fsm functionalities and how to setup the fsm please refer FSM v1.0 documentation.

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 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. Index are required for data visualisation in kibana or in DSS.

• Following services should be up and running:

  • egov-user

  • egov-workflow-v2

  • egov-perister

  • egov-localization

  • egov-notification-sms

  • egov-mdms

  • egov-idgen

  • egov-url-shortening

  • vehicle

  • vendor

  • fsm-calculator

  • billing-service

  • collection-services

Key Functionalities

• Citizen can file, track and rate the application for cleaning septic tank

• ULB Employee can file application for cleaning septic tank on behalf of Citizen

• ULB Employee can assign DSO to the given application with possible service date

• DSO can accept or reject the application

• DSO or ULB Employee can Complete the FSM Application after cleaning the septic tank

• FSM Admin in ULB can cancel the application at any stage before completing the application

• ULB Employee or Admin can view the audit log of the given application

• Capture citizen gender information if not present or pre-populate the gender information when Citizen is creating 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 made editable and price calculation will be now based on 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 vehicle

• Add ULB contact details in FSM application flow

• DSO can edit pit and property usage details

• Show vehicle trip status in employee inbox along with Desludging application
  
  

Deployment Details

1. Deploy the latest version of fsm

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

3. If index are to be created add the indexer config path in indexer service. (The file path is to be added in environment yaml file in param called egov-indexer-yaml-repo-path) and restart egov-indexer service.

Configuration Details

MDMS Configuration

Add master data in MDMS service with module name as FSM and restart the egov-mdms-service . Following is some sample master data for

Application Channel ( Source )

CheckList ( Checklist to be answered by citizen while rating )

Config ( Configuration at application level )

FSTP Plant Info ( FSTP information for each city )

PitType ( Type of pit )

Property Type

Slum ( Slums mapped to the locality of the city )

PaymentType (Payment preference type)

Business Service / Workflow Configuration

Create businessService (workflow configuration) using the  /businessservice/_create. Following is the product configuration for FSM:

For post new Business service FSM_POST_PAY_SERVICE has been created .Create businessService (workflow configuration) using the  /businessservice/_create. Following is the product configuration for FSM_POST_PAY_SERVICE:

Localization Setup

Using /localization/messages/v1/_upsert , add localisation (templates) for notification messages to be sent. Following are the product notification templates:

Actions & Role Action Mapping

Add Role-Action mapping for the API’s in MDMS. Following are the required entries. They should be mapped to both CITIZEN and appropriate employee roles.

Action Configuration

Role Action Mapping

Infra Ops Configuration

Configurations that we can manage through values.yml fsm-calculator in infraops repo as follows
values.yml for fms-calculator can be found here

Sample values.yml

Users

• User with userType employee and role

FSM_CREATOR_EMP role,

Integration

Integration Scope

FSM can be integrated with any ULB or system which wants to track FSM application. The organisations can customise the workflow depending on there product requirements 

Integration Benefits

• Easy tracking and resolution FSM Application

• Configurable workflow according to client requirement

Steps to Integration

1. Citizen/ULB Employee can file Application request using the /fsm/v1/_create

2. Organisation or System can search the FSM Applications using /fsm/v1/_searchendpoint

3. Once the Application is files the organisation or system can call /fsm/v1/_update endpoint to move the application further in workflow until it get resolved

Inbox api

• Introduced new inbox service to get the fsm applications in registered ULB employee inbox, With this ULB employee can track the application or perform the actions based on employee role.

• ULB employee can also apply the filter to check the particular state or applications or any other filter as required.

FSM apply as service

As of now we are providing fsm as adhoc service. In order to avoid multiple times user has to create the fsm request every time, In the system itself after some particular days, we will create same fsm application and if user wants service, he will pay the amount .

MDMS changes

As we mentioned above, we need to define time paramter, in order to create periodic application.For that we added the periodic service master where we will configure the time limit and either schedular is enabled or not. Please find the below configuration and location.

egov-mdms-data/data/pb/amritsar/FSM/PeriodicService.json at DEV · egovernments/egov-mdms-data

{ "tenantId": "pb.amritsar",

"moduleName": "FSM",

"PeriodicService":[

{

"timeLimit" : 864000000,

"isSchedularConfiguration":true

}

]

}

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.Please find the below configuration and file location.

egov-mdms-data/data/pb/common-masters/CronJobAPIConfig.json at DEV · egovernments/egov-mdms-data

{ "jobName": "daily",

"active": "true",

"method": "POST",

"url": "http://fsm.egov:8080/fsm/v1/_schedular",

"payload": {

"RequestInfo": "{DEFAULT_REQUESTINFO}" },

"header": { "Content-Type": "application/json"

}

}

We are using 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 the all eligiable aplications and create periodic applications for those fsm applications.

Infra changes

We added new chart called mdms-read-cronjob.Please find the below chart location.

DIGIT-DevOps/deploy-as-code/helm/charts/utilities/mdms-read-cronjob at master · egovernments/DIGIT-DevOps

Interaction Diagram

TBD

Reference Docs

Doc Links

API List