This section contains all technical documents related to DIGIT stack.

The key services include -

• Core Services

• Business Services

• Municipal Services

• Utilities

Core Services is one of the key DIGIT components. Browse through this section to learn more about key configuration and integration details of these core services.

• Workflow Services

• Location Services

• User Services

• Access Control Services

Overview

A core application which provides location details of the tenant for which the services are being provided.

Pre-requisites

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

• Java 8

• PSQL server is running and database is created

• Knowledge of egov-mdms service

• egov-mdms service is running and all the required mdms master are loaded in it

Key Functionalities

• The location information is also known as boundary data of ULB

• Boundary data can be of different hierarchies ADMIN, ELECTION hierarchy which is defined by the Administrators, Revenue hierarchy defined by the Revenue department.

• The election hierarchy has the locations divided into several types like zone, election ward, block, street and locality. The Revenue hierarchy has the locations divided into a zone, ward, block and locality.

• The model which defines the localities like zone, ward and etc is boundary object which contains information like name, lat, long, parent or children boundary if any. The boundaries come under each other in a hierarchy like a zone contains wards, ward contains blocks, a block contains locality. The order in which the boundaries are contained in each other will differ based on the tenants.

Deployment Details

1. Add/Update the mdms master file which contain boundary data of ULB’s.

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

3. Deploy/Redeploy the latest version of egov-mdms service.

4. Fill the above environment variables in egov-location with proper values.

5. Deploy the latest version of egov-location service.

Configuration Details

The boundary data has been moved to mdms from the master tables in DB. The location service fetches the JSON from mdms and parses it to the structure of boundary object as mentioned above. A sample master would look like below.

{
  "tenantId": "pg.cityA",
   "moduleName": "egov-location",
  "TenantBoundary": [
  {
      "hierarchyType": {
              "code": "ADMIN",
              "name": "ADMIN"
      },
       "boundary": {
                "id": 1,
                "boundaryNum": 1,
                "name": "CityA",
                "localname": "CityA",
                "longitude": null,
                "latitude": null,
                "label": "City",
                "code": "pg.cityA",
                "children": []
        }

    }
 ]
}

Integration

Integration Scope

The egov-location API’s can be used by any module which needs to store the location details of the tenant.

Integration Benefits

• Get the boundary details based on boundary type and hierarchy type within the tenant boundary structure.

• Get the geographical boundaries by providing appropriate GeoJson.

• Get the tenant list in the given latitude and longitude.

Steps to Integration

1. To integrate, host of egov-location should be overwritten in helm chart.

2. /boundarys/_search should be added as the search endpoint for searching boundary details based on tenant Id, Boundary Type, Hierarchy Type etc.

3. /geography/_search should be added as the search endpoint .This method handles all requests related to geographical boundaries by providing appropriate GeoJson and other associated data based on tenantId or lat/long etc.

4. /tenant/_search should be added as the search endpoint. This method tries to resolve a given lat, long to a corresponding tenant, provided there exists a mapping between the reverse geocoded city to tenant.

5. The MDMS Tenant boundary master file should be loaded in MDMS service.

Reference Docs

Doc Links

API List

Please refer to the Swagger API contract for egov-location service to understand the structure of APIs and to have a visualisation of all internal APIs.

Overview

User service is responsible for user data management and providing functionality to login and logout into 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 database

• Redis is running

Key Functionalities

• Store, update and search user data

• Provide authentication

• Provide login, logout functionality into DIGIT 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 egov-user service

3. Add Role-Action mapping for API’s

Configuration Details

Following application properties file in user service are configurable.

Integration Details

Integration Scope

User data management and functionality to login and logout into Digit system using OTP and password.

Integration Benefits

Providing 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 employee to login into DIGIT system based on a password.

• Citizen:

  • Create user

  • Update user

  • Search user

  • User registration using OTP

  • OTP based login

Steps to Integration

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

• Use /citizen/_create and /users/_createnovalidate endpoints for creating users into the system

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

• Use /profile/_update for partial update and /users/_updatenovalidate for update

• Use /password/nologin/_update for otp based password reset and /password/_update for logged in user password reset

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

Reference Docs

Doc Links

API List

Overview

The objective of PDF generation service is to bulk generate pdf as per requirement.

Pre-requisites

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

• Install npm.

• Kafka server is up and running.

• egov-persister service is running and has pdf generation persister config path added in it.

• PSQL server is running and the database is created to store filestore id and job id of generated pdf.

Key Functionalities

• Provide a common framework to generate PDF.

• Provide flexibility to customise the PDF as per the requirement.

• Provide functionality to add an image, Qr Code in PDF.

• Provide functionality to generate pdf in bulk.

• Provide functionality to specify a maximum number of records to be written in one PDF.

External Libraries used :

• Mustache.js: (https://github.com/janl/mustache.js/ ):- as templating engine to populate format as defined in format config, from request json based on mappings defined in data config

Interaction Diagram

Deployment Details

1. Create data config and format config for a PDF according to product requirement.

2. Add data config and format config files in PDF configuration

3. Add the file path of data and format config in the environment yml file

4. Deploy the latest version of pdf-service in a particular environment.

Configuration Details

For Configuration details please refer to Customizing PDF Receipts & Certificates.

Integration

Integration Scope

The PDF configuration can be used by any module which needs to show particular information in PDF format that can be print/downloaded by the user.

Integration Benefits

• Functionality to generate PDFs in bulk.

• Avoid regeneration.

• Support QR codes and Images.

• Functionality to specify the maximum number of records to be written in one PDF.

• Uploading generated PDF to filestore and return filestore id for easy access.

Steps to Integration

1. To download and print the required PDF _create API has to be called with the required key (For Integration with UI, please refer to the links in Reference Docs)

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)

eGov Payment Gateway acts as a liaison between eGov apps and external payment gateways facilitating payments, reconciliation of payments and lookup of transactions' status'.

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 pg service persister config path added in it

• PSQL server is running and the database is created to store transaction data.

Key Functionalities

• Create or initiate a transaction, to make a payment against a bill.

• Make payment for multiple bill details [multi module] for a single consumer code at once.

• Transaction to be initiated with a call to the transaction/_create API, various validations are carried out to ensure the sanctity of the request.

• The response includes a generated transaction id and a redirect URL to the payment gateway itself.

• Various validations are carried out to verify the authenticity of the request and the status is updated accordingly. If the transaction is successful, a receipt is generated for the same.

Payment Flow

Reconciliation

• Reconciliation is carried out by two jobs scheduled via a Quartz clustered scheduler.

• Early Reconciliation job is set to run every 15 minutes [configurable via app properties], and is aimed at reconciling transactions which were created 15 - 30 minutes ago and are in PENDING state.

• Daily Reconciliation job is set to run once per day and is aimed at reconciling all transactions that are in PENDING state, except for ones which were created 30 minutes ago.

Extensions

• Axis, Phonepe and Paytm payment gateways are implemented.

• Additional gateways can be added by implementing the Gateway interface. No changes required to the core packages.

Configuration Details

Following properties in the application.properties file in egov-pg-service has to be added and set to default value after integrating with the new payment gateway. In the below table properties for AXIS bank, payment gateway is shown the same relevant property needs to be added for other payment gateways.

Deployment Details

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

2. Add pg service persister yaml path in persister configuration

Integration Details

Integration Scope

The egov-pg-service acts as communication/contact between eGov apps and external payment gateways.

Integration Benefits

• Record of every transaction against a bill.

• Record of payment for multiple bill details for a single consumer code at once.

Steps to Integration

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

2. /pg-service/transaction/v1/_create should be added in the module to initiates a new payment transaction, on successful validation

3. /pg-service/transaction/v1/_update should be added as the update endpoint to updates an existing payment transaction. This endpoint is issued only by payment gateways to update the status of payments. It verifies the authenticity of the request with the payment gateway and forward all query params received from a payment gateway

4. /pg-service/transaction/v1/_search should be added as the search endpoint for retrieving the current status of a payment in our system.

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)

Overview

The URL shortening service is used to shorten long URLs. There may be requirement when we want to avoid sending very long urls to the user via SMS, Whatsapp etc, this service compresses the URL.

Pre-requisites

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

1. Prior Knowledge of Java/J2EE

2. Prior Knowledge of SpringBoot

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

Key Functionalities

1. Compress long URLs.

2. Converted short URLs contains id, which is used by this service to identify and get longer URLs.

Deployment Details

• Deploy latest version of URL Shortening service

API Details

a) POST /egov-url-shortening/shortener

Receive long urls and converts them to shorter urls. Shortened urls contains urls to endpoint mentioned next. When user clicks on shortened URL, user is redirected to long URL.

b) GET /{id}

This shortened urls contains path to this endpoint. The service uses id used in last endpoint to get long URL. As response the user is redirected to long URL.

Reference Docs

Doc Links

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

• BPA Service

This section provides technical details about business service setup, configuration, deployment, and API integration.

Details coming soon...

Details will be updated soon...

Overview

DIGIT is API based Platform here each API is denoting to a DIGIT resource. Access Control Service (ACS) primary job is to authorise end-user based on their roles and provide access to the DIGIT platform resources. Access control functionality basically works based on below points:

Actions: Actions are events which are performed by a user. This can be an API end-point or Frontend event. This is MDMS master

Roles: Role are assigned to the user, a user can hold multiple roles. Roles are defined in MDMS masters.

Role-Action: Role actions are mapping b/w Actions and Roles. Based on role, action mapping access control service identifies applicable action for the role.

Pre-requisites

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

• Java 8

• MDMS service is up and running

Key Functionalities

• Serve the applicable actions for a user based on user role (To print menu three).

• On each action which is performed by a user, access control looks at the roles for the user and validate actions mapping with the role.

• Support tenant-level role-action. For instance, an employee from Amritsar can have a role of APPROVER for other ULB like Jalandhar and hence will be authorised to act as APPROVER in Jalandhar.

Deployment Details

1. Deploy the latest version of Access Control Service

2. Deploy MDMS service to fetch the Role Action Mappings

Configuration Details

Define the roles

{
      "code": "EMPLOYEE",
      "name": "Employee",
      "description": "Default role for all employees"
}

Add the Actions (URL)

{
      "id": {{ACTION_ID}},
      "name": "Create TradeLicense",
      "url": "/tl-services/v1/_create",
      "parentModule": "",
      "displayName": "Create TradeLicense",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "tl-services",
      "code": "null",
      "path": ""
}

Add the role action mapping

{
      "rolecode": "EMPLOYEE",
      "actionid": {{ACTION_ID}},
      "actioncode": "",
      "tenantId": "pb"
    }

(The details about the fields in the configuration can be found in the swagger contract)

Integration Details

Integration Scope

Any microservice which requires authorisation can leverage the functionalities provided by access control service.

Integration Benefits

Any new microservice that is to be added in the platform won’t have to worry about authorisation. It can just add it’s role action mapping in the master data and Access Control Service will perform authorisation whenever API for the microservice is called.

Steps to Integration

1. To integrate with Access Control Service the role action mapping has to be configured(added) in the MDMS service.

2. The service needs to call /actions/_authorize API of Access Control Service to check for authorisation of any request

Interaction Diagram

Reference Docs

Doc Links

API List

Overview

Indexer service runs as a separate service. This service is designed to perform all the indexing tasks of the digit platform. The service reads records posted on specific kafka topics and picks the corresponding index configuration from the yaml file provided by the respective module. Objective of Indexer service are listed as below.

• To provide a one stop framework for indexing the data to elasticsearch.

• To create provision for indexing live data, reindexing from one index to the other and indexing legacy data from the datastore.

Pre-requisites

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

1. Prior Knowledge of Java/J2EE

2. Prior Knowledge of SpringBoot

3. Prior Knowledge of Elasticsearch

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

5. Prior Knowledge of Kafka and related concepts like Producer, Consumer, Topic etc.

Key Functionalities

• Performs three major tasks namely: LiveIndex, Reindex and LegacyIndex.

• LiveIndex: Task of indexing the live transaction data on the platform. This keeps the es data in sync with the db.

• Reindex: Task of indexing data from one index to the other. ES already provides this feature, indexer does the same but with data transformation.

• LegacyIndex: Task of indexing legacy data from the tables to ES.

• Provides flexibility to index the entire object, a part of the object or an entirely different custom object all using one input json from modules.

• Provides features for customizing index json by field mapping, field masking, data enrichment through external APIs and data denormalization using MDMS.

• One stop shop for all the es index requirements with easy-to-write and easy-to-maintain configuration files.

• Designed as a consumer to save API overhead. The consumer configs are written from scratch to have complete control over the consumer behaviour.

Deployment Details

• Step 1: Write configuration as per your requirement. Structure of the config file is explained later in the same doc.

• Step 2: Check-in the config file to a remote location preferably github, currently we check the files into this folder https://github.com/egovernments/configs/tree/DEV/egov-indexer -for dev

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

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

Interaction Diagram

Configuration Details

For Indexer Configuration, please refer to the document in Reference Docs table given below.

API Details

a) POST /{key}/_index

Receive data and index. There should be a mapping with topic as {key} in index config files.

b) POST /_reindex

This is used to migrate data from one index to another index

c) POST /_legacyindex

This is to run LegacyIndex job to index data from DB. In the request body the URL of the service which would be called by indexer service to pick data, must be mentioned.

Reference Docs

Doc Links

Swagger Documentation

Overview

One of the applications in the Digit core group of services aims to reduce the time spent by developers on writing codes to store and fetch master data ( primary data needed for module functionality ) which doesn’t have any business logic associated with them. Instead of writing APIs, creating tables in every different service to store and retrieve data that is seldom changed MDMS service keeps them at a single location for all modules and provides data on will with the help of no more than three lines of configuration.

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. Advanced knowledge on how to operate JSON data would be an added advantage to understand the service.

Key Functionalities

• Adds master data for usage without the need to create master data APIs in every module.

• Reads data from GIT directly with no dependency on any database services.

Deployment Details

1. Deploy the latest version of Mdms-service

2. Add conf path for the file location

3. Add master config JSON path

Integration Details

Integration Scope

The MDMS service provides ease of access to master data for any service.

Integration Benefits

• No time spent writing repetitive codes with no business logic.

Steps to Integration

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

2. egov-mdms-service/v1/_search should be added as the search endpoint for searching master data.

3. Mdms client from eGov snapshots should be added as mvn entity in pom.xml for ease of access since it provides mdms request pojos.

Reference Docs

API List

Overview

Workflows are a series of steps that moves a process from one state to another state by actions performed by different kind of Actors - Humans, Machines, Time based events etc. to achieve a goal like onboarding an employee, or approve an application or grant a resource etc. The egov-workflow-v2 is a workflow engine which helps in performing these operations seamlessly using a predefined 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 workflow persister config path added in it

• PSQL server is running and database is created to store workflow configuration and data

Key Functionalities

• Always allow anyone with a role in the workflow state machine to view the workflow instances and comment on it

• On the creation of workflow, it will appear in the inbox of all employees that have roles that can perform any state transitioning actions in this state.

• Once an instance is marked to an individual employee it will appear only in that employee's inbox although point 1 will still hold true and all others participating in the workflow can still search it and act if they have necessary action available to them

• If the instance is marked to a person who cannot perform any state transitioning action, they can still comment/upload and mark to anyone else.

• Overall SLA: SLA for the complete processing of the application/Entity

• State-level SLA: SLA for a particular state in the workflow

Interaction Diagram

Deployment Details

1. Deploy the latest version of egov-workflow-v2 service

2. Add businessService persister yaml path in persister configuration

3. Add Role-Action mapping for BusinessService API’s

4. Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)

5. Create businessService (workflow configuration) according to product requirements

6. Add Role-Action mapping for /processInstance/_search API

7. Add workflow persister yaml path in persister configuration

Configuration Details

For Configuration details please refer to the links in Reference Docs

Integration Details

Integration Scope

The workflow configuration can be used by any module which performs a sequence of operations on an application/Entity. It can be used to simulate and track processes in organisations to make it more efficient too and increase accountability.

Integration Benefits

• Role-based workflow

• An easy way of writing rule

• File movement within workflow roles

Steps to Integration

1. To integrate, host of egov-workflow-v2 should be overwritten in helm chart

2. /process/_search should be added as the search endpoint for searching workflow process Instance object.

3. /process/_transition should be added to perform an action on an application. (It’s for internal use in modules and should not be added in Role-Action mapping)

4. The workflow configuration can be fetched by calling _search API to check if data can be updated or not in the current state

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)

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

1. Add MDMS configs required for Trade License and BPA stakeholder registration and restart MDMS service

2. Deploy the latest version of tl-services service

3. Add tl-service persister yaml path in persister configuration and restart persister service

4. Add Role-Action mapping for API’s

5. Create businessService (workflow configuration) according to trade license and stakeholder registration

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

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

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

2. {servicename}/_create/ _create should be added as the create endpoint for creating any license in the system

3. {servicename}/_search/ _search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria

4. {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

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

Description

BPA application and BPA Occupancy Certificate application has Fee involved. Based on the Application Type, RiskType and ServiceType Fee to be calculated and generates a demand for the calculated amount for Payment. This service used to generate Application Fee, Sanction Fee, Low Application Permit Fee, Deviation Charges for BPA application and Occupancy Certificate Application.

System Requirements

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

• Knowledge of Spring Boot and spring-boot microservices.

• Knowledge of Git or any version control system.

• Knowledge of RESTful Web services.

• Knowledge of the Lombok library will helpful.

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

Functionality

bpa calculator services present in municipal services provide multiple functionalities like calculating Application Fee, Sanction Fee, Low Permit Fee, OC Deviation Charges, generating demands for a particular BPA, BPA OC applications, updating demands, The different functionalities provided by sewerage calculator services are:

Setup and usage

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

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

Application.properties File Information

• Business service codes for

  • BPA High/Medium Risk Application Fee

    • egov.demand.appl.businessservice=BPA.NC_APP_FEE

  • BPA High/Medium Risk Sanction Fee

    • egov.demand.sanc.businessservice=BPA.NC_SAN_FEE

  • BPA Low Risk Permit Fee

    • egov.demand.lowriskpermit.businessservice=BPA.LOW_RISK_PERMIT_FEE

  • BPA OC Application Fee

    • egov.demand.oc.appl.businessservice=BPA.NC_OC_APP_FEE

  • BPA OC Sanction Fee

    • egov.demand.oc.sanc.businessservice=BPA.NC_OC_SAN_FEE

• Tax Head Code for

  • BPA High/Medium Risk Application Fee

    • egov.appl.fee=BPA_APPL_FEES

  • BPA High/Medium Risk Sanction Fee

    • egov.sanc.fee= BPA_SANC_FEES

  • BPA Low Risk Sanction Fee

    • egov.low.sanc.fee= BPA_LOW_SANC_FEES

  • BPA Low Risk Application Fee

    • egov.low.appl.fee=BPA_LOW_APPL_FEES

  • BPA OC Application Fee

    • egov.oc.appl.fee=BPA_OC_APPL_FEES

  • BPA OC Sanction Fee

    • egov.oc.sanc.fee= BPA_OC_SANC_FEES

External Application references

• dcr-services (Use Edcr data )

• egov-mdms ( Configurations/master by MDMS )

• billing-service ( Generate and update demands )

• bpa-services (Get the bpa application data for fee calculation )

API Information

• bpa-calculator/v1/_calculate End point to calculate the Fee and create Demand with the applicable businessService and TaxHeads

MDMS Configuration:

Access MDMS Config

bpa-calculator cannot be accessed publicly, Only called by the bpa-calculator

Billing Service MDMS Config

BusinessService.json

BusinessService Config for Fee’s to be collected

Application Fee, Sanction Fee BPA High/Medium Risk

 {
      "businessService": "BPA.NEWCONSTRUCTION_APP_FEE",
      "code": "BPA.NC_APP_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },
    {
      "businessService": "BPA.NEWCONSTRUCTION_SANC_FEE",
      "code": "BPA.NC_SAN_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },

Application Fee, Sanction Fee for BPA Low Risk

{
      "businessService": "BPA.NEWCONSTRUCTION_LOW_RISK_PERMIT_FEE",
      "code": "BPA.LOW_RISK_PERMIT_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },

Application Fee, Sanction Fee for BPA OC

{
      "businessService": "BPA.NEWCONSTRUCTION_OC_APP_FEE",
      "code": "BPA.NC_OC_APP_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },
    {
      "businessService": "BPA.NEWCONSTRUCTION_OC_SANC_FEE",
      "code": "BPA.NC_OC_SAN_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    }

TaxHead MDMS

TaxHeader.json

Tax Head for BPA High/Medium Risk

{
      "category": "FEE",
      "service": "BPA.NC_APP_FEE",
      "name": "BPA Application fees",
      "code": "BPA_APPL_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },
    {
      "category": "FEE",
      "service": "BPA.NC_SAN_FEE",
      "name": "BPA Sanction fees",
      "code": "BPA_SANC_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "2",
      "isRequired": false
    },

TaxHead config for BPA Low Risk

 {
      "category": "FEE",
      "service": "BPA.LOW_RISK_PERMIT_FEE",
      "name": "BPA Low Risk Appllication Fees",
      "code": "BPA_LOW_APPL_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },
    {
      "category": "FEE",
      "service": "BPA.LOW_RISK_PERMIT_FEE",
      "name": "BPA Low Risk Permit Fees",
      "code": "BPA_LOW_SANC_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },

TaxHead config for BPA OC

 {
      "category": "FEE",
      "service": "BPA.NC_OC_APP_FEE",
      "name": "BPA Application fees",
      "code": "BPA_OC_APPL_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },
    {
      "category": "FEE",
      "service": "BPA.NC_OC_SAN_FEE",
      "name": "BPA Sanction fees",
      "code": "BPA_OC_SANC_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "2",
      "isRequired": false
    },

TaxPeriod MDMS Config

TaxPeriod.json

TaxPeriod MDMS for BPA High/Medium Risk

{
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_APP_FEE",
      "code": "BPA10YRS2018",
      "financialYear": "2018-28"
    },
    {
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_SAN_FEE",
      "code": "BPA10YRS2018",
      "financialYear": "2018-28"
    },

TaxPeriod MDMS for BPA Low Risk

{
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.LOW_RISK_PERMIT_FEE",
      "code": "BPA10YRS2018",
      "financialYear": "2018-28"
    },

TaxPeriod Config for BPA OC

{
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_OC_APP_FEE",
      "code": "BPAOCAPP10YRS2018",
      "financialYear": "2018-28"
    },
    {
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_OC_SAN_FEE",
      "code": "BPAOCSAN10YRS2018",
      "financialYear": "2018-28"
    }

Workflow

NA

Persister configuration

NA

Database Schema

NA

Notifications

NA

PDF Configuration

NA

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

1. Deploy the latest version of pgr-services

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

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

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

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

1. Customer can raise a complaint using the /requests/_create.

2. Organisation or System can search the complaint using /requests/_searchendpoint.

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

Description

Construction or renovation of buildings is regulated by Municipal Body in India. One must get permission from the ULB prior to construction. This process involves submitting the building plan to ULB along with other documents, ULB verifies the plan with other documents and approves the construction. The document which authorizes the construction is called “Permit Order” One must have this permit order with him till the completion of construction. ULB officials will inspect various stages of construction and make sure it is compliance with the plan. When construction completed, after inspection Secretary provides “Completion certificate” and finally will provide “Occupancy Certificate”. This entire process is known as “Building Plan Approval”.

Functionality

This section covers the high-level details of the functionalities available in the Building Plan Application system.

• Centralized login page for citizen, official and stakeholders

• Citizen functionalities

• Online application submission - New construction

• Occupancy certificate request

• FieldInspection Report Capture

• Pay fee online and generate permit order online

• Inspection of applications and online status

• Configurable workflow

• Auto fee calculation

• Online and offline payment collection

• Rejection process

• Revocation process

• Configurable functionalities

System Requirements

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

• Knowledge of Spring Boot and spring-boot microservices

• Knowledge of Git or any version control system

• Knowledge of RESTful Web services

• Knowledge of the Lombok library will helpful

• knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-sms, eGov-email,eGov-user, eGov-localization, eGov-workflow-service,dcr, land-services, bpa-calculator will be helpful

Setup and usage

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

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

API Information

• Please refer to Swagger API for YAML file details. Link - API Specs.

Application.properties File Information

Here we are listing the configs apart from dependent service host, URLs, DB and Flyway configs.

• kafka topics persister configs for eGov persister to save and update BPA Data

  • persister.save.buildingplan.topic=save-bpa-buildingplan

  • persister.update.buildingplan.topic=update-bpa-buildingplan

  • persister.update.buildingplan.workflow.topic=update-bpa-workflow

  • persister.update.buildingplan.adhoc.topic=update-bpa-adhoc-buildingplan

• Receipt kafka topics where BPA application listens to move the application Status after payment completion

  • kafka.topics.receipt.create=egov.collection.payment-create

• Config for Demand Business service codes for different fees to be paid for BPA

  • egov.receipt.businessservice=

    • BPA.NC_APP_FEE := Building Plan Approval Application Fee

    • BPA.NC_SAN_FEE := Building Plan Approval Sanction Fee

    • BPA.LOW_RISK_PERMIT_FEE := Building Plan Approval Low Risk Permit Fee

    • BPA.NC_OC_APP_FEE := Building Plan Approval Occupancy Certificate Application Fee

    • BPA.NC_OC_SAN_FEE := Building Plan Approval Occupancy Certificate Sanction Fee

• Application and Permit Number Formats

  • egov.idgen.bpa.applicationNum.format=PB-BP-[cy:yyyy-MM-dd]-[SEQ_EG_BP_APN]

  • egov.idgen.bpa.permitNum.format=PB-BP-[cy:yyyy-MM-dd]-[SEQ_EG_BP_PN]

• SMS Notification Topic to push the SMS and Notification’s to be sent by BPA module

  • kafka.topics.notification.sms=egov.core.notification.sms

• Payment Notification Config

  • egov.ui.app.host=https://egov-micro-dev.egovernments.org

  • egov.usr.events.create.topic=persist-user-events-async

  • egov.usr.events.pay.link=citizen/otpLogin?mobileNo=$mobile&redirectTo=egov-common/pay?consumerCode=$applicationNo&tenantId=$tenantId&businessService=$businessService

  • egov.usr.events.pay.code=PAY

• List of Application Statuses on which payment notification to be sent

  • egov.usr.events.pay.triggers=PENDING_SANC_FEE_PAYMENT,PENDING_APPL_FEE,PENDING_FEE

• Validity of the permit order generated in no of months

  • egov.bpa.validity.date.in.months=36

• Workflow code for the combination of applicationType , ServiceType

  • appSrvTypeBussSrvCode={"BUILDING_PLAN_SCRUTINY":{"NEW_CONSTRUCTION":"BPA,BPA_LOW"},"BUILDING_OC_PLAN_SCRUTINY":{"NEW_CONSTRUCTION":"BPA_OC"}}

• Application Status on which SKIP_PAYMENT action to be considered

  • egov.bpa.skippayment.status=PENDING_APPL_FEE,PENDING_SANC_FEE_PAYMENT,PENDING_FEE

• Business Service Code for WorkflowCode and Application Status

  • workflowStatusFeeBusinessSrvMap={"BPA":{"PENDING_APPL_FEE":"BPA.NC_APP_FEE","PENDING_SANC_FEE_PAYMENT":"BPA.NC_SAN_FEE"},"BPA_LOW":{"PENDING_FEE":"BPA.LOW_RISK_PERMIT_FEE"},"BPA_OC":{"PENDING_APPL_FEE":"BPA.NC_OC_APP_FEE","PENDING_SANC_FEE_PAYMENT":"BPA.NC_OC_SAN_FEE"}}

• NOC application Integration configs

  • Config to validate the status of applicable noc’s status to allow application to move forward from NOC_VERIFICATION_PENDING Workflow State

    • validate.required.nocs.statuses=APPROVED,AUTO_APPROVED,REJECTED,VOIDED

  • NOC workflow initiate action code to initiate the workflow of the NOC when appliation reachers the respective nocTrigerState

    • egov.noc.initiate.action=INITIATE

  • NOC workflow void action code to void the applicable NOC’s, when the application moved to REJECTED State

    • egov.noc.void.action=VOID

  • NOC workflow action goes for AutoAprove to auto-approve offline NOC , while moving from NOC_VERIFICATION_PENDING to next state

    • egov.noc.autoapprove.action=AUTO_APPROVE

External API References

• egov-user - (Manage user)

• tl-services - Stakeholder Registration (Registration process of Stakeholder is handled by this service)

• egov-user-event (What’s New and Events)

• egov-filestore (To store the documents uploaded by the user)

• egov-idgen (To generate the application No, Permit No)

• egov-indexer (To index the BPA data)

• egov-localization (To use the localized messages)

• egov-location (To store the address locality)

• egov-mdms (Configurations/master data used in the application is served by MDMS)

• egov-notification-sms (Service to send SMS to the users involved in the application)

• egov-persister (Helps to persist the data)

• egov-searcher (Search query used to simplify the search)

• egov-workflow-v2 (Workflow configuration for different BPA application is configured)

• pdf-service (Receipt’s, permit order etc.. and prepared)

• billing-service (Create demands and bills for the fees to be collected)

• collection-services (Create a receipt for the payment received for the bills)

• bpa-calculator (Calculates the fees to be collected at different stages)

• land-services (land information related to BPA application is stored)

• dcr-services (get and validate EDCR data)

• noc-services (NOC application)

Configuration

BPA Specific Mdms configuration

MDMS Github Repo

Under the data/<state code> folder you can find the BPA which has all the MDMS JSON’s

master-config.json for BPA

"BPA": {
    "ServiceType": {
      "masterName": "ServiceType",
      "isStateLevel": true,
      "uniqueKeys": [
        "$.code"
      ]
    },
    "ApplicationType": {
      "masterName": "ApplicationType",
      "isStateLevel": true,
      "uniqueKeys": [
        "$.code"
      ]
    },
    "DocTypeMapping": {
      "masterName": "DocTypeMapping",
      "isStateLevel": true,
      "uniqueKeys": [
        "$.code"
      ]
    },
    "CalculationType": {
      "masterName": "CalculationType",
      "isStateLevel": true,
      "uniqueKeys": []
    },
    "RiskTypeComputation": {
      "masterName": "RiskTypeComputation",
      "isStateLevel": true,
      "uniqueKeys": []
    },
    "OccupancyType": {
      "masterName": "OccupancyType",
      "isStateLevel": true,
      "uniqueKeys": [
        "$.code"
      ]
    },
    "SubOccupancyType": {
      "masterName": "SubOccupancyType",
      "isStateLevel": true,
      "uniqueKeys": [
        "$.code"
      ]
    },
    "CheckList": {
      "masterName": "CheckList",
      "isStateLevel": true,
      "uniqueKeys": [
        "$.question"
      ]
    }
  }

MDMS Details

Access MDMS Config

Action Test : URL Actions adding

action-test.json``

  {
      "id": 1971,
      "name": "BPA-PermitOrderEDCR Report",
      "url": "/bpa-services/v1/bpa/_permitorderedcr",
      "displayName": "Apply",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "BPA",
      "code": "null",
      "path": ""
    }, {
      "id": 1975,
      "name": "Locality searcher endpoint for BPA",
      "url": "/egov-searcher/locality/bpa-services/_get",
      "displayName": "BPA locality searcher",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "egov-searcher",
      "code": "null",
      "path": ""
    },{
      "id": 1924,
      "name": "BPA-Applyforservice",
      "url": "/bpa-services/v1/bpa/_create",
      "displayName": "Apply",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "BPA",
      "code": "null",
      "path": ""
    }, {
      "id": 1930,
      "name": "BPA-applicationsearch",
      "url": "/bpa-services/v1/bpa/_search",
      "displayName": "Search",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "BPA",
      "code": "null",
      "path": ""
    },{
      "id": 1931,
      "name": "BPA-updateapplicationservice",
      "url": "/bpa-services/v1/bpa/_update",
      "displayName": "Apply",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "BPA",
      "code": "null",
      "path": ""
    },

Access to the Roles for the above Actions

roleacton.json``

{
      "rolecode": "CEMP",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_TOWNPLANNER",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_BUILDER",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_STRUCTURALENGINEER",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_SUPERVISOR",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_VERIFIER",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_FIELD_INSPECTOR",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_NOC_VERIFIER",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_APPROVER",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_ARCHITECT",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "CITIZEN",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_ENGINEER",
      "actionid": 1971,
      "actioncode": "",
      "tenantId": "pb"
    },
     {
      "rolecode": "BPA_VERIFIER",
      "actionid": 1975,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_FIELD_INSPECTOR",
      "actionid": 1975,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_NOC_VERIFIER",
      "actionid": 1975,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_APPROVER",
      "actionid": 1975,
      "actioncode": "",
      "tenantId": "pb"
    },
     {
      "rolecode": "BPA_ARCHITECT",
      "actionid": 1924,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_ARCHITECT",
      "actionid": 1931,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "CITIZEN",
      "actionid": 1931,
      "actioncode": "",
      "tenantId": "pb"
    }, {
      "rolecode": "BPA_VERIFIER",
      "actionid": 1931,
      "actioncode": "",
      "tenantId": "pb"
    }, {
      "rolecode": "BPA_APPROVER",
      "actionid": 1931,
      "actioncode": "",
      "tenantId": "pb"
    },
     {
      "rolecode": "BPA_FIELD_INSPECTOR",
      "actionid": 1931,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_NOC_VERIFIER",
      "actionid": 1931,
      "actioncode": "",
      "tenantId": "pb"
    },{
      "rolecode": "BPA_ARCHITECT",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },{
      "rolecode": "BPA_VERIFIER",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "CEMP",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_APPROVER",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },  {
      "rolecode": "CITIZEN",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    }, {
      "rolecode": "BPA_FIELD_INSPECTOR",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_NOC_VERIFIER",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },{
      "rolecode": "AIRPORT_AUTHORITY_APPROVER",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "FIRE_NOC_APPROVER",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "NOC_DEPT_APPROVER",
      "actionid": 1930,
      "actioncode": "",
      "tenantId": "pb"
    }

Billing Service MDMS Config

BusinessService.json

BusinessService Config for Fee’s to be collected

Application Fee, Sanction Fee BPA High/Medium Risk

 {
      "businessService": "BPA.NEWCONSTRUCTION_APP_FEE",
      "code": "BPA.NC_APP_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },
    {
      "businessService": "BPA.NEWCONSTRUCTION_SANC_FEE",
      "code": "BPA.NC_SAN_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },

Application Fee, Sanction Fee for BPA Low Risk

{
      "businessService": "BPA.NEWCONSTRUCTION_LOW_RISK_PERMIT_FEE",
      "code": "BPA.LOW_RISK_PERMIT_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },

Application Fee, Sanction Fee for BPA OC

{
      "businessService": "BPA.NEWCONSTRUCTION_OC_APP_FEE",
      "code": "BPA.NC_OC_APP_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    },
    {
      "businessService": "BPA.NEWCONSTRUCTION_OC_SANC_FEE",
      "code": "BPA.NC_OC_SAN_FEE",
      "collectionModesNotAllowed": [
        "DD"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "isVoucherCreationEnabled": true,
      "isActive": true
    }

TaxHead MDMS

TaxHeader.json

Tax Head for BPA High/Medium Risk

{
      "category": "FEE",
      "service": "BPA.NC_APP_FEE",
      "name": "BPA Application fees",
      "code": "BPA_APPL_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },
    {
      "category": "FEE",
      "service": "BPA.NC_SAN_FEE",
      "name": "BPA Sanction fees",
      "code": "BPA_SANC_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "2",
      "isRequired": false
    },

TaxHead config for BPA Low Risk

 {
      "category": "FEE",
      "service": "BPA.LOW_RISK_PERMIT_FEE",
      "name": "BPA Low Risk Appllication Fees",
      "code": "BPA_LOW_APPL_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },
    {
      "category": "FEE",
      "service": "BPA.LOW_RISK_PERMIT_FEE",
      "name": "BPA Low Risk Permit Fees",
      "code": "BPA_LOW_SANC_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },

TaxHead config for BPA OC

 {
      "category": "FEE",
      "service": "BPA.NC_OC_APP_FEE",
      "name": "BPA Application fees",
      "code": "BPA_OC_APPL_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "1",
      "isRequired": false
    },
    {
      "category": "FEE",
      "service": "BPA.NC_OC_SAN_FEE",
      "name": "BPA Sanction fees",
      "code": "BPA_OC_SANC_FEES",
      "isDebit": false,
      "isActualDemand": true,
      "order": "2",
      "isRequired": false
    },

TaxPeriod MDMS Config

TaxPeriod.json

TaxPeriod MDMS for BPA High/Medium Risk

{
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_APP_FEE",
      "code": "BPA10YRS2018",
      "financialYear": "2018-28"
    },
    {
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_SAN_FEE",
      "code": "BPA10YRS2018",
      "financialYear": "2018-28"
    },

TaxPeriod MDMS for BPA Low Risk

{
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.LOW_RISK_PERMIT_FEE",
      "code": "BPA10YRS2018",
      "financialYear": "2018-28"
    },

TaxPeriod Config for BPA OC

{
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_OC_APP_FEE",
      "code": "BPAOCAPP10YRS2018",
      "financialYear": "2018-28"
    },
    {
      "fromDate": 1522540801000,
      "toDate": 1838159999000,
      "periodCycle": "FORTENYEARS",
      "service": "BPA.NC_OC_SAN_FEE",
      "code": "BPAOCSAN10YRS2018",
      "financialYear": "2018-28"
    }

ID Gen Config for BPA Numbers

idFormats.json

BPA Application Number format Config

{
      "idname":"egov.idgen.bpa.applicationNum",
      "format":"PB-BP-[cy:yyyy-MM-dd]-[SEQ_EG_BP_APN]"
    },

BPA Permit Number format Config

{
      "idname":"egov.idgen.bpa.applicationNum",
      "format":"PB-BP-[cy:yyyy-MM-dd]-[SEQ_EG_BP_PN]"
    },

BPA Receipt Number format config

 {
      "format": "BPA/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]",
      "idname": "bpa.nc_app_fee.receipt.id"
    },
    {
      "format": "BPA/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]",
      "idname": "bpa.nc_san_fee.receipt.id"
    },

BPA OC Receipt Number format config

  {
      "format": "BPA/OC/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]",
      "idname": "bpa.nc_oc_app_fee.receipt.id"
    },
    {
      "format": "BPA/OC/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]",
      "idname": "bpa.nc_oc_san_fee.receipt.id"
    },

Persister configuration

BPA Persister YAML

Indexer Configuration

BPA Indexer YAML

Locality Search Configuration

Setup the locality Search query in the localitySearcher.yml as a new entry. Add RoleAction Test and Role Action for the URL “/egov-searcher/locality/bpa-services/_get“

  - name: bpa-services
    query:
      baseQuery: |
        Select row_to_json(result) from
        (
          select applicationNo as referenceNumber,locality from eg_bpa_buildingplan bpa
          INNER JOIN eg_land_Address ad ON ad.landInfoId = bpa.landid
        ) result  $where
      groupBy:
      orderBy:
    searchParams:
      condition: AND
      params:
      - name: result.referenceNumber
        isMandatory: true
        jsonPath: $.searchCriteria.referenceNumber
        operator: 

    output:
      jsonFormat: {"ResponseInfo": {}}
      outJsonPath: $.Localities
      responseInfoPath: $.ResponseInfo

Database Schema

Postman Links

Postman Collection

Workflow Configuration

BPA - Building Plan Approval Apply High/Medium Risk

BPA Low – Building Plan Approval Apply Low Risk

BPA OC - Building Plan Approval Occupancy Certificate Apply

BPA and BPA OC Workflow Stages

BPA workflow configuration is for Building Plan Approval Apply High and Medium Risk Types.

BPA OC workflow configuration is for Building Plan Approval Occupancy Certificate irrespective of RiskTypes

Both the workflow flows as depicted below

In the above Flow Chart

• Rectangle Indicates the Workflow State

• Line connecting two states indicates the action

  • Action name is in black colour text

  • User Role who can take action is in Blue colour Text

Specific Configurations and How To’s

• System allows configuring the Documents that can be visible, allowed to upload and Mandatory to move from the current state in DocumentTypeMapping MDMS as described in MDMS Details Table DocumentTypeMapping Row

• Application Creation Sage

  • Process

    • DCR system is integrated to get the applicationType, serviceType and riskType based on the EDCR Number populated by the architect.

    • DCR system is integrated to validate the status of the EDCRNumber populated

    • New BPA or BPAOC application cannot be created if there is existing un ended( application status other than approved or rejected is considered as unended) application with the same EDCR

  • How To add new Document

    • Should add new documentType group in DocumentTypeMapping MDMS with the applicable applicationType, serviceType, riskType, wfState (refer existing sample for understanding)

    • Can configure allow, required as well as the order for each documentType

    • Make sure the new documentType added exists in documentType of common-masters

• Initiated Stage

  • Process

    • NOC’s from the NocTypeMapping MDMS matching to the application data will get created

  • How To add new NocType

    • Should add new NOCType in NocTypeMapping MDMS

    • New NocType should add in noc-services application as well

• Citizen Approval Pending Stage

  • Process

    • According to the example in the NocTypeMapping Data in the MDMS Details Table, Once BPA or BPA OC reaches this Staus all the Applicable Noc’s workflow would be initiated.

  • How to change NOC workflow initiation step

    • Should change the nocTriggerState in NocTypeMapping to the desired application status.

• InProgress Stage

  • Process

    • Application fee Demand gets generated by the bpa-calculator

    • Notification to the Stakeholder and owner will be sent regarding the fee payment

  • How To change the Fee Amount

    • Will be discussed in bpa-calculator service

• Document Verification Pending Stage

  • Process

    • Nothing Specific

  • How To

    • NA

• FieldInspection Pending Stage

  • Process

    • At this stage, FieldInspector should answer the checklist questions and attached the documents which will be configured in checklist MDMS, as described in MDMS Details Table CheckList Row

    • Field Inspector can create multiple FieldInspection Reports

  • How to add new questions and documents

    • Should add/modify the questions for the desired combination of applicationType, serviceType, risktype

    • with the localization code for question text

    • specify the fieldType ( ass of now only YES/NO/NA only supported )

    • Should add/modify documents for the desired combination of applicationType, serviceType, risktype

• Noc Verification Pending State

  • Process

    • NOC verifier can upload the Documents to the NOC application’s if available.

    • Offline Noc’s would get auto-approved while NOC verifier is forwarding the BPA or BPAOC application from the current state

    • BPA or BPAOC application cannot be forwarded if any NOC is not in matching the status configured for validate.required.nocs.statuses in application.properties

  • How to change the NOC application status to be verified to move forward

    • should update the validate.required.nocs.statuses property in value in application.properties with the list of status to be considered to move forward

• Approval Pending Stage

  • Process

    • Approver can select the predefined conditions for approval updated in CheckList MDMS, as described in MDMS Details Table checkList Row

    • Approver can add new conditions as well for approval

    • Sanction fee Demand gets generated by the bpa-calculator

    • Notification to the Stakeholder and owner will be sent regarding the fee payment

  • How to add/remove/modify conditions

    • Should add/modify the conditions array for the desired combination of applicationType, serviceType, riskType

• Approved Stage

  • Process

    • System generates PermitOrder for the application

    • System Stamps the validate date for the permit Order by adding the no of months configured for the property egov.bpa.validity.date.in.months in application.properties

  • How to change the validity period of the permit order which will generate from now

    • Change the value of the property egov.bpa.validity.date.in.months in application.properties file to the desired no of months

  • How to change Permit Order

    • Can be changed by changing the data and format configs of the permit order, please refer PDF’s section of Permit Order

• Rejected Stage

  • Process

    • NA

BPA LOW Workflow

BPA with riskType low has a separate workflow, which is almost same as the BPA workflow as depicted below

In the above Flow Chart

• Rectangle Indicates the Workflow State

• Line connecting two states indicates the action

  • Action name is in black colour text

  • User Role who can take action is in Blue colour Text

Specific Configurations and How To’s which are not common to BPA Workflow

• InProgress Stage

  • Process

    • Application and Sanction Fee together gets calculated and Demand gets generated by the bpa-calculator

    • Notification to the Stakeholder and owner will be sent regarding the fee payment

  • How To change the Fee Amount

    • Will be discussed in bpa-calculator service

• Document Verification Pending Stage

  • Process

    • System generates PermitOrder for the application

    • System Stamps the validate date for the permit Order by adding the no of months configured for the property egov.bpa.validity.date.in.months in application.properties

  • How to change the validity period of the permit order which will generate from now

    • Change the value of the property egov.bpa.validity.date.in.months in application.properties file to the desired no of months

• Approved Stage

  • Process

    • NA

• Revocated Stage

  • Process

    • System generates Revocation letter

  • How to change Revocation Letter format

    • Can be changed by changing the data and format configs of the revocation letter, please refer PDF’s section of Revocation letter

Validations included

• On Workflow action of Every Stage, System verifies the Documents Configured for the given stage of the workflow from the DocumentTypeMapping MDMS and validates the required Documents attached to move forward

• DropDown values to be validated against the MDMS values, Value in those fields should be one of the MDMS value.

Notifications

Notifications Message codes for SMS and User Events are prepared as follows

ApplicationType_ServiceType_WorkflowAction_ApplicationStatus.

Example BPA Apply Application (i.e applicationType is BUILDING_PLAN_SCRUTINY) with ServiceType NEW_CONSTRUCTION and the current application status is DOCUMENT_VERIFICATION_PENDING and workflow Action of the request is FORWARD then the localized message for this notification will be looked for the code: BUILDING_PLAN_SCRUTINY_NEW_CONSTRUCTION_FORWARD_DOCUMENT_VERIFICATION_PENDING

The message text for the above code is sent through SMS and Notification filling the owner, serviceType, application Number and other values.

PDFS used

BPA supports below PDF’s

Description

For every building plan application, there is a need to get the No objection certificate from concerned departments. Based on the configuration we have for the NOCs, for every application, there will be a set of NOCs required. There should be a provision to allow the NOC department user to login to our system and upload the required NOC. We are providing a user to one NOC department. Based on the workflow mode(online/offline) of each NOC type, the NOC department user can perform the action.

Online mode – NOC department user can log in to the system and approve/reject the application.

Offline mode – NOC application will be auto-approved.

System Requirements

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

• Knowledge of Spring Boot and spring-boot microservices.

• Knowledge of Git or any version control system.

• Knowledge of RESTful Web services.

• Knowledge of the Lombok library will helpful.

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

External API References

• egov-user (Manage user)

• egov-idgen (To generate the application No)

• egov-localization (To use the localized messages)

• egov-location (To store the address locality)

• egov-mdms (Configurations/master data used in the application is served by MDMS)

• egov-notification-sms (Service to send SMS to the users involved in the application)

• egov-persister (Helps to persist the data)

• egov-workflow-v2 (Workflow configuration for different BPA application is configured)