1 of 4

Municipal Service

DIGIT offers key municipal services such as Public Grievance & Redressal, Trade License, Water & Sewerage, Property Tax, Fire NOC, and Building Plan Approval.

PGR Services
Trade License Services

PGR Services 2.0

Overview

Public Grievances & Redressal (PGR) is a system that enables citizens to raise a complaint with the ULBs. A citizen can track the complaint, upload image related to the complaint, re-open the complaint if he/she is not satisfied and rate the service. This document contains the details about how to setup PGR service and describes the functionalities it provides

Pre-requisites

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

Java 8
Kafka server is up and running
egov-persister service is running and has pgr-services persister config path added in it
PSQL server is running and database is created to store complaint data
(Optional) Indexer config for pgr-services is added in egov-indexer yaml paths to index the generated data. Index is required for data visualisation in Kibana or in DSS.
(Optional) Report config for pgr-services is added in Report service config paths. Required if reports are to be provided to the user.
Following services should be up and running:
- egov-user
- egov-workflow-v2
- egov-perister
- egov-localization
- egov-notification-sms
- egov-mdms
- egov-idgen
- egov-url-shortening
- egov-hrms

Key Functionalities

A citizen can file, track and rate the complaint
A citizen can add image and comments related to the complaint
A citizen can re-open the complaint in a certain given period of time after resolution
ULB can setup the complaint workflow according to their requirements and staff capacity
ULB can track the SLA for resolving each complaint and can use it as a metric to streamline the process for resolving complaints
Department wise assignment of the complaint to the LME

Deployment Details

Deploy the latest version of pgr-services
Add pgr-service-persister.yml file in config folder in git and add that path in persister. (The file path is to be added in environment yaml file in param called persist-yml-path )
If any Report Config is created, the config should be added to the config folder in git and that path should be added in Report service. (The file path is to be added in a file called “reportFileLocationsv1.txt” in Config folder)
If index is to be created add the indexer config path in indexer service. (The file path is to be added in environment yaml file in param called egov-indexer-yaml-repo-path)

Configuration Details

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

Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for PGR:

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

Add Role-Action mapping for the APIs in MDMS. Following are the required entries. They should be mapped to both CITIZEN and appropriate employee roles.

Integration

Integration Scope

PGR service can be integrated with any organisation or system which wants to track customer queries or complaint. The organisations can customise the workflow depending on their product requirements.

Integration Benefits

Easy tracking and resolution of complaints
Configurable workflow according to client requirement

Steps to Integration

Customer can raise a complaint using the /requests/_create.
Organisation or System can search the complaint using /requests/_searchendpoint.
Once the complaint is raised the organisation or system can call /requests/_update endpoint to move the application further in workflow until it gets resolved.

Interaction Diagram

Reference Docs

Doc Links

API List

PGR Migration

Setup

Config/Service Name

Path/Build

Persister yml for bulk migration

pgr-services

pgr-services-db:pgr-migration-2475ec38-56

rainmaker-pgr

rainmaker-pgr-db:pgr-migration-c046a264-20

The above build’s has to be deployed to perform migration. The batch persister config has to be added in config Repo. After adding the file in repo, update the persister path in environment yml file. Make sure the persister.bulk.enabled is set to true. Once done restart the persister pod.

To start the migration call the following API with tenantId as param it will migrate data belonging to that tenantId. The API does not have role action mapping and should be used by port forwarding rainmaker-pgr pod.

curl --location --request POST 'http://localhost:8083/rainmaker-pgr/v2/_migrate?tenantIds=pb.jalandhar' \
--header 'Content-Type: application/json' \
--data-raw '{
     "RequestInfo": {
        "apiId": "Rainmaker",
        "action": "",
        "did": 1,
        "key": "",
        "msgId": "20170310130900|en_IN",
        "requesterId": "",
        "ts": 1513579888683,
        "ver": ".01",
        "authToken": "6fc5bb66-f3f1-49fa-b750-34f7b33d80d4",
        "userInfo": {
        "id": 23287,
        "uuid": "4632c941-cb1e-4b83-b2d4-200022c1a137",
        "userName": "PalashS",
        "name": "Palash S",
        "mobileNumber": "9949032246",
        "emailId": null,
        "locale": null,
        "type": "EMPLOYEE",
        "roles": [
            {
                "name": "PGR Last Mile Employee",
                "code": "PGR_LME",
                "tenantId": "pb.amritsar"
            },
            {
                "name": "Employee",
                "code": "EMPLOYEE",
                "tenantId": "pb"
            },
            {
                "name": "Employee",
                "code": "EMPLOYEE",
                "tenantId": "pb.amritsar"
            }
        ],
        "active": true,
        "tenantId": "pb.amritsar"
    }
    }
}'

WSD

Validation Queries

select  distinct(action),count(*) from eg_pgr_action group by  action
select st.state,count(*) from eg_wf_processinstance_v2 pi INNER JOIN eg_wf_state_v2 st ON st.uuid = pi.status  where businessService ='PGR' group by st.state

select tenantId,count(*) from eg_pgr_service group by tenantId;
select tenantId,count(*) from eg_pgr_service_v2 group by tenantId;

select servicecode,count(*) from eg_pgr_service group by servicecode;
select servicecode,count(*) from eg_pgr_service_v2 group by servicecode;

select active,count(*) from eg_pgr_service group by active;
select active,count(*) from eg_pgr_service_v2 group by active;

select count(*) from eg_pgr_address
select count(*) from eg_pgr_address_v2

-- Assignee count match
select count(*) from eg_pgr_action where assignee is not null;
select count(*) from eg_wf_assignee_v2;

select count(*)  from eg_pgr_action  where media NOT in ('[]','null')
select count(*) from eg_wf_document_v2 where processinstanceid IN (select id from eg_wf_processinstance_v2 where businessService ='PGR')

*(Last query related to document might need little modification as values in NOT IN clause can be more than the 2 specified)

Prod Data Insights

null value is stored in action for adding comments in old system it’s mapped to COMMENT in new system.
Locality attribute in new eg_pgr_address_v2 table does not allow NULL values whereas the locality attribute in old eg_pgr_address in Punjab prod data has NULL values. Those values are filled in migration with dummy value NOT_AVAILABLE.
For 128 records accountId is NULL and so they won’t be associated with any citizen login.
For some records in media column corrupt data is present. For example on one case instead of fileStore uuid some normal text describing the complaint is present. While some other records have values like no . For data with such text having length greater than 64 are set to null, else DB validation’s are violated.
In old system id is stored for referencing user data. In new systems we use uuid to refer user, therefore all id are mapped to respective uuid which are then migrated to new system. If some user has uuid as NULL default value NOT_SPECIFIED will be used.
Some 1104 complaints has value in column named feedback which seems to be from some set pf predefined values like "Resolution Time","Quality of work",”others” etc. New structure don’t have any such column so we will be storing this in additionalDetails.
Address and landmark column in eg_pgr_service has values in some column they are also stored in additionalDetails.
Phone column contains phone numbers, we are not migrating that column as it has PII data and will be already present in user service as well.
If sla is not found in old config (will only happen if some complaint category is removed from MDMS and complaints are present in system of that category) default SLA value will be used.

Trade-License Service

Overview

This service is used to issue a license to the user after verification. The service is designed in such a way that it can be used to serve different type of licenses. Currently used to issue trade licenses, perform stakeholder registration and issue lockdown pass. The service is integrated with workflow where we can define the steps for approval of the application. Once the application is approved the license is generated.

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 tl-services persister config path added in it
PSQL server is running and database is created

Key Functionalities

Used for license generations in trade licenses, stakeholder registration and issue lockdown pass
Define roles to applicants on successful application to access Building Plan Approval services at the time of stakeholder registration
Generate application number and license number
Support workflows
Provide notification on various status changes for an application

Interaction Diagram

Deployment Details

Add MDMS configs required for Trade License and BPA stakeholder registration and restart MDMS service
Deploy the latest version of tl-services service
Add tl-service persister yaml path in persister configuration and restart persister service
Add Role-Action mapping for API’s
Create businessService (workflow configuration) according to trade license and stakeholder registration
Add tl-service indexer yaml path in indexer service configuration and restart indexer service

Configuration Details

Following application properties in the Trade License service are configurable.

Property

Value

Remarks

egov.idgen.tl.applicationNum.format

PB-TL-[cy:yyyy-MM-dd]-[SEQ_EG_TL_APL]

The format of the TL application number

egov.idgen.tl.licensenumber.format

PB-TL-[cy:yyyy-MM-dd]-[SEQ_EG_PT_LN]

The format of the TL license number

egov.idgen.bpa.applicationNum.format

PB-SK-[cy:yyyy-MM-dd]-[SEQ_EG_TL_APL]

The format of the Stake holder application number

egov.idgen.bpa.licensenumber.format

PB-SK-[cy:yyyy-MM-dd]-[SEQ_EG_PT_LN]

The format of the Stake holder license number

egov.tl.max.limit

100

Max number of records to be returned

citizen.allowed.search.params

tenantId, applicationNumber, limit, offset, licenseNumbers

The search parameters on which citizen can search

employee.allowed.search.params

tenantId, applicationNumber, applicationType, status, mobileNumber, fromDate, toDate, licenseNumbers, oldLicenseNumber, limit, offset

The search parameters on which employee can search

persister.save.tradelicense.topic

save-tl-tradelicense

The name of kafka topic on which create request is published

persister.update.tradelicense.topic

update-tl-tradelicense

The name of kafka topic on which update request is published

persister.update.tradelicense.workflow.topic

update-tl-workflow

The name of kafka topic on which update request is published

Integration

Integration Scope

The trade-license service is currently used to issue trade licenses, perform stakeholder registration and issue lockdown pass.

Integration Benefits

Provide backend support for the different license registration process.
Mseva and SMS notifications on application status changes.
The elastic search index for creating visualizations and Dashboards.
Bpa Stakeholder registration provides new roles to the user to access the Building Plan Approval system.
Supports workflow which is configurable

Steps to Integration

To integrate, host of tl-services service should be overwritten in the helm chart.
{servicename}/_create/ _create should be added as the create endpoint for creating any license in the system
{servicename}/_search/ _search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria
{servicename}/_update/ _update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.

Reference Docs

Doc Links

Title

Link

Local Setup

API Swagger Documentation (Trade License)

API List

In all below endpoints if the service name is BPAREG it is treated as a stakeholder registration application and if it is TL or if it is absent then the application is treated as trade license application.

Stakeholder registration APIs:- https://www.getpostman.com/collections/d18b79ccfb69ee8bb526

Trade-License APIs:- https://www.getpostman.com/collections/99f98723c45f97024831

Link

{servicename}/_create, _create

This API is used to create an application for the license in the system. Whenever an application is created an application number is generated and assigned to the application for future reference.

{servicename}/_search, /_search

This API is used to search the applications in the system based on various search parameters like mobile number, the application number, status etc.

{servicename}/_update, _update

The _update API is used to update the application information or to forward the application from one state to another.

In the case of the stakeholder registration if the application reaches the last stage the role depending on the license type is given to the user.

{servicename}/{jobname}/_batch, /_batch

Searches trade licenses which are expiring and send a reminder SMS to owner's of the licenses

PGR Migration

Setup

Config/Service Name

Path/Build

Persister yml for bulk migration

pgr-services

pgr-services-db:pgr-migration-2475ec38-56

rainmaker-pgr

rainmaker-pgr-db:pgr-migration-c046a264-20

curl --location --request POST 'http://localhost:8083/rainmaker-pgr/v2/_migrate?tenantIds=pb.jalandhar' \
--header 'Content-Type: application/json' \
--data-raw '{
     "RequestInfo": {
        "apiId": "Rainmaker",
        "action": "",
        "did": 1,
        "key": "",
        "msgId": "20170310130900|en_IN",
        "requesterId": "",
        "ts": 1513579888683,
        "ver": ".01",
        "authToken": "6fc5bb66-f3f1-49fa-b750-34f7b33d80d4",
        "userInfo": {
        "id": 23287,
        "uuid": "4632c941-cb1e-4b83-b2d4-200022c1a137",
        "userName": "PalashS",
        "name": "Palash S",
        "mobileNumber": "9949032246",
        "emailId": null,
        "locale": null,
        "type": "EMPLOYEE",
        "roles": [
            {
                "name": "PGR Last Mile Employee",
                "code": "PGR_LME",
                "tenantId": "pb.amritsar"
            },
            {
                "name": "Employee",
                "code": "EMPLOYEE",
                "tenantId": "pb"
            },
            {
                "name": "Employee",
                "code": "EMPLOYEE",
                "tenantId": "pb.amritsar"
            }
        ],
        "active": true,
        "tenantId": "pb.amritsar"
    }
    }
}'

WSD

Validation Queries

select  distinct(action),count(*) from eg_pgr_action group by  action
select st.state,count(*) from eg_wf_processinstance_v2 pi INNER JOIN eg_wf_state_v2 st ON st.uuid = pi.status  where businessService ='PGR' group by st.state

select tenantId,count(*) from eg_pgr_service group by tenantId;
select tenantId,count(*) from eg_pgr_service_v2 group by tenantId;

select servicecode,count(*) from eg_pgr_service group by servicecode;
select servicecode,count(*) from eg_pgr_service_v2 group by servicecode;

select active,count(*) from eg_pgr_service group by active;
select active,count(*) from eg_pgr_service_v2 group by active;

select count(*) from eg_pgr_address
select count(*) from eg_pgr_address_v2

-- Assignee count match
select count(*) from eg_pgr_action where assignee is not null;
select count(*) from eg_wf_assignee_v2;

select count(*)  from eg_pgr_action  where media NOT in ('[]','null')
select count(*) from eg_wf_document_v2 where processinstanceid IN (select id from eg_wf_processinstance_v2 where businessService ='PGR')

*(Last query related to document might need little modification as values in NOT IN clause can be more than the 2 specified)

Prod Data Insights

null value is stored in action for adding comments in old system it’s mapped to COMMENT in new system.
Locality attribute in new eg_pgr_address_v2 table does not allow NULL values whereas the locality attribute in old eg_pgr_address in Punjab prod data has NULL values. Those values are filled in migration with dummy value NOT_AVAILABLE.
For 128 records accountId is NULL and so they won’t be associated with any citizen login.
For some records in media column corrupt data is present. For example on one case instead of fileStore uuid some normal text describing the complaint is present. While some other records have values like no . For data with such text having length greater than 64 are set to null, else DB validation’s are violated.
In old system id is stored for referencing user data. In new systems we use uuid to refer user, therefore all id are mapped to respective uuid which are then migrated to new system. If some user has uuid as NULL default value NOT_SPECIFIED will be used.
Some 1104 complaints has value in column named feedback which seems to be from some set pf predefined values like "Resolution Time","Quality of work",”others” etc. New structure don’t have any such column so we will be storing this in additionalDetails.
Address and landmark column in eg_pgr_service has values in some column they are also stored in additionalDetails.
Phone column contains phone numbers, we are not migrating that column as it has PII data and will be already present in user service as well.
If sla is not found in old config (will only happen if some complaint category is removed from MDMS and complaints are present in system of that category) default SLA value will be used.

Trade-License Service

Overview

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 tl-services persister config path added in it
PSQL server is running and database is created

Key Functionalities

Used for license generations in trade licenses, stakeholder registration and issue lockdown pass
Define roles to applicants on successful application to access Building Plan Approval services at the time of stakeholder registration
Generate application number and license number
Support workflows
Provide notification on various status changes for an application

Interaction Diagram

Deployment Details

Add MDMS configs required for Trade License and BPA stakeholder registration and restart MDMS service
Deploy the latest version of tl-services service
Add tl-service persister yaml path in persister configuration and restart persister service
Add Role-Action mapping for API’s
Create businessService (workflow configuration) according to trade license and stakeholder registration
Add tl-service indexer yaml path in indexer service configuration and restart indexer service

Configuration Details

Following application properties in the Trade License service are configurable.

Property

Value

Remarks

egov.idgen.tl.applicationNum.format

PB-TL-[cy:yyyy-MM-dd]-[SEQ_EG_TL_APL]

The format of the TL application number

egov.idgen.tl.licensenumber.format

PB-TL-[cy:yyyy-MM-dd]-[SEQ_EG_PT_LN]

The format of the TL license number

egov.idgen.bpa.applicationNum.format

PB-SK-[cy:yyyy-MM-dd]-[SEQ_EG_TL_APL]

The format of the Stake holder application number

egov.idgen.bpa.licensenumber.format

PB-SK-[cy:yyyy-MM-dd]-[SEQ_EG_PT_LN]

The format of the Stake holder license number

egov.tl.max.limit

100

Max number of records to be returned

citizen.allowed.search.params

tenantId, applicationNumber, limit, offset, licenseNumbers

The search parameters on which citizen can search

employee.allowed.search.params

tenantId, applicationNumber, applicationType, status, mobileNumber, fromDate, toDate, licenseNumbers, oldLicenseNumber, limit, offset

The search parameters on which employee can search

persister.save.tradelicense.topic

save-tl-tradelicense

The name of kafka topic on which create request is published

persister.update.tradelicense.topic

update-tl-tradelicense

The name of kafka topic on which update request is published

persister.update.tradelicense.workflow.topic

update-tl-workflow

The name of kafka topic on which update request is published

Integration

Integration Scope

The trade-license service is currently used to issue trade licenses, perform stakeholder registration and issue lockdown pass.

Integration Benefits

Provide backend support for the different license registration process.
Mseva and SMS notifications on application status changes.
The elastic search index for creating visualizations and Dashboards.
Bpa Stakeholder registration provides new roles to the user to access the Building Plan Approval system.
Supports workflow which is configurable

Steps to Integration

To integrate, host of tl-services service should be overwritten in the helm chart.
{servicename}/_create/ _create should be added as the create endpoint for creating any license in the system
{servicename}/_search/ _search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria
{servicename}/_update/ _update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.

Reference Docs

Doc Links

Title

Link

Local Setup

API Swagger Documentation (Trade License)

API List

Stakeholder registration APIs:- https://www.getpostman.com/collections/d18b79ccfb69ee8bb526

Trade-License APIs:- https://www.getpostman.com/collections/99f98723c45f97024831

Link

{servicename}/_create, _create

This API is used to create an application for the license in the system. Whenever an application is created an application number is generated and assigned to the application for future reference.

{servicename}/_search, /_search

This API is used to search the applications in the system based on various search parameters like mobile number, the application number, status etc.

{servicename}/_update, _update

The _update API is used to update the application information or to forward the application from one state to another.

In the case of the stakeholder registration if the application reaches the last stage the role depending on the license type is given to the user.

{servicename}/{jobname}/_batch, /_batch

Searches trade licenses which are expiring and send a reminder SMS to owner's of the licenses

PGR Services 2.0

Overview

Pre-requisites

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

Java 8
Kafka server is up and running
egov-persister service is running and has pgr-services persister config path added in it
PSQL server is running and database is created to store complaint data
(Optional) Indexer config for pgr-services is added in egov-indexer yaml paths to index the generated data. Index is required for data visualisation in Kibana or in DSS.
(Optional) Report config for pgr-services is added in Report service config paths. Required if reports are to be provided to the user.
Following services should be up and running:
- egov-user
- egov-workflow-v2
- egov-perister
- egov-localization
- egov-notification-sms
- egov-mdms
- egov-idgen
- egov-url-shortening
- egov-hrms

Key Functionalities

A citizen can file, track and rate the complaint
A citizen can add image and comments related to the complaint
A citizen can re-open the complaint in a certain given period of time after resolution
ULB can setup the complaint workflow according to their requirements and staff capacity
ULB can track the SLA for resolving each complaint and can use it as a metric to streamline the process for resolving complaints
Department wise assignment of the complaint to the LME

Deployment Details

Deploy the latest version of pgr-services
Add pgr-service-persister.yml file in config folder in git and add that path in persister. (The file path is to be added in environment yaml file in param called persist-yml-path )
If any Report Config is created, the config should be added to the config folder in git and that path should be added in Report service. (The file path is to be added in a file called “reportFileLocationsv1.txt” in Config folder)
If index is to be created add the indexer config path in indexer service. (The file path is to be added in environment yaml file in param called egov-indexer-yaml-repo-path)

Configuration Details

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

{
  "tenantId": "pb",
  "moduleName": "RAINMAKER-PGR",
  "ServiceDefs": [
    {
      "serviceCode": "NoStreetlight",
      "keywords": "streetlight, light, repair, work, pole, electric, power, repair, damage, fix",
      "department": "Streetlights",
      "slaHours": 336,
      "menuPath": "StreetLights",
      "active": false,
      "order": 1
    },
    {
      "serviceCode": "StreetLightNotWorking",
      "keywords": "streetlight, light, repair, work, pole, electric, power, repair, fix",
      "department": "DEPT_1",
      "slaHours": 336,
      "menuPath": "StreetLights",
      "active": true,
      "order": 2
    },
    {
      "serviceCode": "GarbageNeedsTobeCleared",
      "keywords": "garbage, collect, litter, clean, door, waste, remove, sweeper, sanitation, dump, health, debris, throw",
      "department": "DEPT_25",
      "slaHours": 336,
      "menuPath": "Garbage",
      "active": true,
      "order": 3
    }
  ]
}

Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for PGR:

{
      "tenantId": "pb",
      "businessService": "PGR",
      "business": "pgr-services",
      "businessServiceSla": 432000000,
      "states": [
        {
          "sla": null,
          "state": null,
          "applicationStatus": null,
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "APPLY",
              "nextState": "PENDINGFORASSIGNMENT",
              "roles": [
                "CITIZEN",
                "CSR"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "PENDINGFORASSIGNMENT",
          "applicationStatus": "PENDINGFORASSIGNMENT",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": false,
          "actions": [
            {
              "action": "ASSIGN",
              "nextState": "PENDINGATLME",
              "roles": [
                "GRO",
                "DGRO"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "GRO",
                "DGRO"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "PENDINGFORREASSIGNMENT",
          "applicationStatus": "PENDINGFORREASSIGNMENT",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": false,
          "actions": [
            {
              "action": "REASSIGN",
              "nextState": "PENDINGATLME",
              "roles": [
                "GRO",
                "DGRO"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "GRO",
                "DGRO"
              ]
            }
          ]
        },

        {
          "sla": 259200000,
          "state": "PENDINGATLME",
          "applicationStatus": "PENDINGATLME",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": false,
          "actions": [
            {
              "action": "RESOLVE",
              "nextState": "RESOLVED",
              "roles": [
                "PGR_LME"
              ]
            },
            {
              "action": "REASSIGN",
              "nextState": "PENDINGFORREASSIGNMENT",
              "roles": [
                "PGR_LME"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "REJECTED",
          "applicationStatus": "REJECTED",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "actions": [
            {
              "action": "REOPEN",
              "nextState": "PENDINGFORASSIGNMENT",
              "roles": [
                "CFC",
                "CSR",
                "CITIZEN"
              ]
            },
            {
              "action": "RATE",
              "nextState": "CLOSEDAFTERREJECTION",
              "roles": [
                "CFC",
                "CITIZEN"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "RESOLVED",
          "applicationStatus": "RESOLVED",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "actions": [
            {
              "action": "REOPEN",
              "nextState": "PENDINGFORASSIGNMENT",
              "roles": [
                "CFC",
                "CSR",
                "CITIZEN"
              ]
            },
            {
              "action": "RATE",
              "nextState": "CLOSEDAFTERRESOLUTION",
              "roles": [
                "CFC",
                "CITIZEN"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "CLOSEDAFTERREJECTION",
          "applicationStatus": "CLOSEDAFTERREJECTION",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true
        },
        {
          "sla": null,
          "state": "CLOSEDAFTERRESOLUTION",
          "applicationStatus": "CLOSEDAFTERRESOLUTION",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true
        }
      ]
    }

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

{
  "messages": [
       {
            "code": "PGR_APPLY_PENDINGFORASSIGNMENT_SMS_MESSAGE",
            "message": "Dear Citizen, Your complaint for <complaint_type> has been submitted with ID <id> on <date>. You can track your complaint status on the mSeva Punjab mobile App (download here - <download link>) or your local municipal web portal.",
            "module": "rainmaker-pgr",
            "locale": "en_IN"
        },
        {
            "code": "PGR_RESOLVE_RESOLVED_SMS_MESSAGE",
            "message": "Dear Citizen, Your complaint for <complaint_type> with ID <id> submitted on <date> has been resolved by <emp_name>. If you are not satisfied with service you can REOPEN complaint through mSeva Punjab mobile App (download here - <download_link>) or your local municipal web portal or by calling our CSR.",
            "module": "rainmaker-pgr",
            "locale": "en_IN"
        },
        {
            "code": "PGR_REOPEN_PENDINGFORASSIGNMENT_SMS_MESSAGE",
            "message": "Dear Citizen, Your complaint for <complaint_type> with ID <id> submitted on <date> has been RE-OPEN as per your request. You can track your complaint status and connect with our officials on the mSeva Punjab mobile App (download here - <download_link>) or your local municipal web portal.",
            "module": "rainmaker-pgr",
            "locale": "en_IN"
        },
        {
            "code": "PGR_REJECT_REJECTED_SMS_MESSAGE",
            "message": "Dear Citizen, Your complaint for <complaint_type> with ID <id> submitted on <date> has been rejected. Reason for Rejection: <reason>, Additional Comments: <additional_comments> If you wish to re-open the complaint, you can download the mSeva Punjab mobile app (download here - <download_link>) or visit your local municipal website.",
            "module": "rainmaker-pgr",
            "locale": "en_IN"
        },
        {
            "code": "PGR_REASSIGN_PENDINGATLME_SMS_MESSAGE",
            "message": "Dear Citizen, Your complaint for <complaint_type> with ID <id> submitted on <date> has been re-assigned to <reassign_emp_name>, <emp_designation>, <emp_department>. You can track your complaint status and connect with our officials on the mSeva Punjab mobile App (download here - <download_link>) or your local municipal web portal.",
            "module": "rainmaker-pgr",
            "locale": "en_IN"
        }      
    ]
}

Add Role-Action mapping for the APIs in MDMS. Following are the required entries. They should be mapped to both CITIZEN and appropriate employee roles.

{
  {
      "id": {{ID_PLACEHOLDER}},
      "name": "Create PGR Request",
      "url": "/pgr-services/v2/requests/_create",
      "parentModule": "",
      "displayName": "Create PGR Request",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "pgr-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{ID_PLACEHOLDER}},
      "name": "Update PGR Request",
      "url": "/pgr-services/v2/requests/_update",
      "parentModule": "",
      "displayName": "Update PGR Request",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "pgr-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{ID_PLACEHOLDER}},
      "name": "Search PGR Request",
      "url": "/pgr-services/v2/requests/_search",
      "parentModule": "",
      "displayName": "Search PGR Request",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "pgr-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{ID_PLACEHOLDER}},
      "name": "Search PGR Request",
      "url": "/pgr-services/v2/requests/_count",
      "parentModule": "",
      "displayName": "Count PGR Request",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "pgr-services",
      "code": "null",
      "path": ""
    }

Integration

Integration Scope

PGR service can be integrated with any organisation or system which wants to track customer queries or complaint. The organisations can customise the workflow depending on their product requirements.

Integration Benefits

Easy tracking and resolution of complaints
Configurable workflow according to client requirement

Steps to Integration

Customer can raise a complaint using the /requests/_create.
Organisation or System can search the complaint using /requests/_searchendpoint.
Once the complaint is raised the organisation or system can call /requests/_update endpoint to move the application further in workflow until it gets resolved.