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.

As part of the worker welfare v1.0, 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. We will leverage the Individual Registry for storing and querying details about a worker.

The individual service is an enhanced version of the user service that houses data about individuals. The individual service is being re-used from DIGIT Health.

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. Part Search for FSM Registry Vendor Tab by vendor name

10. Updating vendor information, such as Gender, Mobile number, and Locality/Mohalla in FSM Registry.

ENHANCEMENT

Changes from Version 1.3.1 is 1.4.0

1. Change from driver concept to worker.

2. Deprecation of the driver table.

3. Backward compatibility for existing drivers (converting a driver user into an individual and mapping/backfilling to vendors).

4. Introducing worker vendor mapping.

5. Creation of workers directly using Individual registry APIs.

Kafka Topic Details

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

curl 'https://dev.digit.org/vendor/driver/v1/_update?tenantId=pb.amritsar' \
  -H 'authority: dev.digit.org' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'content-type: application/json;charset=UTF-8' \
  -H 'cookie: _ga=GA1.2.1852108775.1653914860; intercom-id-xp1951jv=17aa7431-3dc0-4524-9956-a22bb67a637f; __cuid=858e6f9f233c4b2c804d3f81109b48ac; amp_fef1e8=7faa94f4-6926-4f98-ac07-be2414f977c6R...1gkkb64lb.1gkkb6kvh.7p.a.83' \
  -H 'origin: https://dev.digit.org' \
  -H 'referer: https://dev.digit.org/digit-ui/employee/fsm/registry/modify-driver/b967d3ab-4ce4-41eb-931e-343734a673a0' \
  -H 'sec-ch-ua: "Not?A_Brand";v="8", "Chromium";v="108", "Google Chrome";v="108"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36' \
  --data-raw '{"driver":{"id":"b967d3ab-4ce4-41eb-931e-343734a673a0","tenantId":"pb.amritsar","name":"Vinot","owner":{"id":23597,"uuid":"1eaeae8e-e2cb-4736-b0da-2469441c7136","userName":"9876543210","password":null,"salutation":null,"name":"Vinot","gender":"MALE","mobileNumber":"9876543210","emailId":"abc@egov.com","altContactNumber":null,"pan":"","aadhaarNumber":null,"permanentAddress":"xxccc","permanentCity":null,"permanentPinCode":null,"correspondenceCity":null,"correspondencePinCode":null,"correspondenceAddress":"xxccc","active":true,"dob":1575504000000,"pwdExpiryDate":1542493260000,"locale":null,"type":"CITIZEN","signature":null,"accountLocked":false,"roles":[{"id":null,"name":"Citizen","code":"CITIZEN","tenantId":"pb"},{"id":null,"name":"FSM Desluding Operator","code":"FSM_DSO","tenantId":"pb"},{"id":null,"name":"FSM Driver","code":"FSM_DRIVER","tenantId":"pb"}],"fatherOrHusbandName":null,"relationship":"OTHER","bloodGroup":null,"identificationMark":null,"photo":null,"createdBy":"23299","createdDate":1533648094000,"lastModifiedBy":"28452","lastModifiedDate":1655290352000,"otpReference":null,"tenantId":"pb"},"ownerId":"1eaeae8e-e2cb-4736-b0da-2469441c7136","description":null,"licenseNumber":"34567899990","status":"ACTIVE","auditDetails":{"createdBy":"5674253d-9c2a-4d47-88ae-450f3fbbcad2","lastModifiedBy":"5674253d-9c2a-4d47-88ae-450f3fbbcad2","createdTime":1671536878567,"lastModifiedTime":1671536878567},"vendorDriverStatus":null},"RequestInfo":{"apiId":"Rainmaker","authToken":"5aac2f5f-086b-4770-a832-023641a62650","userInfo":{"id":28452,"uuid":"5674253d-9c2a-4d47-88ae-450f3fbbcad2","userName":"BPAFieldInspector","name":"lakshmi","mobileNumber":"8656565343","emailId":null,"locale":null,"type":"EMPLOYEE","roles":[{"name":"FSM Administrator","code":"FSM_ADMIN","tenantId":"pb.amritsar"},{"name":"BPA Services Approver","code":"BPA_APPROVER","tenantId":"pb.amritsar"},{"name":"Employee","code":"EMPLOYEE","tenantId":"pb.amritsar"},{"name":"FSM Employee Report Viewer","code":"FSM_REPORT_VIEWER","tenantId":"pb.amritsar"},{"name":"BPA Services verifier","code":"BPA_VERIFIER","tenantId":"pb.amritsar"},{"name":"BPA Field Inspector","code":"BPA_FIELD_INSPECTOR","tenantId":"pb.amritsar"},{"name":"BPAREG doc verifier","code":"BPAREG_DOC_VERIFIER","tenantId":"pb.amritsar"}],"active":true,"tenantId":"pb.amritsar","permanentCity":null},"msgId":"1671537564062|en_IN","plainAccessRequest":{}}}' \
  --compressed

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

Create Worker

Update Vendor

Architecture Diagram

Reference Docs

Doc Links

API List

Overview

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

This document contains the details on how to set up the FSM calculator service, describes the functionalities it provides, and details the enhancements made to the FSM calculator service.

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-calculator-persister config path added in it

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

• The following services should be up and running-

- egov-perister

- egov-mdms

- fsm

- billing-service

Key Functionalities

EXISTING

• FSM admin, an employee of ULB with FSM admin role can create, update billing slab(s).

• ULB employee with FSM_CREATOR and FSM_EDITOR can search billing slab(s).

• ULB employee citizen can file, track and rate the application for cleaning septic tank.

• ULB employee can get the estimate for the FSM application.

• FSM service internally call fsm-calculator to generate a demand.

• Vehicle type check has been removed from calculator service and the bill amount is calculated based on the number of trips entered while submitting the FSM application.

ENHANCEMENT

• Bill amount is calculated based on the number of trips entered while updating the number of trips in the FSM application.

• Added validation for advance payment with the configuration.

• Added validation for maximum total advance payment.

• Added cancellation charges for canceling the application.

• Validation before completing the request with the payment.

• Minimum part payment is configurable, that is, it should be fixed or percentage calculation, and the calculation should done based on the mdms config value.

• Minimum cancellation fee is configurable, that is, it should be fixed or percentage calculation, and the calculation should done based on the mdms config value.

• Demand generation process: Generating demand every time the trip is updates.

• Demand generation process: Added validation not to complete the application from the ULB side before completing the payment.

Data Setup

Billing Slab Setup

Create billing slab with combination of PropertyType, refer values from PropertyType Mdms, Slum (YES/NO), capacityFrom and capacityTo refers to the Vehicle Tank Capacity.

Sample Curl

curl --location --request POST 'http://localhost:9098/fsm-calculator/v1/billingSlab/_create' \
--header 'Content-Type: application/json' \
--data-raw '{
    "RequestInfo": {
        "apiInfo": {
            "id": "string",
            "version": "string",
            "path": "string"
        },
        "deviceDetail": {
            "id": "string",
            "signature": "string"
        },
        "ts": 0,
        "action": "string",
        "key": "string",
        "msgId": "string",
        "requesterId": "string",
        "authToken": "a35b5ba7-2d5f-4272-8a67-0303cfab2c9f"
    },
   "billingSlab":{
          
            "tenantId": "pb.amritsar",
            "capacityFrom": 1000.00,
            "capacityTo": 50000.00,
            "propertyType": "RESIDENTIAL.ROW_HOUSES",
            "slum": "NO",
            "price": 9000.00,
            "status": "ACTIVE"
        },
    "workflow": null
}'

Integration

Integration Scope

The FSM-calculator will be integrated with the FSM application. The FSM application internally will invoke the fsm-calculator service to calculate and generate demand for the charges.

Integration Benefits

• The calculation and demand generation logic will be separated from the FSM service. For each implementation, the calculation implementation can be changed, if required, without modifying the FSM service.

Steps to Integration

1. FSM application to call fsm-calulator/v1/_calculate to calculate and generate the demand for the fsm application.

2. ULB employee can call fsm-calculator/v1/_estimate to get the estimates for the fsm application.

3. ULB Employee can create billing slab calling fsm-calculator/v1/billingSlab/_create

4. ULB employee can update billing slab calling fsm-calculator/v1/billingSlab/_update

5. ULB Employee can search billing slab calling fsm-calculator/v1/billingSlab/_search

6. FSM application to call fsm-calculator/v1/_cancellationFee to calculate cancellation charge based on the configuration data, that is, either it will be fixed or it will be a percentage.

FSM application to call fsm-calculator/v1/_advanceBalanceCalculate to calculate the advance charge based on the configuration data, that is, either it will be fixed or a percentage.

Interaction Diagram

TBD

Reference Docs

Doc Links

API List

Overview

Vehicle registry is a system that enables urban local body (ULB) employees to create and search vehicle entities, schedule vehicle trips for FSM application and track vehicle trips. This document contains the details about the new enhancements made to the vehicle service and how to set up the vehicle and describes the functionalities provided.

Pre-requisites

Before you proceed with the configuration, make sure the following prerequisites are met:

• Java 8

• Kafka server is up and running.

• egov-persister service is running and has vehicle-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-perister

- egov-mdms-service

- egov-workflow-v2

- egov-idgen

Key Functionalities

EXISTING

1. DSO or ULB can create multiple vehicle trips based on the number of trips entered while submitting the FSM application.

2. FSTPO can decline the vehicle trip with appropriate reason.

3. Owner attribute has been added to the vehicle.

4. FSTPO Vehicle Log Inbox Enhancements to include Application No search filter so that FSTPO can view all the vehicle trips associated with the application.

5. FSPTO vehicle log API upgraded to show trip numbers in case of multi-trip application.

6. Introduced Vehicle Tab.

7. Option to add/remove/update vehicle individually.

8. Admin can enable or disable the vehicle.

9. Functionality to add/remove vehicles to vendor.

ENHANCEMENT

1. Part Search: The Vehicle tab now includes the ability to perform a part search by vehicle number. This means that users can enter a partial vehicle number and retrieve all relevant results that contain that specific portion. For example, if the vehicle number is "AA 77 JJ 3324", users can search for any part of the vehicle number, such as "AA", "77", or "JJ", and retrieve all relevant results that contain that specific portion.

2. Updating Registry Information: In the Vehicle Tab, the admin has the ability to update certain vehicle information, such as Owner name, Phone Number. Added a new column for gender , Dob and Email address which are updatable.

Data Setup

Create Vehicle

Create a vehicle with one of the vehicle types available in the VehicleMakeModel MDMS.

Sample Curl

curl 'https://dev.digit.org/vehicle/v1/_create?tenantId=pb.amritsar' \
  -H 'authority: dev.digit.org' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'content-type: application/json;charset=UTF-8' \
  -H 'cookie: _ga=GA1.2.1852108775.1653914860; intercom-id-xp1951jv=17aa7431-3dc0-4524-9956-a22bb67a637f; __cuid=858e6f9f233c4b2c804d3f81109b48ac; amp_fef1e8=7faa94f4-6926-4f98-ac07-be2414f977c6R...1gkkb64lb.1gkkb6kvh.7p.a.83' \
  -H 'origin: https://dev.digit.org' \
  -H 'referer: https://dev.digit.org/digit-ui/employee/fsm/registry/new-vehicle' \
  -H 'sec-ch-ua: "Google Chrome";v="107", "Chromium";v="107", "Not=A?Brand";v="24"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36' \
  --data-raw '{"vehicle":{"tenantId":"pb.amritsar","registrationNumber":"AS 12 AS 1234","model":"MAHINDRA","type":"MAHINDRA.BOLERO_PICKUP","tankCapacity":"5000","suctionType":"SEWER_SUCTION_MACHINE","pollutionCertiValidTill":null,"InsuranceCertValidTill":null,"fitnessValidTill":null,"roadTaxPaidTill":null,"gpsEnabled":true,"source":"Municipal records","owner":{"tenantId":"pb","name":"raj","fatherOrHusbandName":"raj","relationship":"OTHER","gender":"OTHERS","dob":-19800000,"emailId":"abc@egov.com","correspondenceAddress":"","mobileNumber":"9876543210"},"additionalDetails":{"description":""}},"RequestInfo":{"apiId":"Rainmaker","authToken":"df28f073-4caf-456e-bd43-1943ce76548c","userInfo":{"id":28452,"uuid":"5674253d-9c2a-4d47-88ae-450f3fbbcad2","userName":"BPAFieldInspector","name":"lakshmi","mobileNumber":"8656565343","emailId":null,"locale":null,"type":"EMPLOYEE","roles":[{"name":"FSM Administrator","code":"FSM_ADMIN","tenantId":"pb.amritsar"},{"name":"BPA Services Approver","code":"BPA_APPROVER","tenantId":"pb.amritsar"},{"name":"Employee","code":"EMPLOYEE","tenantId":"pb.amritsar"},{"name":"FSM Employee Report Viewer","code":"FSM_REPORT_VIEWER","tenantId":"pb.amritsar"},{"name":"BPA Services verifier","code":"BPA_VERIFIER","tenantId":"pb.amritsar"},{"name":"BPA Field Inspector","code":"BPA_FIELD_INSPECTOR","tenantId":"pb.amritsar"},{"name":"BPAREG doc verifier","code":"BPAREG_DOC_VERIFIER","tenantId":"pb.amritsar"}],"active":true,"tenantId":"pb.amritsar","permanentCity":null},"msgId":"1671428547643|en_IN","plainAccessRequest":{}}}' \
  --compressed

Integration

Integration Scope

Integrated with the application through REST API to create, and search vehicles. For any module where the vehicle trip is required, one can integrate REST API trip/v1/create, update, and search.

Integration Benefits

• Vehicle management would become easy.

• Trip management would become easy.

Steps to Integration

• FSM application can vehicle/v1/_search to validate the FSM vehicle assignment.

• FSM application call vehicle/trip/v1/_create on assigning vehicle to the spplication.

• FSTP operators can mark the vehicleTrip as DISPOSED.

Interaction Diagrams

Reference Docs

Doc Links

API List

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 mdms

• employeeUuid : 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.

1. path:- deploy-as-code/helm/charts/sanitation/fsm/values.yaml - link

2. Create plantInfo in PQM.Plant schema .

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

1. Citizen/ULB employee can file application request using the /fsm/v1/_create.

2. An organisation or system can search the FSM Applications using /fsm/v1/_searchendpoint.

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

 {
      "module": "fsm",
      "index": "fsm-application",
      "allowedSearchCriteria": [
        {
          "name": "tenantId",
          "path": "Data.tenantId.keyword",
          "isMandatory": false,
          "operator": "EQUAL"
        },
        {
          "name": "status",
          "path": "Data.currentProcessInstance.state.uuid.keyword",
          "isMandatory": false
        },
        {
          "name": "mobileNumber",
          "path": "Data.mobileNumber.keyword",
          "isMandatory": false
        },
        {
          "name": "locality",
          "path": "Data.locality.keyword",
          "isMandatory": false
        },
        {
          "name": "assignee",
          "path": "Data.currentProcessInstance.assignes.uuid.keyword",
          "isMandatory": false
        },
        {
          "name": "applicationNos",
          "path": "Data.applicationNo.keyword",
          "isMandatory": false,
          "operator": "WILDCARD"
        },
        {
          "name": "fromDate",
          "path": "Data.auditDetails.createdTime",
          "isMandatory": false,
          "operator": "GTE"
        },
        {
          "name": "toDate",
          "path": "Data.auditDetails.createdTime",
          "isMandatory": false,
          "operator": "LTE"
        }
      ],
      "sortBy": {
        "path": "Data.@timestamp",
        "defaultOrder": "DESC"
      },
      "sourceFilterPathList": [
        "Data.currentProcessInstance",
        "Data.auditDetails",
        "Data.additionalDetails",
        "Data.tenantId",
        "Data.applicationNo",
        "Data.workflow",
        "Data.locality"
      ]
    }

• 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

{ "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. Find the configuration and file location below:

{ "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 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:

https://github.com/egovernments/DIGIT-DevOps/tree/master/deploy-as-code/helm/charts/utilities/mdms-read-cronjob

Interaction Diagram

1. Advance Amount Workflow

2. Zero Price Application Workflow

Sequence Diagram

Reference Docs

Doc Links

API List

test