Water Connection advance changes are added to allow the customer to pay the advance amount. This amount is adjusted when a new demand is generated. We can enable or disable advance based on the configuration.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• Kafka server is up and running

• egov-persister service is running and has the water service persister configs path added to it

• PSQL server is running and a database is created to store water connection/application data

• The following services should be up and running:

  • egov-persister

  • egov-mdms

  • ws-services

  • billing-service

  • ws-calculator

  • egov-apportion-service

Key Functionalities

• Accepts advance amount during water connection creation and while collecting payment

• Creates demand for consumer-type water connection-advance

• Adjusts the new demand with existing advance with apportion service

Deployment Details

Deploy the latest version of ws-service, ws-calculator, billing-service, egov-apportion-service

MDMS Configuration

Billing service tax head configuration

{
      "businessService": "ws-services-calculation",
      "code": "WS",
      "collectionModesNotAllowed": [
        "DD",
        "CHEQUE",
        "CARD",
        "OFFLINE_NEFT",
        "OFFLINE_RTGS",
        "POSTAL_ORDER",
        "ONLINE"
      ],
      "partPaymentAllowed": true,
      "isAdvanceAllowed": true,
      "demandUpdateTime": 86400000,
      "isVoucherCreationEnabled": false,
      "billGineiURL" : "egov-searcher/bill-genie/waterbills/_get",
      "isBillAmendmentEnabled":true
    }

Tax-head master service configuration

{
      "category": "ADVANCE_COLLECTION",
      "service": "WS",
      "name": "Ws advance carry forward",
      "code": "WS_ADVANCE_CARRYFORWARD",
      "isDebit": true,
      "isActualDemand": false,
      "order": "0",
      "isRequired": true,
      "IsBillamend": false
    },

Existing Service Code Changes

Billing Service Changes

• Creating a new bill for the advance amount in BillServiceV2. Removing the following line while adding the bill objects to the list if (billAmount.compareTo(BigDecimal.ZERO) >= 0)

• Passing Active status filter for demand search during apportioning in DemandService. DemandCriteria searchCriteria = DemandCriteria.builder().tenantId(tenantId) .status(Demand.StatusEnum.ACTIVE.toString()).consumerCode(Collections.singleton(consumerCode)). businessService(businessService).build();

• New Demand audit history API in Demandcontroller. An API that returns the audit history of demandDetails. demand/_history

Water Service Changes

• Create water connection API: Adding a check for payment type advance. If advance, passing a boolean isAdvanceCollection to calculationRequest to water calculator service.

• Update water connection API: Adding a check for payment type advance. If advance, passing a boolean isAdvanceCollection to calculationRequest to water calculator service. Adding a check for advance in validateUpdate method to set the current demand to CANCELLED.

Water Calculator Service Changes

• Calling estimation service getEstimationMap based on isAdvanceCalculation boolean. If true, reading taxAmount from criteria.getWaterConnection().getAdvance();

• Changes in getEstimatesForTax for a new taxHeadCode ADVANCE_COLLECTION with value WS_ADVANCE_CARRYFORWARD

• Getting the advance amount in getCalculation with taxHeadCode ADVANCE_COLLECTION

• Calling generateDemand method based on isAdvanceCalculation. If true, create a demand object with consumerType “waterConnection-advance“.

Water Connection Penalty changes are added to get the penalty amount after the due date. The due date is configurable and penalty enable and disable are also configurable. If we want to have the penalty we can enable or we can disable it through configuration.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• Kafka server is up and running

• egov-persister service is running and has the water service persister configs path added to it

• PSQL server is running and a database is created to store water connection/application data

• The following services should be up and running:

  • egov-persister

  • egov-mdms

  • ws-services

  • billing-service

Key Functionalities

• Calculate water charges and taxes based on the billing slab.

• Calculate meter reading charge for water connection

• Generate demand for penalty feature

• Scheduler for generating the demand(for non-metered connection)

Deployment Details

1. Deploy the latest version of ws-service and ws-calculator

2. Add water-persist.yml & water-meter.yml file in the config folder in git and add that path in persister. (The file path is to be added in the environment yaml file in a param called persist-yml-path )

Configuration Details

MDMS Configuration

Billing service tax head configuration

 {
      "category": "PENALTY",
      "service": "WS",
      "name": "Penalty",
      "code": "10201",
      "isDebit": false,
      "isActualDemand": true,
      "order": "3",
      "isRequired": false,
      "IsBillamend": true
    },
     {
      "category": "TAX",
      "service": "WS",
      "name": "Water adhoc penalty",
      "code": "WS_TIME_ADHOC_PENALTY",
      "isDebit": false,
      "isActualDemand": true,
      "order": "6",
      "isRequired": false,
      "IsBillamend": false
    },

ws-calculator penalty configuration:

Use case 1: Fixed percentage on outstanding without penalty

Use case 2: Fixed percentage on the current month

Use case 3: Fixed percentage on outstanding including penalty

Note: All the above are applied to the running month only.

Use case 4: Fixed percentage on outstanding applied for every month on the outstanding amount respectively (not implemented)

Tech configuration

Use case 1: "type": "Fixed", "subType": "outstandingWithoutPenalty"

Use case 2: "type": "Fixed", "subType": "currentMonth",

Use Case 3: "type": "Fixed", "subType": "outstanding", We have Total 4 types of penalty in the system:

Fixed - Current month: This type of penalty is applied to the current month's amount based on the rate (%) given in the configuration.

{
  "tenantId": "pb",
  "moduleName": "ws-services-calculation",
  "Penalty": [
    {
      "type": "FIXED",
      "subType": "currentMonth",
      "rate": 10,
      "amount":null,
      "minAmount": null,
      "applicableAfterDays": 10,
      "flatAmount": null,
      "fromFY": "2022-23",
      "startingDay": "1/01/2022"
    }
  ]
}

Fixed - outstanding: This is the penalty applied on the total outstanding amount including previously applied penalties based on the rate (%) given in the configuration.

{
  "tenantId": "pb",
  "moduleName": "ws-services-calculation",
  "Penalty": [
    {
      "type": "FIXED",
      "subType": "outstanding",
      "rate": 10,
      "amount":null,
      "minAmount": null,
      "applicableAfterDays": 10,
      "flatAmount": null,
      "fromFY": "2022-23",
      "startingDay": "1/01/2022"
    }
  ]
}

Fixed - outstandingWithoutPenalty: This is the penalty applied on the total outstanding amount excluding previously applied penalties based on the rate (%) given in the configuration.

{
  "tenantId": "pb",
  "moduleName": "ws-services-calculation",
  "Penalty": [
    {
      "type": "FIXED",
      "subType": "outstandingWithoutPenalty",
      "rate": 10,
      "amount":null,
      "minAmount": null,
      "applicableAfterDays": 10,
      "flatAmount": null,
      "fromFY": "2022-23",
      "startingDay": "1/01/2022"
    }
  ]

Flat - Current month: This type of penalty is applied to the current month's amount based on the amount given in the configuration.

{
  "tenantId": "pb",
  "moduleName": "ws-services-calculation",
  "Penalty": [
    {
      "type": "FLAT",
      "subType": "currentMonth",
      "rate": null,
      "amount": 15,
      "minAmount": null,
      "applicableAfterDays": 10,
      "flatAmount": null,
      "fromFY": "2022-23",
      "startingDay": "1/01/2022"
    }
  ]
}

Flat - outstanding: This type of penalty is applied to the total pending amount till the current month's amount based on the amount given in the configuration.

{
  "tenantId": "pb",
  "moduleName": "ws-services-calculation",
  "Penalty": [
    {
      "type": "FLAT",
      "subType": "outstanding",
      "rate": null,
      "amount": 15,
      "minAmount": null,
      "applicableAfterDays": 10,
      "flatAmount": null,
      "fromFY": "2022-23",
      "startingDay": "1/01/2022"
    }
  ]
}

Curl to create:

curl --location --request POST 'http://localhost:8090/ws-services/wc/_create' \
--header 'authority: mgramseva-qa.egov.org.in' \
--header 'accept: */*' \
--header 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
--header 'content-type: application/json; charset=utf-8' \
--header 'cookie: _ga_MY9HZBBBC8=GS1.1.1646915127.24.1.1646915152.0; _ga=GA1.1.1108799280.1643257024; _ga_8H6W5DYGX0=GS1.1.1655294682.124.0.1655294682.0' \
--header 'origin: https://mgramseva-qa.egov.org.in' \
--header 'referer: https://mgramseva-qa.egov.org.in/mgramseva/home/consumercreate' \
--header 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="102", "Google Chrome";v="102"' \
--header 'sec-ch-ua-mobile: ?0' \
--header 'sec-ch-ua-platform: "Linux"' \
--header 'sec-fetch-dest: empty' \
--header 'sec-fetch-mode: cors' \
--header 'sec-fetch-site: same-origin' \
--header 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36' \
--data-raw '{
    "RequestInfo": {
        "apiId": "mgramseva",
        "ver": 1,
        "ts": "",
        "action": "_create",
        "did": 1,
        "key": "",
        "msgId": "20170310130900|en_IN",
        "authToken": "cded20ed-d1f7-40ca-bd8e-978e319fdcea",
        "userInfo": {
            "id": 705,
            "uuid": "36b747f4-bd94-4be7-b0cc-e59af2ff970b",
            "userName": "8122091926",
            "name": "Vasanthi",
            "mobileNumber": "8122091926",
            "emailId": "vasanth.arun.95@gmail.com",
            "locale": null,
            "type": "EMPLOYEE",
            "roles": [
                {
                    "name": "GP Admin",
                    "code": "GP_ADMIN",
                    "tenantId": "pb.lodhipur"
                },
                {
                    "name": "Bulk Demand Processing",
                    "code": "BULK_DEMAND_PROCESSING",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Super User",
                    "code": "SUPERUSER",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Profile update",
                    "code": "PROFILE_UPDATE",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "Dashbaord Viewer",
                    "code": "DASHBOARD_VIEWER",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Expense Processing",
                    "code": "EXPENSE_PROCESSING",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Dashbaord Viewer",
                    "code": "DASHBOARD_VIEWER",
                    "tenantId": "pb.lodhipur"
                },
                {
                    "name": "Expense Processing",
                    "code": "EXPENSE_PROCESSING",
                    "tenantId": "pb.lodhipur"
                },
                {
                    "name": "GP Admin",
                    "code": "GP_ADMIN",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "GP Admin",
                    "code": "GP_ADMIN",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Profile update",
                    "code": "PROFILE_UPDATE",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "Bulk Demand Processing",
                    "code": "BULK_DEMAND_PROCESSING",
                    "tenantId": "pb.lodhipur"
                },
                {
                    "name": "Profile update",
                    "code": "PROFILE_UPDATE",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Profile update",
                    "code": "PROFILE_UPDATE",
                    "tenantId": "pb.lodhipur"
                },
                {
                    "name": "Employee",
                    "code": "EMPLOYEE",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Employee",
                    "code": "EMPLOYEE",
                    "tenantId": "pb.lodhipur"
                },
                {
                    "name": "Collection Operator",
                    "code": "COLLECTION_OPERATOR",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Employee",
                    "code": "EMPLOYEE",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "Bulk Demand Processing",
                    "code": "BULK_DEMAND_PROCESSING",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Bulk Demand Processing",
                    "code": "BULK_DEMAND_PROCESSING",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "Collection Operator",
                    "code": "COLLECTION_OPERATOR",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "Employee",
                    "code": "EMPLOYEE",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "Dashbaord Viewer",
                    "code": "DASHBOARD_VIEWER",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "Super User",
                    "code": "SUPERUSER",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Dashbaord Viewer",
                    "code": "DASHBOARD_VIEWER",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "Expense Processing",
                    "code": "EXPENSE_PROCESSING",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Expense Processing",
                    "code": "EXPENSE_PROCESSING",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "Dashbaord Viewer",
                    "code": "DASHBOARD_VIEWER",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Bulk Demand Processing",
                    "code": "BULK_DEMAND_PROCESSING",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "GP Admin",
                    "code": "GP_ADMIN",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Super User",
                    "code": "SUPERUSER",
                    "tenantId": "pb.lodhipur"
                },
                {
                    "name": "GP Admin",
                    "code": "GP_ADMIN",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "Expense Processing",
                    "code": "EXPENSE_PROCESSING",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "Collection Operator",
                    "code": "COLLECTION_OPERATOR",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "Profile update",
                    "code": "PROFILE_UPDATE",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Super User",
                    "code": "SUPERUSER",
                    "tenantId": "pb.massewal"
                },
                {
                    "name": "Employee",
                    "code": "EMPLOYEE",
                    "tenantId": "pb.dabourlower"
                },
                {
                    "name": "Super User",
                    "code": "SUPERUSER",
                    "tenantId": "pb.lalpur"
                },
                {
                    "name": "Collection Operator",
                    "code": "COLLECTION_OPERATOR",
                    "tenantId": "pb.dabourupper"
                },
                {
                    "name": "Collection Operator",
                    "code": "COLLECTION_OPERATOR",
                    "tenantId": "pb.lodhipur"
                }
            ],
            "active": true,
            "tenantId": "pb",
            "permanentCity": null
        }
    },
    "WaterConnection": {
        "id": null,
        "connectionNo": null,
        "propertyId": "PB-PT-2022-06-15-1722",
        "applicationNo": null,
        "tenantId": "pb.lodhipur",
        "action": "SUBMIT",
        "status": null,
        "meterInstallationDate": 1651343400000,
        "documents": null,
        "proposedTaps": 1,
        "noOfTaps": 1,
        "paymentType":"arrears",
        "arrears": 112,
        "penalty":50,
        "connectionType": "Metered",
        "oldConnectionNo": "",
        "meterId": "121212",
        "propertyType": "RESIDENTIAL",
        "previousReadingDate": 1651343400000,
        "previousReading": 56,
        "proposedPipeSize": 10,
        "connectionHolders": [
            {
                "id": null,
                "uuid": null,
                "userName": null,
                "password": null,
                "aadhaarNumber": null,
                "permanentAddress": null,
                "permanentCity": null,
                "permanentPinCode": null,
                "correspondenceCity": null,
                "correspondencePinCode": null,
                "correspondenceAddress": null,
                "pwdExpiryDate": null,
                "accountLocked": null,
                "active": null,
                "type": null,
                "tenantId": null,
                "altContactNumber": null,
                "ownerInfoUuid": null,
                "isPrimaryOwner": null,
                "ownerShipPercentage": null,
                "institutionId": null,
                "designation": null,
                "emailId": null,
                "isCorrespondenceAddress": null,
                "mobileNumber": "9182541372",
                "fatherOrHusbandName": "Sravan",
                "name": "Sravani",
                "status": null,
                "gender": "FEMALE",
                "ownerType": "NONE",
                "documents": null,
                "roles": null
            }
        ],
        "additionalDetails": {
            "initialMeterReading": 56,
            "meterReading": 56,
            "locality": "WARD1",
            "category": null,
            "subCategory": null,
            "aadharNumber": null,
            "propertyType": "RESIDENTIAL",
            "street": "",
            "doorNo": "",
            "collectionAmount": null,
            "collectionPendingAmount": null,
            "action": null
        },
        "processInstance": {
            "action": "SUBMIT"
        }
    }
}'

The purpose of the NalJalSeva IFIX adapter service is to push the demand, bill, and payment events to IFIX from the NalJalSeva.

Overview

NalJalSeva IFIX adapter service is a wrapper for pushing data from the NalJalSeva to IFIX. When demand or payment is generated in the NalJalSeva system, the NalJalSeva IFIX adapter service listens to those topics and it calls the IFIX reference adapter service push API to publish the data to IFIX.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• Java 8

• Kafka

• Spring boot

Key Functionalities

• Pushing demand, bill and payment events to the IFIX adapter

The following topics interact with the NalJalSeva IFIX adapter service - When we create demand for ws-services, then it sends an event as demand for IFIX. If it is expense demand, it sends the event as a bill for IFIX. If it is a ws-services payment, then it sends the event as a receipt for IFIX. If it is an expense payment, it sends the payment as an event for IFIX.

• naljalseva-create-demand

• naljalseva-update-demand

• egov.collection.payment-create

Deployment Details

Deploy the following build.

• ifix-adapter:v1.0.0-4e24064-14

Integration Details

Integration Scope

NalJalSeva IFIX adapter is integrated with the IFIX Reference adaptor service. NalJalSeva IFIX adapter Application internally invokes the IFIX Reference adaptor service to push the data.

Integration Steps

NalJalSeva IFIX adapter application triggers IFIX-reference-adapter/events/v1/_push to push the demand, bill, and payment events from NalJalSeva to IFIX.

DSS has two sides to it. One is, the process in which the Data is pooled to ElasticSearch and the other is the way it is fetched, aggregated, computed, transformed and sent across.

As this revolves around a variety of Data Sets, 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 process flow.

This document explains the steps on how to define the configurations for the Analytics Side Of DSS for NalJalSeva.

What is analytics?

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 Configurations: Analytics contains multiple configurations. we need to add the changes related to NalJalseva in this dashboard-analytics.

Dashboard analytics link - https://github.com/misdwss/config-mgramseva/tree/QA/egov-dss-dashboards/dashboard-analytics

Below is a list of configurations that need to be changed to run NalJalSeva successfully.

• Chart API Configuration

• Master Dashboard Configuration

Chart API Configuration

Each Visualization has its properties. Each Visualization comes from different data sources (Sometimes it is a combination of different data sources).

In order to configure each visualization and its 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 the configuration and are easily changeable.

Here is the sample ChartApiConfiguration.json data for the NalJalSeva.

"revenueAndExpenditureTrendTwo": {
    "chartName": "DSS_MGRAMSEVA_COLLECTIONS_DATA_TWO",
    "queries": [
      {
        "module": "WS",
        "dateRefField": "dataObject.paymentDetails.receiptDate",
        "requestQueryMap": "{\"wardId\" : \"domainObject.ward.name.keyword\",\"module\" : \"dataObject.Bill.billDetails.businessService.keyword\", \"tenantId\" : \"dataObject.tenantId\", \"district\" : \"dataObject.tenantData.cityDistrictCode\"}",
        "indexName": "dss-collection_v2",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"dataObject.tenantId.keyword\":\"pb.testing\"}},{\"terms\":{\"dataObject.paymentDetails.bill.status.keyword\":[\"Cancelled\"]}}]}},\"aggs\":{\"Water_Service\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"dataObject.paymentDetails.bill.businessService.keyword\":[\"WS\"]}}]}},\"aggs\":{\"WaterService\":{\"date_histogram\":{\"field\":\"dataObject.paymentDetails.receiptDate\",\"interval\":\"month\"},\"aggs\":{\"Count\":{\"sum\":{\"field\":\"dataObject.paymentDetails.bill.billDetails.amountPaid\"}}}}}},\"Expense_Service\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"dataObject.paymentDetails.bill.businessService.keyword\":[\"EXPENSE.SALARY\",\"EXPENSE.OM\",\"EXPENSE.ELECTRICITY_BILL\"]}}]}},\"aggs\":{\"ExpenseService\":{\"date_histogram\":{\"field\":\"dataObject.paymentDetails.receiptDate\",\"interval\":\"month\"},\"aggs\":{\"Count\":{\"sum\":{\"field\":\"dataObject.paymentDetails.bill.billDetails.amountPaid\"}}}}}}}}}}"
      }
    ],
    "chartType": "line",
    "valueType": "number",
    "action": "",
    "drillChart": "none",
    "documentType": "_doc",
    "aggregationPaths": [
      "WaterService",
      "ExpenseService"
    ],
    "isCumulative": false,
    "interval": "month",
    "insight": {},
    "_comment": " "
  },

Click here to check the complete configuration.

Master Dashboard Configuration

Master Dashboard Configuration is the main configuration that defines the Dashboards to be painted on the screen.

It includes all the Visualizations, their groups, the charts which come within them and even their dimensions as what should be their height and width.

{
      "name": "DSS_MGRAMSEVA_DASHBOARD",
      "id": "mgramseva-wc",
      "isActive": "",
      "style": "linear",
      "visualizations": [
        {
          "row": 1,
          "name": "DSS_REVENUE",
          "vizArray": [
            {
              "id": 431,
              "name": "DSS_MGRAMSEVA_WC",
              "dimensions": {
                "height": 350,
                "width": 12
              },
              "vizType": "chart",
              "label": "",
              "noUnit": true,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "revenueAndExpenditureTrendOne",
                  "name": "DSS_MGRAMSEVA_COLLECTIONS_DATA_ONE",
                  "code": "",
                  "chartType": "bar",
                  "filter": "",
                  "headers": [],
                  "tabName": "Graphical"
                },
                {
                  "id": "revenueAndExpenditureTrendTwo",
                  "name": "DSS_MGRAMSEVA_COLLECTIONS_DATA_TWO",
                  "code": "",
                  "chartType": "line",
                  "filter": "",
                  "headers": [],
                  "tabName": "Expenditure"
                }
              ]
            }
          ]
        }
      ]
    }

Click here to check the complete configuration.

Role Dashboard Mappings Configuration

Master Dashboard Configuration which was explained earlier holds the list of Dashboards that 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 complete configuration.

• Transform collection schema for V2

  • This transform collection v1 configuration file is used to map the incoming data. This mapped data will go inside the data object in the DSS collection v2 index.

Click here for an example configuration

• Here: $i, the variable value that gets incremented for the number of records of paymentDetails $j, the variable value that gets incremented for the number of records of billDetails.

• This configuration defines and directs the Enrichment Process which the data goes through.

• For example, if the incoming data belongs to a Collection Module, then the Collection Domain Config is picked. Based on the Business Type specified in the data, the right config is picked.

• To enhance the data Collection, the domain index specified in the configuration is queried with the right arguments and the response data is obtained, transformed and set.

Enrichment Domain Configuration

1. Domain configuration

2. Topic context configuration

3. transform_expense.electricity_bill_v1 configuration

4. transform_expense.om_v1 configuration

5. transform_expense.salary_v1 configuration

6. transform_ws_v1 configuration

Below is the list of configurations made changes or added newly for NalJalSeva.

 {
            "id": "4",
            "domain": "WS",
            "indexName": "water-services",
            "documentType": "",
            "query": "{\"query\":{\"bool\":{\"must\":[{\"match_phrase\":{\"Data.connectionNo\":\"value\"}}]}}}",
            "targetReferences": [
                {
                    "fieldName": "connectionNo",
                    "argument": "Data.connectionNo",
                    "dataType": "String",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "connectionNo"
                }
            ],
            "sourceReferences": [
                {
                    "fieldName": "consumerCode",
                    "argument": "Data.connectionNo",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "connectionNo"
                }
            ]
        },
        {
            "id": "5",
            "domain": "EXPENSE.SALARY",
            "indexName": "echallan-services",
            "documentType": "",
            "query": "{\"query\":{\"bool\":{\"must\":[{\"match_phrase\":{\"Data.challanNo\":\"value\"}}]}}}",
            "targetReferences": [
                {
                    "fieldName": "challanNo",
                    "argument": "Data.challanNo",
                    "dataType": "String",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "challanNo"
                }
            ],
            "sourceReferences": [
                {
                    "fieldName": "consumerCode",
                    "argument": "Data.challanNo",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "challanNo"
                }
            ]
        },
        {
            "id": "6",
            "domain": "EXPENSE.ELECTRICITY_BILL",
            "indexName": "echallan-services",
            "documentType": "",
            "query": "{\"query\":{\"bool\":{\"must\":[{\"match_phrase\":{\"Data.challanNo\":\"value\"}}]}}}",
            "targetReferences": [
                {
                    "fieldName": "challanNo",
                    "argument": "Data.challanNo",
                    "dataType": "String",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "challanNo"
                }
            ],
            "sourceReferences": [
                {
                    "fieldName": "consumerCode",
                    "argument": "Data.challanNo",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "challanNo"
                }
            ]
        },
        {
            "id": "7",
            "domain": "EXPENSE.OM",
            "indexName": "echallan-services",
            "documentType": "",
            "query": "{\"query\":{\"bool\":{\"must\":[{\"match_phrase\":{\"Data.challanNo\":\"value\"}}]}}}",
            "targetReferences": [
                {
                    "fieldName": "challanNo",
                    "argument": "Data.challanNo",
                    "dataType": "String",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "challanNo"
                }
            ],
            "sourceReferences": [
                {
                    "fieldName": "consumerCode",
                    "argument": "Data.challanNo",
                    "value": "$value",
                    "seperator": " ",
                    "expression": "challanNo"
                }
            ]
        }

Click here to see the complete configuration

Topic Context Configuration

• Topic Context Configuration is an outline to define which data is received on which Kafka Topic.

• Indexer Service and many other services are sending out data on different Kafka Topics. If the Ingest Service is asked to receive those data and pass it through the pipeline, the context and the version of the data being received has to be set. This configuration is used to identify as in which Kafka topic consumed the data and what is the mapping for that.

 "topicContextConfigurations": [
    {
      "topic": "dss-collection-update",
      "dataContext": "collection",
      "dataContextVersion": "v2"
    },
    {
      "topic": "topicTwo",
      "dataContext": "billing",
      "dataContextVersion": "v1"
    }
  ]

Click here to see the complete configuration

Based on expense and water-service business service we added transform configurations as per below.

transform_expense.electricity_bill_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_expense.electricity_bill_v1.json

transform_expense.om_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_expense.om_v1.json

transform_expense.salary_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_expense.salary_v1.json

transform_ws_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_ws_v1.json

Note: For Kafka connect to work, Ingest pipeline application properties or in environments direct push must be disabled.

• es.push.direct=false

• If DSS collection index data is indexing directly ( without Kafka connector) to ES through the ingest pipeline then, make the application properties or in environments, direct push must be enabled.

• es.push.direct=true

Creating Kafka Sync Connector - push the data to the Elasticsearch

• Configure the Kafka topics in the environments or Ingest pipeline application properties as shown below.

For details on services such as re-indexing and Kafka connection, refer to the Services Re-indexing document.

Dashboard Service Changes

Main-Monthly Dashboard

For the main monthly dashboard, we are using the service API to fetch the data and show it in the main monthly dashboard table.

Ws-services:

/ws-services/wc/_revenueCollectionData Should be added to get the main monthly dashboard details. It is used to show the table data based on the no of months for selected financial year.

eChallan-Service:

/echallan-services/eChallan/v1/_chalanCollectionData it is added to get the main monthly dashboard data for the expense.

Dashboard-Metrics:

To show the data in metrics format in a specific month dashboard we are using service API which will fetch the data based on dashboard type.

Ws-services:

/ws-services/wc/_revenueDashboard Should be added to get the revenue dashboard metrix data. It will show the data of revenue collection information

eChallan-Service:

/echallan-services/eChallan/v1/_expenseDashboard Is added in echallan-service to show the data of expenses in matrix format.

MDMS- changes for the dashboard:

Actions & Role Action Mapping

Actions:

[
 {
      "id": {{PLACEHOLDER1}},
      "name": " feedback search",
      "url": "/ws-services/wc/_revenueDashboard",
      "parentModule": "",
      "displayName": "get Revenue Dashboard Data",
      "orderNumber": 2,
      "enabled": false,
      "serviceCode": "ws-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER2}},
      "name": " feedback search",
      "url": "/ws-services/wc/_revenueCollectionData",
      "parentModule": "",
      "displayName": "get Revenue Dashboard Data",
      "orderNumber": 2,
      "enabled": false,
      "serviceCode": "ws-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER3}},
      "name": "Expense Update",
      "url": "/echallan-services/eChallan/v1/_expenseDashboard",
      "parentModule": "",
      "displayName": "get Expense Dashboard",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "echallan-services",
      "code": "null",
      "path": ""
    },
 {
      "id": {{PLACEHOLDER4}},
      "name": "Expense Update",
      "url": "/echallan-services/eChallan/v1/_chalanCollectionData",
      "parentModule": "",
      "displayName": "get Expense Dashboard",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "echallan-services",
      "code": "null",
      "path": ""
    },
      {
      "id": {{PLACEHOLDER5}},
      "name": "DSS Dashboard Charts",
      "url": "/dashboard-analytics/dashboard/getChartV2",
      "parentModule": "",
      "displayName": "DSS",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "DSS",
      "code": "null",
      "path": ""
     },
]

Role Action Mapping:

[
 
    {
      "rolecode": "GP_ADMIN",
      "actionid": {{PLACEHOLDER1}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "GP_ADMIN",
      "actionid": {{PLACEHOLDER2}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "GP_ADMIN",
      "actionid": {{PLACEHOLDER3}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "GP_ADMIN",
      "actionid": {{PLACEHOLDER4}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "GP_ADMIN",
      "actionid": {{PLACEHOLDER5}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "DASHBOARD_VIEWER",
      "actionid": {{PLACEHOLDER5}},
      "actioncode": "",
      "tenantId": "pb"
    }
]

Available Roles:

		{
      "code": "GP_ADMIN",
      "name": "GP Admin",
      "description": "Who has a access to ws-services"
    },
		{
      "code": "COLLECTION_OPERATOR",
      "name": "Collection Operator",
      "description": "Who has a access to ws-services,demand, bill and payment"
    },
		{
      "code": "BULK_DEMAND_PROCESSING",
      "name": "Bulk Demand Processing",
      "description": "Who has a access to bulk demand generation,raise bill, downloa bill and receipts"
    },
		{
      "code": "EXPENSE_PROCESSING",
      "name": "Expense Processing",
      "description": "Who has a access to create and update expenses"
    },
		{
      "code": "DASHBOARD_VIEWER",
      "name": "Dashbaord Viewer",
      "description": "Who has a access to dashboard of revenue and expenditure"
    }

Postman collection for dashboards

One of the major applications of the eGov stack is that it helps municipalities and citizens handle property tax payments and other related functions on the property such as assessments, mutation, and so on.

Pre-requisites

1. Prior knowledge of Java/J2EE

2. Prior knowledge of Spring Boot

3. Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.

4. Prior knowledge of Git

5. Prior knowledge of the demand-based systems

6. The following services should be up and running:

   • user

   • MDMS

   • Persister

   • Location

   • Localization

   • Id-Gen

   • Billing-service

   • URL-shortener

Key Functionalities

The Property Service provides multiple functionalities starting from serving as a central repository where property information is registered for reference of citizens and other municipality-provided services such as water connection and sewerage management. An assessment can be done to calculate and pay tax on the property. The different services provided by the property services are -

• Property Registry

• Assessment

• Mutation

• Bifurcation

• Consolidation

Registry Explanation

• The registry flow helps the citizen/Employee to create a property in the system with the minimal information required.

• Other workflows such as assessment or mutation can be triggered on the existing ACTIVE Property in the registry.

• The property can be created, updated, cancelled, and searched followed by the process of Mutation and Assessment.

• The same entry in the registry can be referred to by other modules for various business purposes (Water charges).

Configuration Details

Persister File Configuration

Workflow Configurations

Each flow in the property has a workflow associated with it, which can be controlled by following configurations.

The Boolean field can enable/disable Workflow - the same field controls the update and creates the workflow.

Workflow configuration for a property is created if the source is from the WATER CONNECTION module.

Use Case 1, which involves property creation from the Water and Sewerage module, necessitates a single-step workflow. In the MDMS file mentioned above, ensure that the businessService with PT.CREATEWITHWNS object is enabled, allowing the field to be set as true. Property creation from the Water and Sewerage module will feature a one-step workflow, for properties in an ACTIVE state.

Fields in the above MDMS file:

Note: Each object mentioned above represents a specific use case outlined in this ticket. Therefore, only one object (use case) enable field should be set to true at any given time.

Sample workflow config for use case 1 where property creation is from water and sewerage module with one-step workflow.

Sample workflow config - (The same PT.CREATE can be used for update workflow also since both involve the same functionality)

PT.LEGACY workflow config

Notifications:

To enable or disable notifications notif.sms.enabled=true

#notif urls - makes use of the UI app host in notification service egov.notif.commonpay = citizen/egov-common/pay?consumerCode={CONSUMERCODE}&tenantId={TENANTID} egov.notif.view.property = citizen/property-tax/my-properties/property/{PROPERTYID}/{TENANTID} egov.notif.view.mutation = citizen/pt-mutation/search-preview?applicationNumber={APPID}&tenantId={TENANTID}

The current localization messages for notification -

Configs in App.props

Integration Details

Integration Scope

Property service can be integrated with any organization or system that wants to maintain a record of the property and collect taxes with ease.

Integration Benefits

• Easy to create and simple process of self-assessment to avoid the hassle.

• Helps maintain property data which can be used in the integration of other essential services like asset management, water connection and so on.

• provides additional functionalities like mutation and assessment of properties.

Integration Steps

1. Customers can create a property using the /property/_create

2. Search the property using /property/_searchendpoint

3. /property/_update endpoint to update the property demand as needed.

4. Mutation can be carried out with the help of /property/_update itself, no extra API is required.

Reference Docs

Doc Links

API LIST

Schedulers are designed to run a particular service at a scheduled time, without triggering manually. We can have multiple schedulers for an application. It will consider the GMT format only.

How CronJob Works

The Python script reads the mdms-read-cronjob JSON from the MDMS service using a token from the CRONJOB user.

Identify the APIs set up in this MDMS using the provided script argument. The script uses the config from the MDMS to call the corresponding API.

NalJalSeva Schedulers

A total of 7 schedulers are available in the NalJalSeva:

_schedulerTodaysCollection: This scheduler will run daily to send the day collection amount to the collection employee.

_jobscheduler/true: This is to send the notification to the ULB employee when the bulk demand auto-generation is failed.

_schedulermarkexpensebill: This scheduler is used to mark the expense as paid for the paid expenses once every fortnight.

_schedulernewexpenditure: This is used to send the notification once every fortnight regarding the no of expenditures created.

_schedulermonthsummary: This is to send the monthly summary details to the ULB employee. _schedulerpendingcollection: This is to send the total pending amount details to the respective ULB employee user once every fortnight.

_jobscheduler/false: This is used to generate the bulk demand automatically once every month.

We have 7 different schedulers in NalJalSeva, running in 4 different time slots. We need to set them all to run the same Python scripts with different arguments, which you can find in the file under command -> args.

Configure the scheduler's runtime under the cron -> schedule option.

Example of failedBulkDemand scheduler:

1. The cron schedule is set to "30 3 5 * *", which triggers the job at 3:30 AM GMT on the 5th day of every month. Converting this to IST, the job runs at 9:00 AM IST on the 5th day of each month.

2. The command failedbulkdemand is used to instruct the Python script to invoke only the API configured as "failedbulkdemand" in the mdms-read-cronjob.mdms JSON file.

Configuration Details

Infraops Configuration Changes

PriorNote: In DevOps, the app name and schedule change based on the cron job file and set time. Arguments are set according to the job name in MDMS configuration.

labels: App: monthly-cronjob Group: mdms-read-cronjob <!-- Stays the same as we use the same Python script

cron: schedule: 30 3 4 * * // This depends on the time we need to run the scheduler

image: repository: api-cronjob tag: v1

command:

• python3

• cronJobAPIConfig.py

args:

• monthly // This is the job name which differs from the requirement based on the scheduler type.

env:

name: JOB_NAME

valueFrom:

fieldRef:

resources: |

requests: {}

The remaining fields will be the same for all the schedulers.

Monthly: This will run and send the notification to the ULB employee or consumer on the 4th of every month morning at 9 am as per the scheduled time.

Fortnightevening: This scheduler will run on the 1st and 15th of every month evening at 6 pm to send the respective notification to the Consumer.

Failedbulkdemand: When the bulk demand generation is failed this scheduler will run and share the message to ULB employees to generate demand manually.

Dailyevening: This scheduler will run daily and send notifications to the collection operator daily.

Check the links below

MDMS object details and configuration:

{

"jobName": "monthly", // This will change based on the job name

"active": "true", // when the "active" param is set to true, the scheduler runs automatically. The scheduler does not run when set to false.

"method": "POST",

"payload": {

"RequestInfo": "{DEFAULT_REQUESTINFO}" // this is common in all the schedulers used to send the request info.

},

"header": {

"Content-Type": "application/json" // This is a common property for all schedulers.

}

}

Create User

Need to create a user with CRONJOB as name and type as SYSTEM and ROLE as SYSTEM AND EMPLOYEE here is the sample curl to create the user.

Deployment Details

A Build ID (similar to the ID given below) is created when you build the cronjob. api-cronjob:develop-c0aa08a-2

Take the id only from this instead of a complete name like develop-c0aa08a-2. This id will be used as the id for your respective yaml files and the same will be deployed to the required environment to test the cron job.

For example:

Mdms-read-cronjob:develop-c0aa08a-2,

failedbulkdemand:develop-c0aa08a-2,

Fortnightevening:develop-c0aa08a-2,

monthly:develop-c0aa08a-2 Note: develop-c0aa08a-2 is the common build id for all the files which you are using.

Run the cronjob manually - Steps

• Delete the existing cron jobs if they already exist with the same name.

• kubectl delete cronjob mdms-read-cronjob -n mgramseva

• Deploy these builds in QA environments, which are related to cronjob schedulers

• mdms-read-cronjob:develop-c0aa08a-2, failedbulkdemand:develop-c0aa08a-2, fortnightevening:develop-c0aa08a-2,monthly:develop-c0aa08a-2

Test the cron job scheduler - Steps

• kubectl get cronjob -n mgramseva -- to check the list of cron jobs

• Create the job manually to test the messages. Below are the commands to create the jobs.

  • A message is received for the respective schedulers each time we run it.

  • We can increase the number to test again like failedbulkdemand-manually-1 next it will be failedbulkdemand-manually-2.

  • kubectl create job --from=cronjob/failedbulkdemand failedbulkdemand-manually-1 -n mgramseva

  • kubectl create job --from=cronjob/fortnightevening fortnightevening-manually-1 -n mgramseva

  • kubectl create job --from=cronjob/mdms-read-cronjob mdms-read-cronjob-manually-1 -n mgramseva

  • kubectl create job --from=cronjob/monthly monthly-manually-1 -n mgramseva

  • kubectl get job -n mgramseva -- to check the list of jobs

To check the cronjob image

kubectl describe cronjob mdms-read-cronjob -n mgramseva

To delete specific job

kubectl delete jobs mdms-read-cronjob-manually-1 -n mgramseva

User service is responsible for user data management and providing functionality to log in and log out of the DIGIT system.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• Java 8

• Kafka server is up and running

• Encryption and MDMS services are running

• PSQL server is running and the database

• Redis is running

Key Functionalities

• Store, update and search user data

• Provide authentication

• Provide login and logout functionality to the NalJalSeva platform

• Store user data PIIs in encrypted form

Interaction Diagram

Deployment Details

1. Setup latest version of egov-enc-service and egov-mdms- service

2. Deploy the latest version of the egov-user service

3. Add Role-Action mapping for APIs

Configuration Details

The following properties in the application.properties file in user service are configurable.

Integration Details

Integration Scope

User data management and functionality to log in and log out into the DIGIT system using OTP and password.

Integration Benefits

Providing the following functionality to citizen and employee-type users

• Employee:

  • User registration

  • Search user

  • Update user details

  • Forgot password

  • Change password

  • User role mapping (Single ULB to multiple roles)

  • Enable employees to login into the DIGIT system based on the password.

• Citizen:

  • Create user

  • Update user

  • Search user

  • User registration using OTP

  • OTP based login

Integration Steps

• To integrate, the host of egov-user should be overwritten in the helm chart.

• Use /citizen/_create endpoint for creating users into the system. This endpoint requires the user to validate his mobile Number using OTP. The first OTP will be sent to his mobile number and then that OTP will be sent as otpReference in the request body

• Use /v1/_search and /_search endpoints to search users in the system depending on various search parameters

• Use /profile/_update for updating the user profile. The user will be validated (either by OTP-based validation or password validation) when this API is called

• /users/_createnovalidate and /users/_updatenovalidate are endpoints to create user data into the system without any validations (no OTP or password required). They should be strictly used only for creating/updating users internally and should not be exposed outside

• Forgot password: In case the user forgets the password it can be reset by first calling /user-otp/v1/_send which will generate and send OTP on the employee’s mobile number, the password can then be updated using this OTP by calling the API /password/nologin/_update in which a new password along with the OTP has to be sent.

• Use /password/_update to update the existing password by logging in. In the request body, both old and new password has to be sent. Details of the API can be found in the attached Swagger documentation

• Use /user/oauth/token for generating tokens, /_logoutfor logout and /_details for getting user information from his token

• Multi-Tenant User: The multi-tenant user functionality allows a user to perform actions across multiple ULBs. For example, an employee belonging to Amritsar can perform the role of Trade License Approver for Jalandhar by assigning a tenant-level role of tenantId pb.jalandhar to him. Following is an example of such a user:

If an employee has a role with a state-level tenantId he can perform actions corresponding to that role across all tenants

• Refresh Token: Whenever the /user/oauth/token is called to generate the access_token , along with the access_token one more token is generated called refresh_token . The refresh token is used to generate new access_token whenever the existing one expires. Till the time the refresh token is valid the user won’t have to log in even if his access_token get’s expired, as it will be generated using refresh_token. The validity time of the refresh token is configurable and can be configured using the property: refresh.token.validity.in.minutes

Reference Docs

(Note: All the APIs are in the same Postman collection therefore the same link is added in each row)

eGov-User-Events service provides a common point to manage all the events generated for the user in the system. Events include updates from multiple applications like PT, PGR, TL etc, events created by the employee addressing the citizen etc. This service provides APIs to create, update and search such events for the user.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• The Kafka server is up and running

• egov-persister service is running and has egov-user-events persister config path added to it

• PSQL server is running and the database is created

Key Functionalities

• Provide a common platform to create, manage and notify events.

• Events can be created either through an API call or by pushing records to the Kafka queue.

Deployment Details

1. Add mdms configs required for egov-user-events.

2. Add Role-Action mapping for API’s.

3. Deploy the latest version of egov-user-events

4. Add egov-user-events file in config folder in git and add that path in persister. (The file path is to be added in environment yaml file in a param called persist-yml-path )

Configuration Details

Add master data in the MDMS service with the module name as mseva. Following is some sample master data for the service:

Event Categories

Event Types:

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

Copy

Configurable Properties

Following are the properties in the application.properties file in the egov-user-events service which is configurable.

Entities:

Events: Model to capture the events information. This object captures all the details of an event which is either being created or updated.

EventDetails: Captures details of the event such as organiser, location, time etc are captured here. This is the child object to the Events object. This has significance only because the type of the event is ‘EVENTSONGROUND’.

Action: This captures the user actions involved in the event. Say the pay now option, reopen option, download certificate option etc.

Recipient: Every event is addressed to a crowd to which a notification of the same is sent. This model captures information about the recipients of the notification of this event or can also be framed as details of the address of the event.

Event Type: Events are divided into multiple types as follows:

1. BROADCAST - These are messages broadcasted addressing a group of people. For instance, “There’s road blockage near the bus stand, please use a different route”

2. EVENTSONGROUND - These are events organised by a group of people addressing another group of people usually it is the ULB organising events for the citizens. It can be any activity like a 10K Marathon, Polio Drive, Property Tax collection drive etc.

3. SYSTEMGENERATED - These events are generated by different systems on the egov platform like PT, TL, PGR etc addressing a group of people. For instance, “Dear Citizen, Your TL has been approved please proceed to Pay here <PAY_NOW>”

4. OTHERS - Events that don’t belong to the types mentioned above.

These are configured in MDMS.

Event Category: Events are categorised into the following:

1. PUBLICHEALTH - Events related to public health.

2. CULTURAL - Cultural events

3. WARDCOMMITEEMEETING - Events for recurring meetings of the ward committee.

These event categories are mapped to event types internally. The categories mentioned here are for EVENTSONGROUND type. These are configured in MDMS.

How does it work?

This service manages user events on the egov-platform, which means all the events about which the user (essentially citizen) has to be notified are stored and retrieved through this service. Events can be created either by an API call or by pushing records to the Kafka queue.

Once the event is sent for creation, the service validates all the required fields and assigns a recipient list to that event. An event can be addressed to a particular person, group of people, user type and also roles. Events like updates on the TL application are addressed to the owner of the TL only, Events like Polio Drive are addressed to the entire ULB, and Events like mass Bill generation are addressed only to those who are required to pay those bills. Similarly, a recipient list is generated based on the request and stored in the system.

When an event is updated a counter event is generated, Counter events are of 2 types: Counter event on Delete and Counter event on Update. When an event in ACTIVE status is made INACTIVE or CANCELLED, a counter-event on delete is generated. When details of an event are updated irrespective of the status a counter event on update is generated. These counter-events are stored along with the actual event in the system. However, when a counter-event on delete is generated, its corresponding actual event is marked INACTIVE.

One of the important aspects of this service is the search API. Searching for the events stored in the user-events system is different for different roles. When CITIZEN searches, all the events addressed to that citizen are retrieved, the events that contain corresponding counter-events are deduplicated and only the latest ACTIVE events are returned.

We have a use-case where past events have to be marked INACTIVE, this applies to all the BROADCAST and EVENTSONGROUND types of events which are time-capped. If a BROADCAST event is active from 1/Jan to 10/Jan, it’ll be marked inactive post 10/Jan, after which the CITIZEN stops receiving any updates to that event. This changing of the status of the events is achieved by a lazy-update technique instead of a cron job. Due to this, the search API not only returns the events but also updates the status of events before returning them to the user based on whether it has expired.

When an EMPLOYEE searches, all the EVENTSONGROUND posted in his particular ULB are returned by default irrespective of the status. He/She can perform actions on those events, which if active, are notified to the CITIZEN.

An EMPLOYEE can search event based on the date the range, whatever the event created or last modified in that range, will appear in the search response. So, to get the details about an event in a particular date range pass the value in the fromDate and toDate fields of search criteria.

fromDate and toDate fields accept epoch values only.

And to get details about the Delete event, pass Status as CANCELLED and to get details about the Broadcast event pass eventType as BROADCAST.

Review the code and descriptions of every method to understand the use cases and flow of logic in a better way.

Integration Details

Integration Scope

eGov-user-events can be integrated with any organisation or system which wants to send the events generated for the user in the system

Integration Benefits

• Easy manages user events on the system, which means all the events about which the user (essentially citizen) has to be notified are stored and retrieved through this service.

Integration Steps

1. An employee can create events in the system using /egov-user-event/v1/events/_create endpoint

2. Employees can update events in the system using /egov-user-event/v1/events/_update endpoint

3. Events are searched in the system using /egov-user-event/v1/events/_search endpoint

4. /egov-user-event/v1/events/notifications/_count API is used to fetch the count of total, unread, and read notifications.

5. /egov-user-event/v1/events/lat/_update API is use to update the last-login-time of the user. We store the last login time of the user through this API thereby deciding which notifications have been read.

Reference Docs

Doc Links

API List

(Note: All the APIs are in the same Postman collection therefore same link is added in each row).

User OTP service is used to generate OTP for user login, user registration and user password change.

Pre-requisites

• Prior Knowledge of Java/J2EE.

• Prior Knowledge of Spring Boot.

• Prior Knowledge of KAFKA

• Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.

• The following services should be up and running:

  • user

  • MDMS

  • Id-Gen

  • URL-Shortening

  • notification-sms

Key Functionalities

• The user-otp service validates the user details and request type and sends OTP for a particular action.

Deployment Details

• Deploy the latest image of the user-otp service available.

Configuration Details

Integration Details

Integration Scope

User OTP service can be integrated with any organization or system that wants OTP-based validation for user login and registration.

Integration Benefits

• Easy to create and simple process of generating bills from demands.

• Easy to generate OTPs to validate mobile numbers for registration, login and password reset with simple API calls

Integration Steps

OTP can be generated by calling /user-otp/v1/_send

Vendor Registry is a system that enables ULB employees to create and search vendors i.e. Desludging Operator (DSO) and driver entities with appropriate vehicle Entities for FSM Applications. This document contains details on how to set up the Vendor and describes the functionalities provided.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• Java 8

• The Kafka server is up and running

• egov-persister service is running and has a vendor-persister config path added to it

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

• The following services should be up and running:

  • egov-mdms-service

  • egov-user-service

  • boundary-service

  • vehicle

Key Functionalities

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.

Deployment Details

1. Deploy the latest version of the vendor

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

Configuration Details

Actions & Role Action Mapping

After adding Actions and role-action mappings, restart the egov-mdms-service.

Actions

Role Action Mapping

Infra Ops Configuration

Configurations we can manage through values.yml of the vendor in the infra ops repo are as follows: values.yml for a vehicle can be found.

Configurations sample in Values.yml

Data Setup

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

Integration Details

Integration Scope

Any system or DIGIT module can integrated with Vendor Service, which helps to manage the Vendor with the vehicles, drivers and owner for the representative and login for the representative/owner to log 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

Integration Steps

• FSM to call vendor/v1/_search to fetch the DSOs

• FSM can call vendor/v1/_search to fetch the DSOs and the respective vehicles and drivers

Reference Docs

API List

We use re-indexing to transfer all data to the appropriate indexer. This process involves two steps:

1. Run the connector from the playground.

2. Call the legacy indexer service, which internally queries the plain search service to retrieve data and send it to the appropriate indexer.

Pre-requisites

• Access to kubectl of the environment targeted

• Plain search APIs in the respective services

NalJalSeva uses 3 main indexes for re-indexing:

• Water-services

• e-challan-services

• dss-collection_v2

Re-indexing Steps

• ws-services re-indexing - Kafka Connector Curl to be run from playground pod

Plain Search Call

EChallan-Reindexing

Kafka Connector Call to be run from Playground pod:

Legacy Index call from postman:

• Dss collection v2 re-indexing - Kafka Connector call to be run from playground pod

payment re-indexing run from postman call

Apportion service is used to apportion the amount paid against a bill among the different tax heads based on the implemented algorithm. The default algorithm uses the order of the tax head to apportion, the tax head with the lowest order is apportioned off first while the highest-order tax head is apportioned last.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• The Kafka server is up and running

• egov-persister service is running and has an apportioned persister configuration path added to it

• PSQL server is running and a database is created to store apportion audit data

Key Functionalities

• Apportion payment in tax heads of bill

• Apportion advance amount in tax heads of demand during demand creation

Deployment Details

1. Deploy the latest version of the egov-apportion-service service

2. Add apportion persister yaml path in persister configuration

Configuration Details

There is no separate configuration required. The TaxHead master that is configured in the billing service is only used

Integration Details

Integration Scope

Any payment service which wants to divide the paid amount into different tax head buckets can integrate with the apportion service.

Integration Benefits

• Apportions amount in tax heads

Integration Steps

1. To integrate, the host of egov-apportion-service should be overwritten in the helm chart

2. /apportion-service/v2/bill/_apportion should be called to apportion the bill

3. /apportion-service/v2/demand/_apportion should be called to apportion advance amount in demands

Reference Docs

Doc Links

API List

(Note: All the APIs are in the same Postman collection therefore the same link is added in each row)

Events push is used to manually push data from the NalJalSeva Adapter to the iFIX Adapter. Make sure the existing events are cleared or deleted to ensure reliable data transfer. Refer to the documentation here to find details on how to clean up the event data - . Post events clean up the system loads the project code for all the tenants. Then it pushes the data to the iFIX adapter.

Pre-requisites

• Access to Kubectl of the environment targetted

• Postman scripts

The Postman script fetches the data from the existing NalJalSeva database and passes it to the NalJalSeva adapter, from where it is pushed to the iFIX adapter.

Payments Curl

Pass the offset and limits based on the total transactions present in the database.

Here, TenantId is mandatory. Limit and offset can vary based on the requirement. Business service is not required.

This fetches all payment records irrespective of tenant based on the limit and offset. The data is passed to the IFIX adapter one after the other.

Demand / Bill Curl

The above curl fetches the demands based on the tenant ID and business service passed. Business service can be ‘WS' or ‘EXPENSE.SALARY’ or 'EXPENSE.MISC’ or 'EXPENSE.OM’ etc. For WS it is saved as demand and for EXPENSE it is saved as bill.