Release Summary

mGramSeva 1.2 release features enhancements with a few functional changes and non-functional changes.

• Create and update consumers with the option to pay penalty and advance

• Allow users to collect advance payment

• Penalty amount addition if the due amount is not paid before the due date

• Addition of father/husband column in household register

• Receipt and bill PDF changes based on advance and penalty amount and localization fixes

• Dashboard data and trend graph data mismatch fixes

• Non-functional: After flutter upgradation, APK was not working in Android > 12 fixes

New ‌Feature Additions/Enhancements

Road Map

The below enhancements in reports and dashboard are addressed for tracking/viewing Advance and Penalty details

• PFM-1729 Enhancements in Household Register to display Active/Inactive status, Advance, last demand and to enable sorting

• PFM-1739 Changes in the Monthly collection dashboard to display the Advance adjustment, Advance/Penalty collection and pending penalty

• PFM-1740 Changes in the Main dashboard to display the Advance adjustment, Advance/Penalty collection and pending penalty

• PFM-1741 Rollout dashboard changes for including Advance penalty details

Other Enhancements

• PFM-1728 The old connection ID is to be made mandatory and unique in create/update consumer screen

• PFM-1730 Create a new card in the login to display the GPWSC details and the rate info.

Success Metrics

Primary KPI for overall mGramSeva - mGramseva Adoption KPI

Additional: % of consumers paying and GPWSC collecting advance % of the advance amount of revenue collected month on month Outcomes: * Increased revenue * Timely payments

Known Issues

PFM-1699 - Reactivating the consumer and checking if it is allowing to generate the demand for previous month PFM-1761 - HH Register PDF | Consumer name in Hindi should be fetched in Hindi even if language selected is English. PFM-1671 - Bill and Receipt localization issue not displayed properly for tenant and month name

Document Resources & Links

Package Used

package_info_plus: ^1.3.0

The build number of the application is compared every time we hit the URL. If the build number is not present in the local storage or the build number does not match the existing build number then the local storage cache is deleted.

Build number

1.2.0+17 

Here, 17 is the build number.

If we add new localizations after deploying the build, we need to increment the build version and deploy a new build to reflect those localizations. The previous web cache validates the build number check and does not delete the localization messages stored in the local storage.

Click here to download the test cases.

MDMS Changes

Config Changes

Migration Changes

Create IFIX COA code for WS_TIME_PENALTY, 10201 & WS_ADVANCE_CARRYFORWARD , and run the following insert queries by replacing id & ifixcoacode.

• insert into ifix_adapter_coa_map(id,clientcode,ifixcoacode,ifixid,tenantid) values(,'WS_TIME_PENALTY','0215-01-104-00-00-00',,'pb');

• insert into ifix_adapter_coa_map(id,clientcode,ifixcoacode,ifixid,tenantid) values(,'10201','0215-01-104-00-00-00',,'pb');

• insert into ifix_adapter_coa_map(id,clientcode,ifixcoacode,ifixid,tenantid) values(,'WS_ADVANCE_CARRYFORWARD','0215-01-799-04-00-43',,'pb');

A quick walkthrough of mGramSeva

Detailed version -

Service Architecture

mGramSeva is built on top of the Platform. It consists of distinct layers listed below.​

Back End

• Core Services

  1. ​(egov-user)

  2. (user-otp)

  3. ​ (access-control)

  4. ​

  5. (id-gen)

  6. ​ (pg-service)

  7. ​ (wf-service)

  8. ​

  9. ​

  10. ​ (data-encryption-service)

  11. ​e (localization-service)

  12. ​e (location-service)

  13. ​ (url-shortening-service)

  14. ​ (pdf-generator)

  15. ​ (notification-sms)

  16. (notification-email)

  17. ​

  18. ​​

• Business Services

  1. ​

  2. ​

  3. ​

  4. ​

  5. ​s (DSS)

• Municipal Services

  1. ​ (property-services)

  2. ​ (ws-calculator)

  3. ​ (ws-service)

  4. ​ (echallan)

  5. ​ (user-event)

  6. ​​

  7. ​​

mGramSeva Architecture Diagram

The sequence diagram below illustrates a typical interaction between the various services.

Overview

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.

3. Integrate the below changes in vendor-persister.yml - https://github.com/egovernments/configs/commit/95dd26f926ec44d07448926ee4b6b7e031847a57

4. https://github.com/egovernments/configs/pull/2237/files

Configuration Details

Actions & Role Action Mapping

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

Actions

{
      "id": {{PLACEHOLDER1}},
      "name": "Create Vendor/DSO",
      "url": "/vendor/v1/_create",
      "displayName": "Create Vehicle",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "vendor",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER1}},
      "name": "Search Vendor/DSO",
      "url": "/vendor/v1/_search",
      "displayName": "Search  Vendor",
      "orderNumber": 1,
      "enabled": false,
      "serviceCode": "vendor",
      "code": "null",
      "path": ""
    },

Role Action Mapping

[
  {
    "rolecode": "FSM_ADMIN",
    "actionid": "{{PLACEHOLDER1}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_ADMIN",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_DSO",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_EDITOR_EMP",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_VIEW_EMP",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_EMP_FSTPO",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "CITIZEN",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  }
]

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

# Common Labels
labels:
  app: "vendor"
  group: "rainmaker"

# Ingress Configs
ingress:
  enabled: true
  zuul: true
  context: "vendor"

# Init Containers Configs
initContainers:
  dbMigration:
    enabled: true
    schemaTable: "vendor_schema"
    image:
      repository: "vendor-db"

# Container Configs
image:
  repository: "vendor"
replicas: "1"
healthChecks:
  enabled: true
  livenessProbePath: "/vendor/health"
  readinessProbePath: "/vendor/health"
appType: "java-spring"
tracing-enabled: true
heap: "-Xmx256m -Xms256m"
java-args: "-Dspring.profiles.active=monitoring"

# Additional Container Envs
env: |
  - name: EGOV_VEHICLE_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: vehicle
  - name: EGOV_MDMS_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-mdms-service
  - name: EGOV_USER_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-user
  - name: EGOV_LOCATION_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-location
  - name: EGOV_HRMS_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-hrms
  - name: SPRING_KAFKA_CONSUMER_GROUP_ID
    value: egov-vendor-services
  - name: PERSISTER_SAVE_VENDOR_TOPIC
    value: save-vendor-application
  - name: PERSISTER_UPDATE_VENDOR_TOPIC
    value: update-vendor-application
  - name: SPRING_KAFKA_PRODUCER_KEY_SERIALIZER
    value: org.apache.kafka.common.serialization.StringSerializer
  - name: SPRING_KAFKA_PRODUCER_VALUE_SERIALIZER
    value: org.springframework.kafka.support.serializer.JsonSerializer
  - name: JAVA_OPTS
    value: {{ index .Values "heap" | quote }}
  - name: JAVA_ARGS
    value: {{ index .Values "java-args" | quote }}
  - name: SERVER_PORT
    value: "8080"
  - name: SECURITY_BASIC_ENABLED
    value: "false"  
  - name: MANAGEMENT_SECURITY_ENABLED
    value: "false"
  {{- if index .Values "tracing-enabled" }}
  - name: TRACER_OPENTRACING_ENABLED
    value: "true" 
  {{- end }}
 

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

curl --location --request POST 'https://dev.digit.org/vendor/v1/_create' \
--header 'Content-Type: application/json' \
--data-raw '{
    "RequestInfo": {
        "apiInfo": {
            "id": "string",
            "version": "string",
            "path": "string"
        },
        "deviceDetail": {
            "id": "string",
            "signature": "string"
        },
        "ts": 0,
        "action": "string",
        "key": "string",
        "msgId": "string",
        "requesterId": "string",
        "authToken": "a35b5ba7-2d5f-4272-8a67-0303cfab2c9f"
    },
    "vendor": {
        "tenantId": "pb.amritsar",
        "name": "DSO TATA1",
        "address": { 
            "tenantId": "pb.amritsar",
            "doorNo": "my door",
            "plotNo": "my plot",
            "landmark": "my landmark",
            "city": "amritsar",
            "district": "amritsar",
            "region": "amritsar",
            "state": "punjab",
            "country": "in",
            "pincode": "143001",
            "additionDetails": null,
            "buildingName": "my building",
            "street": "my streat",
            "locality": {
                "code": "SUN178",
                "name": "Mohalla Singh kia - Area2",
                "label": "Locality",
                "latitude": null,
                "longitude": null,
                "area": "Area2",
                "pincode": null,
                "boundaryNum": 1,
                "children": []
            },
            "geoLocation": {
                "latitude": 0,
                "longitude": 0,
                "additionalDetails": {}
            }
        },
        "owner": {

            "tenantId": "pb.amritsar",
            "name": "DSOc4",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146603
        },
        "vehicles": [{
        "tenantId": "pb.amritsar",
        "registrationNumber": "TS 09 PA 3586",
        "model":"1998",
        "type":"TATA.407",
        "tankCapacity":"2000",
        "suctionType":"SEWER_SUCTION_MACHINE",
        "pollutionCertiValidTill":1611584416772,
        "InsuranceCertValidTill":1611584416772,
        "fitnessValidTill":1611584416772,
        "roadTaxPaidTill":1611584416772,
        "gpsEnabled":true,
        "source":"Municipal records",
        "owner": {

            "tenantId": "pb.amritsar",
            "name": "DSOc4",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146617
        }
    },{
        "tenantId": "pb.amritsar",
        "registrationNumber": "TS 09 PA 2584",
        "model":"1998",
        "type":"MAHINDRA.BOLERO_PICKUP",
        "tankCapacity":"2000",
        "suctionType":"SEWER_SUCTION_MACHINE",
        "pollutionCertiValidTill":1611584416772,
        "InsuranceCertValidTill":1611584416772,
        "fitnessValidTill":1611584416772,
        "roadTaxPaidTill":1611584416772,
        "gpsEnabled":true,
        "source":"Municipal records",
        "owner": {

            "tenantId": "pb.amritsar",
            "name": "DSOc3",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146617
        }
    }],
        "drivers": [{

            "tenantId": "pb.amritsar",
            "name": "DriverDSO4",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146216
        },{

            "tenantId": "pb.amritsar",
            "name": "DriverDSO3",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146216
        }],
        "source": "WhatsApp"
    }
}'

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

DIGIT being an open-source platform, all the tools and tech stack used to build, deploy and operate DIGIT - are also open-sourced and community edition. The tools used to set up, develop and deploy the mGramSeva stack are listed below with the specific versions used and their short description.

Overview

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 MDMS service with the module name as mseva. Following is some sample master data for the service: Event Categories

{
  "tenantId": "pb",
  "moduleName": "mseva",
  "EventCategories": [
    {
      "code": "PUBLICHEALTH",
      "eventType":"EVENTSONGROUND",
      "active": true
    },
    {
      "code": "CULTURAL",
      "eventType":"EVENTSONGROUND",
      "active": true
    },
    {
      "code": "WARDCOMMITTEEMEETING",
      "eventType":"EVENTSONGROUND",
      "active": true
    }
  ]
}

Event Types:

{
  "tenantId": "pb",
  "moduleName": "mseva",
  "EventTypes": [
    {
      "code": "BROADCAST",
      "active": true
    },
    {
      "code": "EVENTSONGROUND",
      "active": true
    },
    {
      "code": "SYSTEMGENERATED",
      "active": true
    },
    {
      "code": "OTHERS",
      "active": true
    }
  ]
}

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

{
  "messages": [
    {
      "code": "egovuserevents.notification.counterevent.ondelete",
      "message": "<event_name> has been deleted. Please remove from your calendar.",
      "module": "egov-user-events",
      "locale": "en_IN"
    },
    {
      "code": "egovuserevents.notification.counterevent.onupdate",
      "message": "Details of <event_name> have been updated.",
      "module": "egov-user-events",
      "locale": "en_IN"
    }
  ]
}

Configurable Properties

Following are the properties in application.properties file in egov-user-events service which are 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.

Every event should contain information about the event type, event category, event name, description, recipient, actions, event details etc. Based on the type of the event, the list of mandatory fields varies. MDMS configurations required for this service to work can be found here: https://github.com/egovernments/egov-mdms-data/tree/master/data/pb/mseva

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 Delete event, pass Status as CANCELLED and to get details about 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).

Overview

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

MDMS CONFIG: https://github.com/egovernments/egov-mdms-data/tree/DEV/data/pb/PropertyTax

Persister File Configuration

The persister file configuration for property services can be found in the Config repo of eGov Git, which needs to be added in the persister service - property-services-registry.yml

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.

For the creation of property from the water and sewerage module, as per the use case mentioned in this ticket, a different workflow configuration is used. For each use case, to identify which workflow to use can be identified from this mdms file.

{
 "tenantId": "pb",
 "moduleName": "PropertyTax",
 "PTWorkflow":[
     {
         "businessService":"PT.CREATEWITHWNS",
         "initialAction":"OPEN",
         "inWorkflowStatusAllowed":false,
         "enable":false
     },
     {
      "businessService":"PT.CREATE",
      "initialAction":"open",
      "inWorkflowStatusAllowed":true,
      "enable":true
  }
     
 ]
}

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

{
    "BusinessServices": [
      {
        "tenantId": "pb",
        "businessService": "PT.CREATEWITHWNS",
        "business": "PT",
        "businessServiceSla": null,
        "states": [
          {
            "sla": null,
            "state": null,
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": true,
            "isTerminateState": false,
            "isStateUpdatable": false,
            "actions": [
              {
                "action": "OPEN",
                "nextState": "INITIATED",
                "roles": [
                  "CITIZEN",
                  "WS_CEMP",
                  "SW_CEMP"
                ]
              }
            ]
          },
          {
            "sla": null,
            "state": "INITIATED",
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": true,
            "isTerminateState": false,
            "isStateUpdatable": true,
            "actions": [
              {
                "action": "SUBMIT",
                "nextState": "APPROVED",
                "roles": [
                  "EMPLOYEE",
                  "CITIZEN",
                  "SW_CEMP",
                  "WS_CEMP"
                ]
              },
              {
                "action": "BACK",
                "nextState": "INWORKFLOW",
                "roles": [
                  "EMPLOYEE",
                  "CITIZEN",
                  "SW_CEMP",
                  "WS_CEMP"
                ]
              }
            ]
          },
          {
            "sla": null,
            "state": "INWORKFLOW",
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": true,
            "isTerminateState": false,
            "isStateUpdatable": true,
            "actions": [
              {
                "action": "SUBMIT",
                "nextState": "APPROVED",
                "roles": [
                  "EMPLOYEE",
                  "CITIZEN",
                  "SW_CEMP",
                  "WS_CEMP"
                ]
              }
            ]
          },
          {
            "sla": null,
            "state": "APPROVED",
            "applicationStatus": "ACTIVE",
            "docUploadRequired": false,
            "isStartState": false,
            "isTerminateState": true,
            "isStateUpdatable": false,
            "actions": null
          }
        ]
      }
    ]
  }

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

 {
  "RequestInfo": {
    "apiId": "Rainmaker",
    "action": "",
    "did": 1,
    "key": "",
    "msgId": "20170310130900|en_IN",
    "requesterId": "",
    "ts": 1513579888683,
    "ver": ".01",
    "authToken": "b39181b1-5c6b-484a-b825-6be2f62012b8"
  },
 "BusinessServices": [
  {
    "tenantId": "pb",
    "businessService": "PT.CREATE",
    "business": "PT",
    "businessServiceSla": null,
    "states": [
        {
            "tenantId": "pb",
            "sla": null,
            "state": null,
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": true,
            "isTerminateState": false,
            "actions": [
                {
                    "tenantId": "pb",
                    "action": "OPEN",
                    "nextState": "OPEN",
                    "roles": [
                        "CITIZEN",
                        "EMPLOYEE"
                    ]
                }
            ]
        },
        {
            "tenantId": "pb",
            "sla": null,
            "state": "OPEN",
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": true,
            "isTerminateState": false,
            "actions": [
                {
                    "tenantId": "pb",
                    "action": "VERIFY",
                    "nextState": "DOCVERIFIED",
                    "roles": [
                        "PT_DOC_VERIFIER"
                    ]
                },
                {
                  "tenantId": "pb",
                  "action": "REJECT",
                  "nextState": "REJECTED",
                  "roles": [
                      "PT_DOC_VERIFIER"
                  ]
              },
              {
                "tenantId": "pb",
                "action": "SENDBACKTOCITIZEN",
                "nextState": "CORRECTIONPENDING",
                "roles": [
                    "PT_DOC_VERIFIER"
                ]
            }
            ]
        },
        {
            "tenantId": "pb",
            "sla": null,
            "state": "DOCVERIFIED",
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": false,
            "isTerminateState": false,
            "actions": [
                {
                    "tenantId": "pb",
                    "action": "FORWARD",
                    "nextState": "FIELDVERIFIED",
                    "roles": [
                        "PT_FIELD_INSPECTOR"
                    ]
                }
            ]
        },
        {
            "tenantId": "pb",
            "sla": null,
            "state": "FIELDVERIFIED",
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": false,
            "isTerminateState": false,
            "actions": [
                {
                    "tenantId": "pb",
                    "action": "APPROVE",
                    "nextState": "APPROVED",
                    "roles": [
                        "PT_APPROVER"
                    ]
                },
                {
                    "tenantId": "pb",
                    "action": "REJECT",
                    "nextState": "REJECTED",
                    "roles": [
                        "PT_APPROVER"
                    ]
                }
            ]
        },
        {
            "tenantId": "pb",
            "sla": null,
            "state": "REJECTED",
            "applicationStatus": "INACTIVE",
            "docUploadRequired": false,
            "isStartState": false,
            "isTerminateState": true,
            "actions": null
        },
        {
            "tenantId": "pb",
            "sla": null,
            "state": "APPROVED",
            "applicationStatus": "ACTIVE",
            "docUploadRequired": false,
            "isStartState": false,
            "isTerminateState": true,
            "actions": null
        },
        {
          "tenantId": "pb",
          "sla": null,
          "state": "CORRECTIONPENDING",
          "applicationStatus": "INWORKFLOW",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
              {
                  "tenantId": "pb",
                  "action": "REOPEN",
                  "nextState": "OPEN",
                  "roles": [
                    "CITIZEN",
                    "PT_CEMP"
                  ]
              },
              {
                  "tenantId": "pb",
                  "action": "REJECT",
                  "nextState": "REJECTED",
                  "roles": [
                    "CITIZEN",
                    "PT_CEMP"
                  ]
              }
          ]
      }
    ]
}
  ]
}	

PT.LEGACY workflow config

{
    "RequestInfo": {
      "apiId": "Rainmaker",
      "action": "",
      "did": 1,
      "key": "",
      "msgId": "20170310130900|en_IN",
      "requesterId": "",
      "ts": 1513579888683,
      "ver": ".01",
      "authToken": "{{authToken_amritsar}}"
    },
    "BusinessServices": [
      {
        "tenantId": "pb",
        "businessService": "PT.LEGACY",
        "business": "PT",
        "businessServiceSla": null,
        "states": [
          {
            "tenantId": "pb",
            "sla": null,
            "state": null,
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": true,
            "isTerminateState": false,
            "actions": [
              {
                "tenantId": "pb",
                "action": "OPEN",
                "nextState": "APPROVALPENDING",
                "roles": [
                  "CITIZEN",
                  "EMPLOYEE"
                ]
              }
            ]
          },
          {
            "tenantId": "pb",
            "sla": null,
            "state": "APPROVALPENDING",
            "applicationStatus": "INWORKFLOW",
            "docUploadRequired": false,
            "isStartState": true,
            "isTerminateState": false,
            "actions": [
              {
                "tenantId": "pb",
                "action": "APPROVE",
                "nextState": "APPROVED",
                "roles": [
                  "EMPLOYEE"
                ]
              },
              {
                "tenantId": "pb",
                "action": "REJECT",
                "nextState": "REJECTED",
                "roles": [
                  "EMPLOYEE"
                ]
              }
            ]
          },
          {
            "tenantId": "pb",
            "sla": null,
            "state": "REJECTED",
            "applicationStatus": "INACTIVE",
            "docUploadRequired": false,
            "isStartState": false,
            "isTerminateState": true,
            "actions": null
          },
          {
            "tenantId": "pb",
            "sla": null,
            "state": "APPROVED",
            "applicationStatus": "INACTIVE",
            "docUploadRequired": false,
            "isStartState": false,
            "isTerminateState": true,
            "actions": null
          }
        ]
      }
    ]
  }

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 -

[
        {
            "code": "PT_NOTIF_WF_STATE_LOCALE_OPEN",
            "message": "Open",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_STATE_LOCALE_DOCVERIFIED",
            "message": "Document Verified",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_STATE_LOCALE_FIELDVERIFIED",
            "message": "Field verified",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_STATE_LOCALE_APPROVED",
            "message": "Approved",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_STATE_LOCALE_REJECTED",
            "message": "Rejected",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_STATE_LOCALE_PAID",
            "message": "Paid",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_MT_OPEN",
            "message": "Dear {OWNER_NAME}, Your application to edit ownership details of property ID {PROPERTYID} has been submitted successfully. Your application no. for future reference is {APPID}. You can track your application on the link given below - {MTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_MT_STATE_CHANGE",
            "message": "Dear {OWNER_NAME}, Status for your application no. {APPID} for property {PROPERTYID} to edit ownership has been changed to {STATUS}. You can track your application on the link given below - {MTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_MT_PAYMENT_PENDING",
            "message": "Dear {OWNER_NAME}, Payment is pending for your application no. {APPID} for property ID {PROPERTYID} to edit ownership. You can pay your mutation fee on the below link - {PAYLINK} or visit your ULB to pay your dues. Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_MT_PAID",
            "message": "Dear {OWNER_NAME}, You’ve successfully paid mutation fee - INR {AMOUNT} for application no. {APPID} for property ID {PROPERTYID}. You can download your receipt on the below link - {MTURL} Thank you ",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_MT_APPROVED",
            "message": "Dear {OWNER_NAME}, Your property ownership has been changed as per the application no. {APPID} for property {PROPERTYID}. You can download your mutation certificate on the below link - {MTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_MT_NONE",
            "message": "Dear {OWNER_NAME}, Your property with property-id {PROPERTYID} has been mutated. You can view your property on the link given below - {MTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_OPEN",
            "message": "Dear {OWNER_NAME}, Your application to {updated/created} property with Id {PROPERTYID} has been submitted successfully. Your application no. for future reference is {APPID}. You can track your application on the link given below - {PTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_STATUS_CHANGE",
            "message": "Dear {OWNER_NAME}, Status for your application no. {APPID} for property {PROPERTYID} to {updated/created} property has been changed to {STATUS}. You can track your application on the link given below - {PTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_APPROVED",
            "message": "Dear {OWNER_NAME}, Your property has been {updated/created} as per the application no. {APPID} for property {PROPERTYID}. You can view your property on the link given below - {PTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        },
        {
            "code": "PT_NOTIF_WF_UPDATE_NONE",
            "message": "Dear {OWNER_NAME}, Your property with property-id {PROPERTYID} has been {updated/created}. You can view your property on the link given below - {PTURL} Thank you",
            "module": "rainmaker-pt",
            "locale": "en_IN"
        }
    ]

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

Overview

eChallan system enables employees to generate the challans for Adhoc services so that the payment can be recorded into the system along with service-specific details.

It also enables citizens to make payments online based on challan numbers.

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 eChallan persister config path added to it

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

Key Functionalities

• Allow employees to capture service details for miscellaneous services and collect payment

• Allow employees to update/cancel challan

• Search, download, and print echallan / bill for miscellaneous service

• Generate and view echallan / bill pdf for all miscellaneous and ad-hoc services

• Send an SMS and an email bill notification to the citizen with a payment link and bill link

Configuration Details

Actions & Role Action Mapping

Actions

Role Action Mapping

Roles available:

Localization:

Deployment Details

1. Add MDMS configurations required for eChallan Service and calculator and restart the MDMS service.

2. Deploy the latest version of eChallan Service and calculator.

3. Add eChallan Service persister yaml path in persister configuration and restart persister service.

4. Add Role-Action mapping for APIs.

5. Add pdf configuration file for challan and bill.

Integration Details

Integration Scope

The eChallan service is used to generate e-challans / bills for all miscellaneous/ad-hoc services which citizens avail from ULBs.

Integration Benefits

• Can perform service-specific business logic without impacting the other module.

• Allows capturing the unique identifier of the entity for which the challan is generated.

• In the future, if we decide to make the application accessible to citizens, it can be done effortlessly.

• Workflow or service-specific workflow can be enabled at the challan service level at any time, without the need for any design changes.

• Allow employees to update/cancel challan.

Integration Steps

1. To integrate, you need to overwrite the host of the echallan-services module in the Helm chart.

2. echallan-services/eChallan/v1/_create should be added as the create endpoint for creating eChallan in the system.

3. echallan-services/eChallan/v1/_search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria.

4. echallan-services/eChallan/v1/_update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of applications based on workflow.

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

Overview

Water Calculator Service is used to create meter readings, search meter readings, update existing meter readings, calculate water charges, generate demand, notify ULB officials using SMS & email on-demand generation and estimation of water charges (one-time cost) which involves costs like road-cutting charge, form fee, scrutiny fee, etc.

Pre-requisites

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

1. Java 8

2. The Kafka server is up and running

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

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

5. The following services should be up and running:

   • egov-perister

   • 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

• 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 files in the config folder in git and add that path in persister. (Add the file path to the environment YAML file under a parameter named "persist-yml-path").

Configuration Details

MDMS Configuration

Billing Slabs

Criteria

1. connection type

2. building type

3. calculation attribute

4. property usage type

Depending on the matching criteria for the water connection, the calculation applies the specified slab.

Estimation:

For the one-time fee application, the estimation will return all related tax heads based on criteria. All configurations for estimation are present in ws-services-calculation.

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:

The billing slab determines the water charges. Water application charges are based on the slab and tax calculations are based on the master configuration.

Interest:

Below is a sample of the master data JSON for interest :

Penalty:

Below is a sample of the master data JSON for penalty:

Round Off:

If the fraction is greater than equal to 0.5 the number is rounded up else it’s rounded down. For example, 100.4 is rounded to 100 while 100.6 is rounded to 101.

Actions & Role Action Mapping

Actions

Role Action Mapping

Demand Generation

Once water is sent to the calculator, its tax estimates are calculated. Using these tax head estimates, demand details are created. For every tax head, the estimated demand generates a corresponding demand detail.

When the _calculate API is called, demand is first searched based on the connection number or application number and the demand period. If demand already exists, it is updated with the new information. Otherwise, a new demand is generated for the financial year period.

During an update, if the tax head estimates change, the difference in amount for that tax head is added as a 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:

Round-off in the bill is based on the total amount, ensuring that the payable amount is a whole number. Each WS_ROUNDOFF in the demand detail can be greater than 0.5, but the sum of all WS_ROUNDOFF values is always less than 0.5.

Demand Generation Scheduler (For Non-metered Connection)

Description

To generate demand for non-metered connections, we have a feature for batch demand generation. The scheduler is responsible for generating demand based on the tenant.

• The scheduler can be triggered using the scheduler API, scheduled as a cron job, or configured in Kubectl to hit the scheduler based on the configuration.

• After the scheduler is triggered, we can search for the list of tenants (cities) in the database.

• After obtaining the list of tenants, iterate through the list and generate the demand for specific tenants.

• Load the consumer codes for the tenant and push the calculation criteria to Kafka. The calculation criteria contain minimal information, including the consumer code and one boolean variable.

• After pushing the data into Kafka, the system consumes the records based on the batch configuration. For example, if the batch configuration is set to 50, the system will consume 50 calculation criteria at a time.

• After consuming the records (calculation criteria), the system processes the batch to generate the demand. If the batch processing is successful, the processed consumer codes are logged.

• If some records fail in the batch, the system pushes the batch into the dead letter batch topic. From there, the batch is processed one record at a time.

• If the record is successful, the system logs the consumer code. If the record fails, the data is pushed into a dead-letter single topic.

• Dead letter single topic contains information about failure records in Kafka.

Use cases:

1. If the same job triggers multiple times what will happen?

If the same job triggers multiple times the system processes it again as mentioned above but at the demand level, it checks the demand based on consumer code and billing period. In case the demand already exists then it updates the demand or else creates the demand.

1. Are we maintaining success or failure status anywhere?

Currently, we are maintaining the status of failed records in Kafka.

Configuration:

We need to configure the batch size for Kafka consumers. This configuration determines how much data is processed at a time.

Integration Details

Integration Scope

The ws-calculator is integrated with ws-service. ws-services internally invoke the ws-calculator service to calculate and generate demand for the charges.

Integration Benefits

WS calculator application is used to calculate the water application one-time fees and meter reading charges based on the different billing slabs. That's why the calculation and demand generation logic is separated from the WS service. So in future, if calculation logic requires modification the changes can be carried out for each implementation without modifying the WS service.

Integration Steps

1. Once the water connection is activated for the metered connection, the employee can add meter reading details using the API - /ws-calculator/meterConnection/_create. This generates the demand. For non-metered connections, the scheduler APIs should be called periodically to generate the demand.

2. For the metered connection service, the /meterConnection/_search API is used to get the previous meter reading,

3. To activate the Water Service application, the user has to pay the ONE_TIME_FEE for the connection. To calculate this fee, the ONE_TIME_FEE /waterCalculator/_estimate API is used.

4. To generate the demand for metered or non-metered water connection /waterCalculator/_calculate API is used.

5. Users can pay partial/full/advance amounts for the metered or non-metered connection bill. In such cases, the billing service would call back /waterCalculator/_updateDemandAPI to update the demand-generated details.

6. /waterCalculator/_jobscheduler API is used to generate demand for non-metered connections. This API can be called periodically.

7. /waterCalculator/_applyAdhocTax API is used to add a Rebate or Penalty on any bill and based on that the bill amount is adjusted.

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

​All content on this page by is licensed under a .

About Firebase Analytics

Google Analytics helps you understand how people use the web and Android apps. Analytics helps you understand how the users behave, so we can make informed decisions about how to market our app.

Plugins Used

firebase_analytics

About Firebase Console

In the Firebase console we can track the real-time user usage, Below are the main core features for tracking the user

• Users in the last 30 minutes.

• User's activity over time using a date picker represents inline charts.

• Track the users by app version.

• Track users by device Model.

• User Retention.