Water Service - Technical Document

Water Services:

This is the egov application, which helps and gives flexibility to municipal and citizen to handle the water service like apply for water connection, search water connection. The application will go on different stages that state can verify by given roles, If that role can take the action then the application will go to the next state. Based on the state, citizen will get notification (SMS and in-app ). Citizens also can pay for application fees or employees can collect the fee for the application.

The setup of the Application is as follows

Requirements:

  • Knowledge of Java/J2EE(preferably Java 8 version)

  • Knowledge of Spring Boot and spring-boot microservices.

  • Knowledge of Git or any version control system.

  • Knowledge of RESTful Web services.

  • Knowledge of the Lombok library will helpful.

  • knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-sms, eGov-email,eGov-user, eGov-localization, eGov-workflow-service will be helpful.

Functionality:

  1. Apply for water connection.

  2. Searching for water connections.

  3. Apply for Property creation.

  4. Can take different action based on state (Workflow)

  5. Notification based on the application state.

Setup and usage:

The Application is present among the municipal services group of applications available in the eGov-services git repository.  The spring boot application needs the Lombok* extension added in your IDE to load it. Once the application is up and running API requests can be posted to the URL and ids can be generated. 

  • in case of IntelliJ, the plugin can be installed directly, for eclipse the Lombok jar location has to be added in eclipse.ini file in this format  javaagent:lombok.jar

API Information :

Application.properties File Information:

kafka topics persister configs for eGov persister

  • egov.waterservice.createwaterconnection = save-ws-connection

  • egov.waterservice.updatewaterconnection=update-ws-connection

  • egov.waterservice.updatewaterconnection.workflow.topic=update-ws-workflow

URLs for the external API references:

egov.idgen.wcapid.name=waterservice.application.id
egov.idgen.wcapid.format=WS_AP/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]

Configuration:

Mdms configuration:

https://github.com/egovernments/egov-mdms-data/tree/master/data

ws-services-calculation ws-services-masters PropertyTax

master-config.json for water service

"ws-services-masters": { "connectionCategory": { "masterName": "connectionCategory", "isStateLevel": true, "uniqueKeys": [ "$.code" ] }, "connectionType": { "masterName": "connectionType", "isStateLevel": true, "uniqueKeys": [ "$.code" ] }, "waterSource": { "masterName": "waterSource", "isStateLevel": true, "uniqueKeys": [ "$.code" ] }, "billingPeriod": { "masterName": "billingPeriod", "isStateLevel": true, "uniqueKeys": [ "$.billingCycle" ] }, "waterSourceWithSubSource": { "masterName": "waterSourceWithSubSource", "isStateLevel": true, "uniqueKeys": [] } }, "ws-services-calculation": { "WaterCess": { "masterName": "WaterCess", "isStateLevel": true, "uniqueKeys": [] }, "Interest": { "masterName": "Interest", "isStateLevel": true, "uniqueKeys": [ "$.fromFY" ] }, "Rebate": { "masterName": "Rebate", "isStateLevel": true, "uniqueKeys": [ "$.fromFY" ] }, "Penalty": { "masterName": "Penalty", "isStateLevel": true, "uniqueKeys": [ "$.fromFY" ] }, "WCBillingSlab": { "masterName": "WCBillingSlab", "isStateLevel": true, "uniqueKeys": [] }, "WS_CHARGE": { "masterName": "WS_CHARGE", "isStateLevel": true, "uniqueKeys": [] }, "WS_TIME_PENALTY": { "masterName": "WS_TIME_PENALTY", "isStateLevel": true, "uniqueKeys": [] }, "WS_WATER_CESS": { "masterName": "WS_WATER_CESS", "isStateLevel": true, "uniqueKeys": [] }, "MeterStatus": { "masterName": "MeterStatus", "isStateLevel": true, "uniqueKeys": [] }, "WS_Round_Off": { "masterName": "WS_Round_Off", "isStateLevel": true, "uniqueKeys": [] }, "PlotSizeSlab": { "masterName": "PlotSizeSlab", "isStateLevel": true, "uniqueKeys": [] }, "PropertyUsageType": { "masterName": "PropertyUsageType", "isStateLevel": true, "uniqueKeys": [] }, "FeeSlab": { "masterName": "FeeSlab", "isStateLevel": true, "uniqueKeys": [] }, "RoadType": { "masterName": "RoadType", "isStateLevel": true, "uniqueKeys": [] }, "CalculationAttribute": { "masterName": "CalculationAttribute", "isStateLevel": true, "uniqueKeys": [] } }

 

Property creation through WNS module
https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/PTWorkflow.json

Persister configuration:

water-persist.yml
https://github.com/egovernments/configs/blob/master/egov-persister/water-meter.yml

Postman link:

https://www.getpostman.com/collections/b5b7248d1aeacc9431cb

Workflow business service config:

{ "RequestInfo": { "apiId": "Rainmaker", "action": "", "did": 1, "key": "", "msgId": "20170310130900|en_IN", "requesterId": "", "ts": 1513579888683, "ver": ".01", "authToken": "{{Auth_Token}}" }, "BusinessServices": [ { "tenantId": "pb", "businessService": "NewWS1", "business": "ws-services", "businessServiceSla": 259200000, "states": [ { "sla": null, "state": null, "applicationStatus": null, "docUploadRequired": false, "isStartState": true, "isTerminateState": false, "isStateUpdatable": false, "actions": [ { "action": "INITIATE", "nextState": "INITIATED", "roles": [ "CITIZEN", "WS_CEMP" ] } ] }, { "sla": null, "state": "INITIATED", "applicationStatus": "INITIATED", "docUploadRequired": false, "isStartState": false, "isTerminateState": false, "isStateUpdatable": true, "actions": [ { "action": "SUBMIT_APPLICATION", "nextState": "PENDING_FOR_DOCUMENT_VERIFICATION", "roles": [ "CITIZEN", "WS_CEMP" ] } ] }, { "sla": null, "state": "PENDING_FOR_CITIZEN_ACTION", "applicationStatus": "PENDING_FOR_CITIZEN_ACTION", "docUploadRequired": false, "isStartState": false, "isTerminateState": false, "isStateUpdatable": true, "actions": [ { "action": "RESUBMIT_APPLICATION", "nextState": "PENDING_FOR_DOCUMENT_VERIFICATION", "roles": [ "CITIZEN", "WS_CEMP" ] } ] }, { "sla": null, "state": "PENDING_FOR_DOCUMENT_VERIFICATION", "applicationStatus": "PENDING_FOR_DOCUMENT_VERIFICATION", "docUploadRequired": false, "isStartState": false, "isTerminateState": false, "isStateUpdatable": true, "actions": [ { "action": "VERIFY_AND_FORWARD", "nextState": "PENDING_FOR_FIELD_INSPECTION", "roles": [ "WS_DOC_VERIFIER" ] }, { "action": "REJECT", "nextState": "REJECTED", "roles": [ "WS_DOC_VERIFIER" ] }, { "action": "SEND_BACK_TO_CITIZEN", "nextState": "PENDING_FOR_CITIZEN_ACTION", "roles": [ "WS_DOC_VERIFIER" ] } ] }, { "sla": null, "state": "REJECTED", "applicationStatus": "REJECTED", "isStateUpdatable": false, "docUploadRequired": false, "isStartState": false, "isTerminateState": true }, { "sla": 86400000, "state": "PENDING_FOR_FIELD_INSPECTION", "applicationStatus": "PENDING_FOR_FIELD_INSPECTION", "docUploadRequired": false, "isStartState": false, "isStateUpdatable": true, "isTerminateState": false, "actions": [ { "action": "VERIFY_AND_FORWARD", "nextState": "PENDING_APPROVAL_FOR_CONNECTION", "roles": [ "WS_FIELD_INSPECTOR" ] }, { "action": "REJECT", "nextState": "REJECTED", "roles": [ "WS_FIELD_INSPECTOR" ] }, { "action": "SEND_BACK_FOR_DOCUMENT_VERIFICATION", "nextState": "PENDING_FOR_DOCUMENT_VERIFICATION", "roles": [ "WS_FIELD_INSPECTOR" ] } ] }, { "sla": 43200000, "state": "PENDING_APPROVAL_FOR_CONNECTION", "applicationStatus": "PENDING_APPROVAL_FOR_CONNECTION", "docUploadRequired": false, "isStartState": false, "isStateUpdatable": true, "isTerminateState": false, "actions": [ { "action": "APPROVE_FOR_CONNECTION", "nextState": "PENDING_FOR_PAYMENT", "roles": [ "WS_APPROVER" ] }, { "action": "REJECT", "nextState": "REJECTED", "roles": [ "WS_APPROVER" ] }, { "action": "SEND_BACK_FOR_FIELD_INSPECTION", "nextState": "PENDING_FOR_FIELD_INSPECTION", "roles": [ "WS_APPROVER" ] } ] }, { "sla": 43200000, "state": "PENDING_FOR_PAYMENT", "applicationStatus": "PENDING_FOR_PAYMENT", "docUploadRequired": false, "isStartState": false, "isTerminateState": false, "isStateUpdatable": false, "actions": [ { "action": "PAY", "nextState": "PENDING_FOR_CONNECTION_ACTIVATION", "roles": [ "CITIZEN", "WS_CEMP" ] } ] }, { "sla": null, "state": "PENDING_FOR_CONNECTION_ACTIVATION", "applicationStatus": "PENDING_FOR_CONNECTION_ACTIVATION", "isStateUpdatable": true, "docUploadRequired": false, "isStartState": false, "isTerminateState": false, "actions": [ { "action": "ACTIVATE_CONNECTION", "nextState": "CONNECTION_ACTIVATED", "roles": [ "WS_CLERK" ] } ] }, { "sla": null, "state": "CONNECTION_ACTIVATED", "applicationStatus": "CONNECTION_ACTIVATED", "isStateUpdatable": false, "docUploadRequired": false, "isStartState": false, "isTerminateState": true } ] } ] }

 

Workflow for property creation through Water and Sewerage Module

Indexer config for water-service:

  • The indexer provides the facility for indexing the data to elastic search.

Setup:

  1. Write the configuration for water service. The structure of the config file is explained later in the same doc.

  2. Provide the absolute path of the checked-in file to DevOps, to add it to the file-read path of egov-indexer. The file will be added to the egov-indexer's environment manifest file for it to be read at the start-up of the application.

  3. Put indexer config file to the config repo under egov-indexer folder.(https://github.com/egovernments/configs/tree/master )

  4. Run the egov-indexer app, Since it is a consumer, it starts listening to the configured topics and indexes the data.

 

config Keys:

The indexer uses a config file per module to store all the configurations pertaining to that module. Indexer reads multiple such files at start-up to support indexing for all the configured modules. The water service file contains the following keys:

a. serviceName: Name of the module to which this configuration belongs.

b. summary: Summary of the module.

c. version: The version of the configuration.

d. mappings: List of definitions within the module. Every definition corresponds to one index requirement. Which means, every object received onto the Kafka queue can be used to create multiple indexes, each of these indexes will need configuration, all such configurations belonging to one topic forms one entry in the mappings list. The keys listed henceforth together form one definition and multiple such definitions are part of this mappings key.

i. topic: Topic on which the data is to be received to activate this particular configuration.

ii. configKey: Key to identify to what type of job is this config for. values: INDEX, REINDEX, LEGACYINDEX. INDEX: LiveIndex, REINDEX: Reindex, LEGACYINDEX: LegacyIndex.

iii. indexes: Key to configure multiple index configurations for the data received on the particular topic. Multiple indexes based on different requirement can be created using the same object. This list of such configurations is a part of this key. uses the following keys:

1. name: Index name on the elasticsearch. (Index will be created if it doesn't exist with this name.)

2. type: Document type within that index to which the index json has to go. (Elasticsearch uses the structure of index/type/docId to locate any file within index/type with id = docId)

3. id: Takes comma separated JsonPaths. The JSONPath is applied on the record received on the queue, the values hence obtained are appended and used as id for the record.

4. jsonPath: Key to be used in case of indexing a part of the input JSON and in case of indexing a custom json where the values for custom json are to be fetched from this part of the input.

5. timeStampField: JSONPath of the field in the input which can be used to obtain the timestamp of the input.

6. i) indexMapping: A skeleton/mapping of the JSON that is to be indexed. Note that, this JSON must always contain a key called "Data" at the top-level and the custom mapping begins within this key. This is only a convention to smoothen dashboarding on Kibana when data from multiple indexes have to be fetched for a single dashboard.

      iv) fieldMapping: Contains a list of configurations. Each configuration contains keys to identify the field of the input JSON that has to be mapped to the fields of the index json which is mentioned in the key 'indexMapping' in the config. Has the following keys:

  1. inJsonPath: JSONPath of the field from the input.

  2. outJsonPath: JSONPath of the field of the index json.

        v) externalUriMapping: Contains a list of configurations. Each configuration contains keys to identify the field of the input JSON that are to be enriched using APIs from the external services. The confiugration for those APIs also is a part of this. Uses the following keys:

  1. path: URI of the API to be used. (it should be POST/_search API.)

  2. queryParam: Configruation of the query params to be used for the API call. It is a comma seperated key-value pair, where key is the parameter name as per the API contract and value is the JSONPath of the field to be equated against this paramter.

  3. apiRequest: Request Body of the API. (Since we only use _search APIs, it should be only RequestInfo.)

  4. uriResponseMapping: Contains a list of configuration. Each configuration contains two keys: One is a JSONPath to identify the field from response, Second is also a JSONPath to map the response field to a field of the index json mentioned in the key 'indexMapping'.

i) inJsonPath: JSONPath to identify the field from response

ii) outJsonPath: JSONPath to map the response field to a field of the index json

water-service indexer config:

meter reading indexer config:

table UML diagram:

Modify connection:

After connection activation or legacy connection, we can edit the connection. This process based on defined workflow. Any action is based on defined roles on the action level. For edit connection, we need to upload some supporting documents and mandatory info.

Workflow config for edit connection:

Notification :

Notification will be sent to the property owners and connection holders based on different application states.

Capturing connection holders :

We can add connection holders to the water connection which will be the owner of the connection. We can fill the connection holders' details or we can just make the property owner to the connection holder.

The connection holder will get notification based on a different state of the application. We are pushing the data of the connection holders in the user service too.

Multiple Road Type Support
We can add road cutting details of multiple roads to the water connection. For each road which goes under cutting process we have to fill their road type details and road cutting area.
Based on this information, application one time fee estimate is calculated.

Water Calculator Service - Technical Document

This application is used for creating meter reading, searching meter reading, updating existing meter reading, calculation of water charge, demand generation, SMS & email notification to ULB officials on-demand generation and estimation of water charge(one-time cost) which involves cost like road-cutting charge, form fee, scrutiny fee, etc.

Billing Slabs:

Criteria :

  1. connection type

  2. building type

  3. calculation attribute

  4. property usage type

The combination of the above can be used to define the billing slab. Billing Slab is defined in mdms under ws-services-calculation folder with the WCBillingSlab. The following is the sample slab.

 

If all criteria will match for that water connection this slab will use for calculation.

Estimation:

For application one-time fee, the estimation will return all the related tax head based on criteria. For estimation, all configuration is present in ws-services-calculation.

  1. FeeSlab.json

  2. PlotSizeSlab.json

  3. RoadType.json

All the above master configuration is used for estimation.

Following are the exemptions and taxes that are calculated:

  • Form fee

  • Scrutiny fee

  • Meter charge (For metered connection)

  • Other charges

  • Road cutting charges

  • One time fee

  • Security charges

  • Tax and cess

Water Charge and Tax:

Water charge is based on billing slab, for water application charge will be based on slab and tax based on master configuration.

Interest:

Below is a sample of master data JSON for interest :

Penalty:

Below is a sample of master data JSON for penalty :

Round Off:

If the fraction is greater than equal to 0.5 the number is round up else it’s round down. eg: 100.4 will be rounded to 100 while 100.6 will be rounded to 101.

Adding Adhoc penalty or rebate:

The only employee can apply for a penalty or rebate for an existing connection. As an employee, I can update or add the penalty and rebate of a connection. This applied penalty or rebate will be added or updated in existing demand as tax heads. For configuration, we have to add the tax head in TaxHeadMaster.json file.

 

Demand Generation:

Once water is sent to calculator it’s tax estimates are calculated. Using this tax head estimates demand details are created. For every tax head, estimate demand generates function will create a corresponding demand detail.

Whenever _calculate API is called demand is first searched based on the connection no or application no and the demand from and to period. If demand already exists the same demand is updated else new demand is generated with consumer code as connection no or application no and demand from and to a period equal to financial year start and end period.

In case of the update if the tax head estimates change, the difference in amount for that tax head is added as new demand detail. For example, if the initial demand has one demand detail with WATER_CHARGE equal to 120

After updating if the WATER_CHARGE increases to 150 we add one more demand detail to account for the increased amount. The demand detail will be updated to:

RoundOff is bill based i.e every time bill is generated round off is adjusted so that payable amount is the whole number. Individual WS_ROUNDOFF in demand detail can be greater than 0.5 but the sum of all WS_ROUNDOFF will always be less than 0.5.

Frontend:

Configurations:

ws-services-masters MDMS folder:

https://github.com/egovernments/egov-mdms-data/tree/master/data/pb/ws-services-masters

Documents.json

Used to display the order of the files in the Documents section which needs to be uploaded from the Citizen or Employee while creating the Water Service application.

WaterSource.json - Provides details of the different types of water source and their sub types.

ws-services-calculation MDMS folder:

https://github.com/egovernments/egov-mdms-data/tree/master/data/pb/ws-services-calculation

Pipesize.json - Provides the details of the pipe sizes.

Roadtype.json - Provides the details of the different types of the Roads and their cutting charges.

PDF Configurations:

The UI and the PDFService retrieves the Data and Format configurations from the following path:

https://github.com/egovernments/configs/tree/master/pdf-service

 

Citizen UI Guide:

List of features available in the W&S service for Citizen role.

a)Search Bills & Pay:

Citizen, by using different search criteria to find the particular connection and also he/she can able to pay the water and sewerage bill for the particular connection.