Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The FSTP plant info contains plant operational capacity per day of each ULB and other plant-related information. It is required to calculate the FSTP capacity utilization in percentage form. MDMS file details:
egov-mdms-data/FSTPPlantInfo.json at QA · egovernments/egov-mdms-data``
In this document, we will learn how to legacy index/re-index the fsm index.
Kubectl access to the required environment in which you want to run the re-indexing
playground pod access
Legacy index mapping/configuration done in the respective indexer-config ( in this case for FSM, legacy index configuration for fsm is done here, Similarly for VehicleTrip also exists )
Postman collection to re-index the data for FSM, VehicleTrip, Vehicle, Vendor Services can be downloaded here
After importing the postman collection downloaded from above section, you can find two request
fsm-legacy : This request helps to get the data from fsm/plainsearch api and push data to fsm-enriched topic by indexer service
fsm-legacy-kafkaconnector : This is the request to create a connector which can listen to the fsm-enriched topic and push data to the elastic search with the new index fsm-enriched
Run the fsm-legacy-kafkaconnector request in the playground pod, which would create a connector which would intern start listening to the topic fsm-enriched-sink
Run the fsm-legacy request in the playground pod, which would call indexer service to intiate the process of fetching the data from plainsearch and push the data prepared according to the legacy-index mapping and push the data to the fsm-enriched-sink topic
Whole process would take some time, mean while you can searc for the data in fsm-enriched index in the elastic search
we can go through the logs of the indexer pod, which would help to understand the job is done
Once the job is done, delete the kafka connector running the below curl in the playground curl --location --request DELETE 'http://kafka-connect.kafka-cluster:8083/connectors/fsm-enriched-es-sink'
Once reindexing is completed, please verfiy the count in fsm index and fsm-enriched index, then delete the fsm index and create alias for fsm-enriched index as fsm.Please use below command for alias creating.
After importing the postman collection downloaded from above section, you can find two request
vehicleTrip-legacy : This request helps to get the data from vehicletrip/plainsearch api and push data to vehicletrip-enriched topic by indexer service
vehicle-trip-legacy-kafkaconnector : This is the request to create a connector which can listen to the vehicletrip-enriched topic and push data to the elastic search with the new index vehicletrip-enriched
Run the vehicletrip-legacy-kafkaconnector request in the playground pod, which would create a connector which would intern start listening to the topic vehicletrip-enriched-sink
Run the vehicletrip-legacy request in the playground pod, which would call indexer service to intiate the process of fetching the data from plainsearch and push the data prepared according to the legacy-index mapping and push the data to the vehicletrip-enriched-sink topic
Whole process would take some time, mean while you can searc for the data in vehicletrip-enriched index in the elastic search
we can go through the logs of the indexer pod, which would help to understand the job is done
Once the job is done, delete the kafka connector running the below curl in the playground curl --location --request DELETE 'http://kafka-connect.kafka-cluster:8083/connectors/vehicletrip-enriched-es-sink'
Once reindexing is completed, please verfiy the count in vehicletrip index and vehicletrip-enriched index, then delete the vehicletrip index and create alias for vehicletrip-enriched index as vehicletrip.Please use below command for alias creating.
Details for setting up FSM calculator service
FSM Calculator is a system that enables FSM Admin to create billing slab for the FSM application(s) with different combination of propertyType , slum , tank capacity and etc..
Generates the Demand after calculating the charges for the given application using the billing slab already configured. This document contains the details about how to setup the fsm-calculator service and description the functionalities it provides.
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
Following services should be up and running:
egov-perister
egov-mdms
fsm
billing-service
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 FSM Application
FSM service internally call fsm-calculator to generate a demand
Deploy the latest version of fsm
Add fsm-calculator-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 )
FSM MDMS Configuration is sufficient
NA
Actions
Role Action Mapping
Infra Ops Configuration
Configurations sample in Values.yml
Sample Curl
FSM-calculator will be integrated with FSM Application. FSM Application internally invokes the fsm-calculator service to calculate and generate demand for the charges.
Calculation and demand generation logic will be separated from the FSM service. For each implementation, calculation implementation can be changed if required without modifying the fsm service.
FSM application to call fsm-calulator/v1/_calculate to calculate and generate the demand for the fsm application
ULB Employee can call fsm-calculator/v1/_estimate to get the estimates for the fsm application
ULB Employee can create billing slab calling fsm-calculator/v1/billingSlab/_create
ULB Employee can update billing slab calling fsm-calculator/v1/billingSlab/_update
ULB Employee can search billing slab calling fsm-calculator/v1/billingSlab/_search
TBD
Details for registering new vendors
Vendor Registry is a system that enables ULB Employees to create and search Vendor i.e Desludging Operator (DSO) and driver entities with appropriate vehicle Entities for FSM Application. This document contains details about how to set up the Vendor and describe the functionalities provided.
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 a database is created to store FSM Application data
Following services should be up and running:
egov-mdms-service
egov-user-service
boundary-service
vehicle
Deploy the latest version of FSM
Add vehicle-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 )
NA
NA
Actions
Role Action Mapping
Infra Ops Configuration
Configurations that we can manage through values.yml vehicle in infraops repo as follows values.yml for the vehicle can be found**.**
Configurations sample in Values.yml
DSO for FSM System is a vendor, For every city/ULB DSO should be created with the Representative details as owner, associated vehicles and drivers
Sample Curl
Any system or digit module can ****be integrated with Vendor Service, helps to manage the Vendor with the vehicles, drivers and owner for representative and login for the representative/owner to login into the system to carry our role-specific operations.
Validation of DSO/Vendor availability
Fetch the vehicle assigned to the DSO
Fetch the Drivers assigned to the DSO
FSM to call vendor/v1/_search to fetch the DSO’s
FSM can call vendor/v1/_search to fetch the DSO’s and the respective vehicles and drivers
TBD
Faecal sludge management (FSM) is a system that enables the citizen to raise a request for septic tank cleaning with the ULBs directly or by reaching out to the ULB counter. The citizen can track the application, make a payment for the charges and rate the service. This document contains details about how to set up the fsm and describes the functionalities it provides.
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. 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
A citizen can file, track and rate the application for cleaning septic tank
ULB Employee can file an application for cleaning septic tank on behalf of Citizen
ULB Employee can assign DSO to the given application with a 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
Deploy the latest version of fsm
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.
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.
Add master data in MDMS service with the module name as FSM and restart the egov-mdms-service. Following is some sample master data for
Application Channel (Source)
The checkList (Checklist to be answered by a citizen while rating)
Config (Configuration at the 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 )
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for FSM:
Using /localization/messages/v1/_upsert , add localisation (templates) for notification messages to be sent. Following are the product notification templates:
Add Role-Action mapping for the APIs 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
Sample values.yml
Users
User with userType employee and role FSM_CREATOR_EMP role,
FSM can be integrated with any ULB or system which wants to track FSM application. The organisations can customise the workflow depending on the product requirements**.**
Easy tracking and resolution FSM Application
Configurable workflow according to client requirement
Citizen/ULB Employee can file Application request using the /fsm/v1/_create
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 workflow until it gets resolved
TBD
Learn how to setup and configure FSM service
Faecal Sludge Management (FSM) is a system that enables a citizen to raise a request for septic tank cleaning with there ULB’s directly or by reaching out to the ULB counter. The Citizen can track the application, make a payment for the charges and rate the service. This document contains the details about how to set up the FSM services and describes the functionalities it provides.
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-localization
egov-notification-sms
egov-mdms
egov-idgen
egov-url-shortening
vehicle
vendor
fsm-calculator
billing-service
collection-services
A Citizen can file, track and rate the application for cleaning septic tank
ULB Employee can file an application for cleaning septic tank on behalf of Citizen
ULB Employee can assign DSO to the given application with a 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
Deploy the latest version of FSM
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 )
If an index is 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)
Add master data in MDMS service with the module name as FSM. Following is some sample master data for Application Channel (Source).
Checklist (Checklist to be answered by a citizen while rating)
Config (Configuration at the application level)
FSTP Plant Info (FSTP information for each city)
Pit Type (Type of pit)
Property Type
Slum (Slums mapped to the locality of the city)
Create businessService (workflow configuration) using the __/businessservice/_create.
Following is the product configuration for FSM:
Using /localization/messages/v1/_upsert , add localisation (templates) for notification messages to be sent.
Following are the product notification templates
Add Role-Action mapping for the APIs 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
Sample values.yml
Users
User with userType employee and role FSM_CREATOR_EMP role,
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
Easy tracking and resolution FSM Application
Configurable workflow according to client requirement
Citizen/ULB Employee can file Application request using the /fsm/v1/_create
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 workflow until it gets 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 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. Please find the below configuration and location.
{ "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.
{ "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 reads the master data for each tenant and based on the time limit configured for that tenant, it gets all eligible applications and creates periodic applications for those FSM applications.
Infra changes
We added a new chart called mdms-read-cronjob. Please find the below chart location.
TBD
DSS has two sides to it. One being the process in which the Data is pooled to ElasticSearch and the other being the way it is fetched, aggregated, computed, transformed and sent across.
As this revolves around a variety of Data Set, there is a need for making this configurable. So that, tomorrow, given a new scenario is introduced, then it is just a configuration away from getting the newly introduced scenario involved in this flow of process.
This document explains the steps on how to define the configurations for Analytics Side Of DSS for FSM.
Analytics : Micro Service which is responsible for building, fetching, aggregating and computing the Data on ElasticSearch to a consumable Data Response. Which shall be later used for visualizations and graphical representations.
Analytics contains multiple configurations. we need to add the changes related to fsm in this dashboard-analytics. Here is the location : configs/egov-dss-dashboards/dashboard-analytics at qa · egovernments/configs Below is a list of configurations that need to be changed to run fsm successfully.
Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration
Chart API Configuration
Each Visualization has its own properties. Each Visualization comes from different data sources (Sometimes it is a combination of different data sources)
In order to configure each visualization and their properties, we have a Chart API Configuration Document.
In this, Visualization Code, which happens to be the key, will be having its properties configured as a part of configuration and are easily changeable.
Here is the sample ChartApiConfiguration.json data for the fsm.
Click here to check the complete configuration
Master Dashboard Configuration is the main configuration which defines as which are the Dashboards which are to be painted on screen.
It includes all the Visualizations, their groups, the charts which comes within them and even their dimensions as what should be their height and width.
Click here for the complete configuration
Master Dashboard Configuration which was explained earlier hold the list of Dashboards which are available.
Given the instance where Role Action Mapping is not maintained in the Application Service, this configuration will act as Role - Dashboard Mapping Configuration
In this, each Role is mapped against the Dashboard which they are authorized to see
This was used earlier when the Role Action Mapping of eGov was not integrated.
Later, when the Role Action Mapping started controlling the Dashboards to be seen on the client side, this configuration was just used to enable the Dashboards for viewing.
Click here to check the configuration
common-masters/uiCommonConstants.json
Click here to check the complete configuration
roleaction.json
Click here to check the complete configuration
Action test.json:
Click here to check the complete configuration
FSM-DSS Consists of multiple graphs which represent the data of FSM. Each graph has its own configuration which will describe the chart and its type.
DSS Consists of following charts in FSM:
Overview
Total Cumulative Collection
Top ULB By Performance
Bottom ULB by Performance
FSM Collection by Usage Type
FSTP - Capacity Utilization
Monthly Septage Collected
Top DSO By Performance
Bottom DSO By Performance
Desludging Request Report
Vehicle Log Report
Overview graph contains multiple data information as below in the selected time period.
Total Requests : Which represents the no of FSM applications count.
Total Sludge Treated : This represents the total sludge dumped at the yard in KL.
Average FSM Cost : This represents the average collection amount for the FSM applications.
Total Collection : This represents the total collection amount for the FSM applications.
SLA Compliance : This represents the total SLA achieved in percentage.
Average Citizen Rating : This represents the Citizen Average Rating value.
This Graph contains the collection amount information in the monthly base as a cumulative line graph. This will change as per the denomination amount filter selection.
This graph represents the ULB’s based on the sla achieved in bar chart representation with the % of sla achieved in ascending order. Also this chart contains the drill down to give the complete information regarding each ULB.
drillChart : If there is a drill down on the visualization, then the code of the Drill Down Visualization is added here. This will be used by Client Service to manage drill downs.
This chart consists of drill down so we gave the drill down chart key as reference in this chart as in the above picture.
Here is the drill down chart config params.
Table chart Sample: This chart comes with 2 kinds, table and xtable.
table type allows aggregated fields added as available in the query keys, hence to extract the values based on the key, aggegationPaths needs to add along with their data type as in pathDataTypeMapping.
On click of show more You will navigate to tabular chart of bottom ULB by performance.
This graph shows the collection amount based on the usage/property type and this amount will change as per the denomination filter change and this also shows the % of the top 4 properties, remaining properties will go under others category.
This graph is in the line chart representation and shows the data in cumulative format, and it contains the information about the waste collecting plant capacity utilization in % and also shows the total waste dumped at plant in KL at the top of the graph.
This graph represents the DSO’s based on the no of dso requests and based on sla achievement in bar chart representation in descending order. Also this chart contains the drill down to give the complete information regarding each DSO.
This is the bottom DSO drill down chart which represents the table chart type.
On click of show more we can see the details of the available DSO’s under the selected ULB.
This tabular chart representation graph shows multiple FSM information like no of open application requests, closed requests, total requests, completion rate in %, sla achieved in % and total collection amount. And this table shows the data in district level and also has the drill down chart for each district to ulb and from ulb to ward level data for the same.
xtable type allows to add multiple computed fields with the aggregated fields dynamically added.
To add multiple computed columns, computedFields [] where actionName (IComputedField<T> interface), fields [] names as in exist in query key, newField as name to appear for computation must be defined.
chartSpecificProperty : This is specific to FSM-DSS, and it is used to achieve the xtable column order along with the computed fields. This property is not used in any other modules till now.
On click of any district name will enter into drill down charts, which will represents that specific District data.
On click of the ULB will navigate to wards under that specific ULB and each ward shows the specific data regarding that ward.
This table shows data data of vehicle trips which have no of trips, Total septage collected, total septage dumped and capacity utilization in %. This graph also contains the drills downs from district to ULB and from ULB to vehicle level, which shows the vehicle no.
On click of any district name will enter into drill down charts, which will represents that specific District data.
On click of any boundary/ ULB we will navigate to specific vehicle details which will be as below.
isRoundOff: This property is introduced to round off the decimal values. Ex: if the value is 25.43 by using isRoundOff property in configuration we will get it as 25. if value is 22.56 round of value will be 23. This can be used for insights configuration as well for overview graph.
Key(eg: fsmTotalrequest) : This is the Visualization Code. This key will be referred to in further visualization configurations.
This is the key which will be used by the client application to indicate which visualization is needed for display.
chartName : The name of the Chart which has to be used as a label on the Dashboard. The name of the Chart will be a detailed name.
In this configuration, the Name of the Chart will be the code of Localization which will be used by Client Side.
queries : Some visualizations are derived from a specific data source. While some others are derived from different data sources and are combined together to get a meaningful representation.
The queries of aggregation which are to be used to fetch out the right data in the right aggregated format are configured here.
queries.module : The module / domain level, on which the query should be applied on. Facial Sludge Management is fsm.
queries.indexName : The name of the index upon which the query has to be executed is configured here.
queries.aggrQuery : The aggregation query in itself is added here. Based on the Module and the Index name specified, this query is attached to the filter part of the complete search request and then executed against that index
queries.requestQueryMap : Client Request would carry certain fields which are to be filtered. The parameters specified in the Client Request are different from the parameters in each of these indexed documents.
In order to map the parameters of the request to the parameters of the ElasticSearch Document, this mapping is maintained.
queries.dateRefField : Each of these modules have separate indexes. And all of them have their own date fields.
When there is a date filter applied against these visualizations, each of them has to apply it against their own date reference fields.
In order to maintain what is the date field in which index, we have this configured in this configuration parameter.
chartType : As there are different types of visualizations, this field defines what is the type of chart / visualization that this data should be used to represent.
Chart types available are:
metric - this represents the aggregated amount/value for records filter by the aggregate es query
pie - this represents the aggregated data on grouping. This is can be used to represent any line graph, bar graph, pie chart or donuts
line - this graph/chart is data representation on date histograms or date groupings
perform - this chart represents groping data as performance wise.
table - represents a form of plots and value with headers as grouped on and list of its key, values pairs.
xtable - represents a advanced feature of table, it has addition capabilities for dynamic adding header values.
valueType : In any case of data, the values which are sent to plot, might be a percentage, sometimes an amount and sometimes it is just a count.
In order to represent them and differentiate the numbers from amount from percentage, this field is used to indicate the type of value that this Visualization will be sending.
action : Some of the visualizations are not just aggregation on data source. There might be some cases where we have to do a post aggregation computation.
For Example, in the case of Top 3 Performing ULBs, the Target and Total Collection is obtained and then the percentage is calculated. In these kinds of cases, what is the action that has to be performed on that data obtained is defined in this parameter.
documentType : The type of document upon which the query has to be executed is defined here.
drillChart : If there is a drill down on the visualization, then the code of the Drill Down Visualization is added here. This will be used by Client Service to manage drill downs.
aggregationPaths : All the queries will be having Aggregation names in it. In order to fetch the value out of each Aggregation Responses, the name of the aggregation in the query will be an easy bet. These aggregation paths will have the names of Aggregation in it.
insights : It is to show the data with the comparison of last year with arrow symbols, it will show the data in how much % is increased or decreased.
_comment : In order to display information on the “i” symbol of each visualization, Visualization Information is maintained in this field.
Postman collection for fsm-dss: https://www.getpostman.com/collections/119ee90dd54c04617c3a
Configurations that we can manage through values.yml fsm-calculator in infraops repo as follows values.yml for fms-calculator can be found
Create Billing Slab with ****a combination of PropertyType refer values form , Slum ( YES/NO), capacityFrom and capacityTo refers to Vehicle Tank Capacity.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
Configurations that we can manage through values.yml fsm-calculator in infraops repo as follows values.yml for fms-calculator can be found
All content on this page by is licensed under a .
Configurations that we can manage through values.yml fsm-calculator in infraops repo as follows values.yml for fms-calculator can be found
All content on this page by is licensed under a .
line - this graph/chart is data representation on date histograms or date groupings.
This graph represents the ULB’s based on the sla achieved in bar chart representation with the % of sla achieved in descending order. Also this chart contains the drill down to give the complete information regarding each ULB.
This graph shows the data in horizontal bar representation and bars contain data in monthly wide and non cumulative data. This graph contains the monthly information of septage collected and dumped at the plant in KL.
This graph represents the DSO’s based on the no of dso requests and based on sla achievement in bar chart representation in ascending order. Also, this chart contains the drill down to give the complete information regarding each DSO.
On click of show more we can see the details of the available DSO’s under the selected ULB.
Description
name in values.yml
Current Value
contextPath of the api’s
SERVER_CONTEXTPATH
/fsm-calculator
Kafka Consumer Group
SPRING_KAFKA_CONSUMER_GROUP_ID
fsm-calculator
kafka topic to which service push data to save new billing slab
PERSISTER_SAVE_BILLING_SLAB_TOPIC
save-fsm-billing-slab
kafka topic to which service push data to update the existing billing slab
PERSISTER_UPDATE_BILLING_SLAB_TOPIC
update-fsm-billing-slab
mdms service host
EGOV_MDMS_HOST
egov-mdms-service from egov-service-host
billing-service host
EGOV_BILLINGSERVICE_HOST
billing-service from egov-service-host
fsm service host
EGOV_FSM_HOST
fsm from egov-service-host
Title
Link
Workflow Technical Document
User Technical Document
MDMS Technical Document
NEEDS TO BE UPDATED
IDGen Technical Document
NEEDS TO BE UPDATED
Localization Technical Document
NEEDS TO BE UPDATED
Persister Technical Document
NEEDS TO BE UPDATED
SMS Notification Technical Document
NEEDS TO BE UPDATED
API Contract
Postman Scripts
Title
Link
fsm-calulator/v1/_calculate
fsm-calculator/v1/_estimate
fsm-calculator/v1/billingSlab/_create
fsm-calculator/v1/billingSlab/_update
fsm-calculator/v1/billingSlab/_search
Description
name in values.yml
Current Value
Kafka Consumer Group
SPRING_KAFKA_CONSUMER_GROUP_ID
egov-vendor-services
kafka topic to which service push data to save new Vendor
PERSISTER_SAVE_VENDOR_TOPIC
save-vendor-application
mdms service host
EGOV_MDMS_HOST
egov-mdms-service from egov-service-host
Vehicle Service host
EGOV_VEHICLE_HOST
vehicle from egov-service-host
User service host
EGOV_USER_HOST
egov-user-service from egov-service-host
Location Service Host
EGOV_LOCATION_HOST
egov-location from egov-service-host
Title
Link
Workflow Technical Document
User Technical Document
MDMS Technical Document
NEEDS TO BE UPDATED
IDGen Technical Document
NEEDS TO BE UPDATED
Localization Technical Document
NEEDS TO BE UPDATED
Persister Technical Document
NEEDS TO BE UPDATED
SMS Notification Technical Document
NEEDS TO BE UPDATED
API Contract
Postman Scripts
Title
Link
v1/_create
v1/_search
Description
name in values.yml
Current Value
id-gen host, to generate the application number
EGOV_IDGEN_HOST
egov-idgen from egov-service-host
Kafka Consumer Group
SPRING_KAFKA_CONSUMER_GROUP_ID
egov-fsm-service
kafka topic to which service push data to save new fsm application
PERSISTER_SAVE_FSM_TOPIC
save-fsm-application
kafka topic to which service push data to save workflow status
PERSISTER_UPDATE_FSM_WORKFLOW_TOPIC
update-fsm-workflow-application
kafka topic to which service push data to update the existing fsm application
PERSISTER_UPDATE_FSM_TOPIC
update-fsm-application
mdms service host
EGOV_MDMS_HOST
egov-mdms-service from egov-service-host
billing-service host
EGOV_BILLINGSERVICE_HOST
billing-service from egov-service-host
fsm-calculator service host
EGOV_FSM_CALCULATOR_HOST
fsm-calculator from egov-service-host
workflow v2 service host
WORKFLOW_CONTEXT_PATH
egov-workflow-v2 from egov-service-host
ui host, to return send the url of new application in sms notification
EGOV_UI_APP_HOST
egov-services-fqdn-name from egov-service-host
vendor service host, to get DSO details
EGOV_VENDOR_HOST
vendor from egov-service-host
Vehicle service host, to get vehicle details and manage vehicleTrip
EGOV_VEHICLE_HOST
vehicle from egov-service-host
Collection service host, to get the payment details
EGOV_COLLECTION_SERVICE_HOST
collection-services from egov-service-host
localization service host, to get the locale data
EGOV_LOCALIZATION_HOST
egov-localization from egov-service-host
user service host, to get the locale data
EGOV_USER_HOST
egov-user from egov-service-host
pdf service host, to get the locale data
EGOV_PDF_HOST
pdf-service from egov-service-host
url shortening service host, to get the short url for the long once
EGOV_URL_SHORTNER_HOST
egov-url-shortening from egov-service-host
User
Role
Description
How to create
FSM Creator
FSM_CREATOR_EMP
Can create FSM Application on behalf of Citizen
Through HRMS with role
FSM Editor
FSM_EDITOR_EMP
Can edit the application created by citizen for demand generation
Assing/ Re-Assign DSO
Complete the Application
Through HRMS with role
FSM Admin
FSM_ADMIN
Can cancel the application at any stage of workflow
Through HRMS with role
DSO
FSM_DSO
can accept/Reject the assigned Application
can complete the FSM Application
Through vendor service, use the create DSO Request from postman Collection
FSTP Operator
FSM_EMP_FSTPO
Can mark the vehicle Trip as disposed. Not FSM Service User
Through HRMS with role
Collector
FSM_COLLECTOR
Can collect the payment amount for application based on demand
Through HRMS with role
Title
Link
Workflow Technical Document
User Technical Document
MDMS Technical Document
NEEDS TO BE UPDATED
IDGen Technical Document
NEEDS TO BE UPDATED
Localization Technical Document
NEEDS TO BE UPDATED
Persister Technical Document
NEEDS TO BE UPDATED
SMS Notification Technical Document
NEEDS TO BE UPDATED
HRMS Technical Document
NEEDS TO BE UPDATED
API Contract
Postman Collection
Title
Link
/fsm/v1/_create
/fsm/v1/_update
/fsm/v1/_search
/fsm/v1/_audit
Description
name in values.yml
Current Value
id-gen host, to generate the application number
EGOV_IDGEN_HOST
egov-idgen from egov-service-host
Kafka Consumer Group
SPRING_KAFKA_CONSUMER_GROUP_ID
egov-fsm-service
kafka topic to which service push data to save new fsm application
PERSISTER_SAVE_FSM_TOPIC
save-fsm-application
kafka topic to which service push data to save workflow status
PERSISTER_UPDATE_FSM_WORKFLOW_TOPIC
update-fsm-workflow-application
kafka topic to which service push data to update the existing fsm application
PERSISTER_UPDATE_FSM_TOPIC
update-fsm-application
mdms service host
EGOV_MDMS_HOST
egov-mdms-service from egov-service-host
billing-service host
EGOV_BILLINGSERVICE_HOST
billing-service from egov-service-host
fsm-calculator service host
EGOV_FSM_CALCULATOR_HOST
fsm-calculator from egov-service-host
workflow v2 service host
WORKFLOW_CONTEXT_PATH
egov-workflow-v2 from egov-service-host
ui host, to return send the url of new application in sms notification
EGOV_UI_APP_HOST
egov-services-fqdn-name from egov-service-host
vendor service host, to get DSO details
EGOV_VENDOR_HOST
vendor from egov-service-host
Vehicle service host, to get vehicle details and manage vehicleTrip
EGOV_VEHICLE_HOST
vehicle from egov-service-host
Collection service host, to get the payment details
EGOV_COLLECTION_SERVICE_HOST
collection-services from egov-service-host
localization service host, to get the locale data
EGOV_LOCALIZATION_HOST
egov-localization from egov-service-host
user service host, to get the locale data
EGOV_USER_HOST
egov-user from egov-service-host
pdf service host, to get the locale data
EGOV_PDF_HOST
pdf-service from egov-service-host
url shortening service host, to get the short url for the long once
EGOV_URL_SHORTNER_HOST
egov-url-shortening from egov-service-host
User
Role
Description
How to create
FSM Creator
FSM_CREATOR_EMP
Can create FSM Application on behalf of Citizen
Through HRMS with role
FSM Editor
FSM_EDITOR_EMP
Can edit the application created by citizen for demand generation
Assing/ Re-Assign DSO
Complete the Application
Through HRMS with role
FSM Admin
FSM_ADMIN
Can cancel the application at any stage of workflow
Through HRMS with role
DSO
FSM_DSO
can accept/Reject the assigned Application
can complete the FSM Application
Through vendor service, use the create DSO Request from postman Collection
FSTP Operator
FSM_EMP_FSTPO
Can mark the vehicle Trip as disposed. Not FSM Service User
Through HRMS with role
Collector
FSM_COLLECTOR
Can collect the payment amount for application based on demand
Through HRMS with role
Title
Link
Workflow Technical Document
User Technical Document
MDMS Technical Document
NEEDS TO BE UPDATED
IDGen Technical Document
NEEDS TO BE UPDATED
Localization Technical Document
NEEDS TO BE UPDATED
Persister Technical Document
NEEDS TO BE UPDATED
SMS Notification Technical Document
NEEDS TO BE UPDATED
HRMS Technical Document
NEEDS TO BE UPDATED
API Contract
Postman Collection
Title
Link
/fsm/v1/_create
/fsm/v1/_update
/fsm/v1/_search
/fsm/v1/_audit
Configuration and setup details on registering vehicles in FSM module
Vehicle Registry is a system that enables ULB Employees to create and search Vehicle Entities and schedule Vehicle Trip for FSM Application and track the VehicleTrip. This document contains the details about how to set up the Vehicle and describe the functionalities provided.
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 a database is created to store FSM Application data
Following services should be up and running:
egov-perister
egov-mdms
egov-workflow-v2
egov-idgen
Deploy the latest version of the vehicle
Add vehicle-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 )
Add master data in MDMS service with the module name as Vehicle.
Following is some sample master data for
SuctionType
VehicleMakeModel
Workflow configuration for VehicleTrip of FSM
Actions
Role Action Mapping
Infra Ops Configuration
Configurations that we can manage through values.yml vehicle in infraops repo as follows values.yml for the vehicle can be found.
Description
name in values.yml
Current Value
id-gen host, to generate the application number
EGOV_IDGEN_HOST
egov-idgen from egov-service-host
mdms service host
EGOV_MDMS_HOST
egov-mdms-service from egov-service-host
workflow v2 service host
WORKFLOW_CONTEXT_PATH
egov-workflow-v2 from egov-service-host
user service host, to get the locale data
EGOV_USER_HOST
egov-user from egov-service-host
Kafka Consumer Group
SPRING_KAFKA_CONSUMER_GROUP_ID
egov-vehicle-services
kafka topic to which service push data to save new vehicle application
PERSISTER_SAVE_VEHICLE_TOPIC
save-vehicle-application
kafka topic to which service push data of the vehicleTrip to save
PERSISTER_SAVE_VEHICLE_TRIP_TOPIC
save-vehicle-trip
kafka topic to which service push data of the vehicleTrip to update
PERSISTER_UPDATE_VEHICLE_TRIP_TOPIC
update-vehicle-trip
kafka topic to which service push data of the vehicleTrip to update the status
PERSISTER_UPDATE_VEHICLE_TRIP_WORKFLOW_TOPIC
update-workflow-vehicle-trip
VehicleTrip Appilcatiion Number format`
egov.idgen.vehicle.trip.applicationNum.format
"[CITY.CODE]-VT-[cy:yyyy-MM-dd]-[SEQ_EGOV_VEHICLETRIP]"
Configurations sample in Values.yml
Create Vehicle with one of the vehicle ****types available in the VehicleMakeModel MDMS
Sample Curl
Integrated with Application through REST API to create, and search vehicles.
For any module where vehicle Trip is required, can integrate REST API trip/v1/create, update, search
Vehicle Managed would become easy
Trip Management would become easy
FSM Application can vehicle/v1/_search to validate the FSM vehicle assignment
FSM Application call vehicle/trip/v1/_create on assigning vehicle to the Application
FSTP operator can mark the vehicleTrip as DISPOSED.
Title
Link
Workflow Technical Document
User Technical Document
MDMS Technical Document
NEEDS TO BE UPDATED
IDGen Technical Document
NEEDS TO BE UPDATED
Localization Technical Document
NEEDS TO BE UPDATED
Persister Technical Document
NEEDS TO BE UPDATED
SMS Notification Technical Document
NEEDS TO BE UPDATED
API Contract
Postman Scripts
Title
Link
vehicle/v1/_create
vehicle/v1/_search
vehicle/trip/v1/_create
vehicle/trip/v1/_update
vehicle/trip/v1/_search
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
