Description

This service is the major service supporting bpa-services which handles the data of the land like land details, owner information, unit, address and documents which has the complete information of the land.

Which can be used as input for the bpa-services to create and process the Building Plan Application.

Functionality

This section covers the high-level details of the functionalities available Land Service

• UI integrated as part of BPA screens

• Ability to create/update Land Details

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.

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 land-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, url’s, DB and Flyway configs.

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

  • persister.save.landinfo.topic=save-landinfo

  • persister.update.landinfo.topic=update-landinfo

External API References

• egov-user - ( Manage user )

• 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-persister ( Helps to persist the data )

Configuration

Land Service Specific MDMS configuration:

There is not MDMS config for Land Service exists as of now.

Access MDMS Config

Action Test : URL Actions adding

action-test.json``

  {
      "id": 1988,
      "name": "BPA-Land-Create",
      "url": "/land-services/v1/land/_create",
      "displayName": "Land Create",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "BPA",
      "code": "null",
      "path": ""
    },
    {
      "id": 1989,
      "name": "BPA-Land-Update",
      "url": "/land-services/v1/land/_update",
      "displayName": "Land Update",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "BPA",
      "code": "null",
      "path": ""
    },
    {
      "id": 1990,
      "name": "BPA-Land-Search",
      "url": "/land-services/v1/land/_search",
      "displayName": "Land Search",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "BPA",
      "code": "null",
      "path": ""
    },

Access to the Roles for the above Actions

roleacton.json``

{
      "rolecode": "BPA_ARCHITECT",
      "actionid": 1988,
      "actioncode": "",
      "tenantId": "pb"
    },
      {
      "rolecode": "BPA_ARCHITECT",
      "actionid": 1989,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "CITIZEN",
      "actionid": 1989,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_VERIFIER",
      "actionid": 1989,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_APPROVER",
      "actionid": 1989,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_FIELD_INSPECTOR",
      "actionid": 1989,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_NOC_VERIFIER",
      "actionid": 1989,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_FIELD_INSPECTOR",
      "actionid": 1990,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_NOC_VERIFIER",
      "actionid": 1990,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_ARCHITECT",
      "actionid": 1990,
      "actioncode": "",
      "tenantId": "pb"
    }, {
      "rolecode": "BPA_VERIFIER",
      "actionid": 1990,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "CEMP",
      "actionid": 1990,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BPA_APPROVER",
      "actionid": 1990,
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "CITIZEN",
      "actionid": 1990,
      "actioncode": "",
      "tenantId": "pb"
    }

Persister configuration

Land Persister YAML

Database Schema

Workflow Configuration

NA

Notifications

NA

PDF Used

NA

Overview

We are using re-indexing to get all the data to respective indexer. We have 2 steps for this. First as to run the connector from playground, which is followed by legacyindexer service call from indexer service, which internally call the respective plain search service to get the data and to send to respective indexer.

Prerequisites:

• Access to kubectl of the environment targetted

• Postman scripts

• Plain search apis in the respective services

OBPS reindexing steps

• Connect to playground pod.

• Delete the kafka connector if already exists with the kafka connection, using below command through playground pod.

curl --location --request DELETE 'http://kafka-connect.kafka-cluster:8083/connectors/bpa-index-enriched-es-sink'

• Run below kafka connector curl from playground pod:

curl --location --request POST 'http://kafka-connect.kafka-cluster:8083/connectors/' \
--header 'Cache-Control: no-cache' \
--header 'Content-Type: application/json' \
--header 'Postman-Token: 419e68ba-ffb9-4da9-86e1-7ad5a4c8d0b9' \
--data-raw '{
    "name": "bpa-index-enriched-es-sink",
    "config": {
        "connector.class": "io.confluent.connect.elasticsearch.ElasticsearchSinkConnector",
        "type.name": "general",
        "tasks.max": "1",
        "max.retries": "15",
        "key.ignore": "true",
        "retry.backoff.ms": "5000",
        "max.buffered.records": "25",
        "value.converter": "org.apache.kafka.connect.json.JsonConverter",
        "errors.log.enable": "true",
        "key.converter": "org.apache.kafka.connect.storage.StringConverter",
        "read.timeout.ms": "100000",
        "topics": "bpa-index-enriched",
        "batch.size": "25",
        "max.in.flight.requests": "2",
        "schema.ignore": "true",
        "behavior.on.malformed.documents": "warn",
        "flush.timeout.ms": "3600000",
        "errors.deadletterqueue.topic.name": "bpa-index-enriched-failed",
        "errors.tolerance": "all",
        "value.converter.schemas.enable": "false",
        "name": "bpa-index-enriched-es-sink",
        "connection.url": "http://elasticsearch-data-v1.es-cluster:9200",
        "linger.ms": "1000",
        "transforms": "TopicNameRouter",
        "transforms.TopicNameRouter.type": "org.apache.kafka.connect.transforms.RegexRouter",
        "transforms.TopicNameRouter.regex": "bpa-index-enriched*",
        "transforms.TopicNameRouter.replacement": "bpa-index-enriched"
    }
}'

• port forward to egov-indexer pod and run below curl throw postman.

curl --location --request POST 'http://localhost:8088/egov-indexer/index-operations/_legacyindex' \
--header 'Content-Type: application/json' \
--data-raw '{
    "RequestInfo": {
        "apiId": "string",
        "ver": "string",
        "ts": null,
        "action": "string",
        "did": "string",
        "key": "string",
        "msgId": "string",
        "authToken": "ca3256e3-5318-47b1-8a68-ffcf2228fe35",
        "correlationId": "e721639b-c095-40b3-86e2-acecb2cb6efb",
        "userInfo": {
            "id": 23299,
            "uuid": "e721639b-c095-40b3-86e2-acecb2cb6efb",
            "userName": "9337682030",
            "name": "Abhilash Seth",
            "type": "CITIZEN",
            "mobileNumber": "9337682030",
            "emailId": "abhilash.seth@gmail.com",
            "roles": [
                {
                    "id": 281,
                    "name": "Citizen"
                }
            ]
        }
    },
    "apiDetails": {
        "uri": "http://bpa-services.egov:8080/bpa-services/v1/bpa/_plainsearch",
        "tenantIdForOpenSearch": "pb",
        "paginationDetails": {
            "offsetKey": "offset",
            "sizeKey": "limit",
            "maxPageSize": 25,
            "limit": 25
        },
        "responseJsonPath": "$.BPA"
    },
    "legacyIndexTopic": "bpa-connection-legacyIndex",
    "tenantId": "pb"
}'

• Delete the kafka connection after all the data has been re-indexed by follwing below command through playground pod.

curl --location --request DELETE 'http://kafka-connect.kafka-cluster:8083/connectors/bpa-index-enriched-es-sink'

• Alias water-services-enriched as water-services through kibana server.

POST /_aliases 
{
  "actions": [
    {
      "add": {
        "index": "bpa-index-enriched",
        "alias": "bpa-index"
      }
    }
  ]
}

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

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 in compliance with the plan. When construction completed, after inspection Secretary provides a “Completion certificate” and finally will provide an “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

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

API Information

Application.properties File Information

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 the 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 the 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 the 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

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

master-config.json for BPA

MDMS Details

Access MDMS Config

Action Test : URL Actions adding

Access to the Roles for the above Actions

Billing Service MDMS Config

BusinessService Config for Fee’s to be collected

Application Fee, Sanction Fee BPA High/Medium Risk

Application Fee, Sanction Fee for BPA Low Risk

Application Fee, Sanction Fee for BPA OC

TaxHead MDMS

Tax Head for BPA High/Medium Risk

TaxHead config for BPA Low Risk

TaxHead config for BPA OC

TaxPeriod MDMS Config

TaxPeriod MDMS for BPA High/Medium Risk

TaxPeriod MDMS for BPA Low Risk

TaxPeriod Config for BPA OC

ID Gen Config for BPA Numbers

BPA Application Number format Config

BPA Permit Number format Config

BPA Receipt Number format config

BPA OC Receipt Number format config

Persister configuration

Indexer Configuration

Locality Search Configuration

Database Schema

Postman Links

Workflow Configuration

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
• 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 to PDFs section of Permit Order

• Rejected Stage

  • Process

    • NA

BPA LOW Workflow

BPA with risk Type low has a separate workflow, which is almost the 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 in 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 the 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)

API Information

Workflow Configuration

Fire Noc: Off-Line configuration

Airport Authority Noc: Off-Line configuration

Fire Noc: online configuration

Airport Authority: online configuration

Database Schema

Notifications

NA

PDF’s Used

NA

Overview

The Stakeholder registration process is done to allow any user access to the Building plan approval portal. The user registers the application for the desired role. Upon approval of the application, the user gets the role based on the application. This role will be stake level role. The user can also register on behalf of the organisation.

License types: Engineer, Town Planner, Builder, Architect, Structural Engineer

Actors: Citizen, Document Verifier, Approver

States of any application: Initiated, Pending for payment, Pending for document verification, Pending for approval, Approved, Rejected

Promotion Steps

Backend

Promote latest MDMS

MDMS

• TradeLicense:- added type field in existing records and added new trade types

• StakeholderRegistraition:- Contains additional information for each of the trade types being used in BPA registration

Endpoints:

Please whitelist the endpoint from Zuul wherever required

• /tl-services/v1/BPAREG/_create:- mixed (both whitelisted and auth based)

• /tl-services/v1/BPAREG/_update:- mixed (both whitelisted and auth based)

Auth based access:- CITIZEN,BPAREG_DOC_VERIFIER, BPAREG_EMPLOYEE, BPAREG_APPROVER

• /tl-services/v1/BPAREG/_search :- Citizen, Approver, Document Verifier

• /tl-calculator/v1/BPAREG/_getbill:- mixed (both whitelisted and auth based)

Auth based access:- CITIZEN,BPAREG_DOC_VERIFIER, BPAREG_EMPLOYEE, BPAREG_APPROVER

Users:

• Create users with state level roles(tenantId=’pb’) , BPAREG_DOC_VERIFIER, EMPLOYEE, BPAREG_APPROVER

• Create an anonymous user(related to whitelisting). Please refer to the end of this doc

• Workflow config file -

Service Builds (use these or newer builds from master)

• Billing-service-5f944c55c5-4dqcx

• TL-service: tl-services-db:42-bpa-work-9371fe2

• TL-calculator: tl-calculator-db:10-bpa-work-128d676

• Citizen - citizen:210-Nov-15-Release-49699801

• Employee - employee:238-Nov-15-Release-49699801

• Zuul: zuul:21-master-5368046

• Workflow: egov-workflow-v2:9-WF_MULTITENANCY-40d533f

• Restart user and encryption service

Persister Config

Localisation File:

SQL Query:

Please run the below SQL script to add state-level bank account:

insert into egf_bank ( id,code,name,active,tenantid) values ( '23','AXIS','AXIS BANK',t,'pb')

insert into egf_bankbranch(id,bankid,code,name,address,city,state,contactperson,active,createddate ,lastmodifieddate,tenantid) values ('8','23','123','Axis_Bank_Ltd_Punjab','Amritsar','Amrisar','Punjab','ABCD','t','2019-08-16 21:04:32.064' ,'2019-08-16 21:04:32.064','pb')

insert into egf_bankaccount(id,bankbranchid ,chartofaccountid,fundid , accountnumber,accounttype , active ,type, createddate, lastmodifieddate ,tenantid) values ('8','123','1234','12', '91101055559123', 'SAVINGS' ,'t' ,'RECEIPTS_PAYMENTS', '2018-08-16 21:24:48.837','2018-08-16 21:24:48.837','pb')

Add ANONYMOUS role and create a system user as given below

{
 "requestInfo": {
   "apiId": "Rainmaker",
   "ver": ".01",
   "ts": null,
   "action": "_update",
   "did": "1",
   "key": "",
   "msgId": "20170310130900|en_IN",
   "authToken": "5a445d2c-c742-4e07-aaac-2a11e06830fc",
   "userInfo": {
     "id": 301,
     "userName": "EMP10",
     "name": "Employee 10",
     "type": "EMPLOYEE",
     "mobileNumber": "9999405321",
     "emailId": "",
     "roles": [
       {
         "id": 58,
         "name": "Employee",
         "code": "EMPLOYEE"
       }
     ],
     "tenantId": "pb.amritsar",
     "uuid": "dbbb4668-3bba-4f37-8fff-d072b84eb01b"
   }
 },
 "user": {
   "userName": "SYSTEM1",
   "name": "System User",
   "gender": null,
   "mobileNumber": "9191919191",
   "type": "SYSTEM",
   "roles": [
     {
       "id": null,
       "name": "Anonymous User",
       "code": "ANONYMOUS",
       "description": null,
       "createdBy": null,
       "createdDate": null,
       "lastModifiedBy": null,
       "lastModifiedDate": null,
       "tenantId": null
     },
    {
       "id": null,
       "name": "Employee",
       "code": "EMPLOYEE",
       "description": null,
       "createdBy": null,
       "createdDate": null,
       "lastModifiedBy": null,
       "lastModifiedDate": null,
       "tenantId": ‘pb“
     }
   ],
   "tenantId": "pb"
 }
}

https://egov-micro-qa.egovernments.org/user/users/_createnovalidate

Overview

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

As this revolves around a variety of data sets, there is a need for making this configurable. So that, tomorrow, given a new scenario is introduced, it is just a configuration away from getting the newly introduced scenario involved in this flow of the process.

This document explains the steps on how to define the configurations for the analytics side Of DSS for OBPS.

What is analytics?

Analytics: Micro Service which is responsible for building, fetching, aggregating and computing the Data on ElasticSearch to a consumable Data Response. Which shall be later used for visualizations and graphical representations.

Analytics Configurations: Analytics contains multiple configurations. we need to add the changes related to OBPS in this dashboard analytics. Here is the location :

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

1. Chart API Configuration

2. Master Dashboard Configuration

3. Role Dashboard Mappings Configuration

Configuration Details

Chart API Configuration

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

In order to configure each visualization and its properties, we have a Chart API configuration document.

In this, visualization code, which happens to be the key, will have its properties configured as a part of the configuration and easily changeable.

Below is the sample ChartApiConfiguration.json data for the OBPS.

Master Dashboard Configuration

Master dashboard configuration is the main configuration which defines which Dashboards are to be painted on screen.

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

Role Dashboard Mappings Configuration

Master dashboard configuration which was explained earlier hold the list of Dashboards which are available. Given the instance where Role Action Mapping is not maintained in the application service, this configuration acts as the Role-Dashboard mapping configuration.

In this, each role is mapped against the dashboard which they are authorized to see. This was used earlier when the role action mapping of eGov was not integrated.

Later, when the role action mapping started controlling the dashboards to be seen on the client side, this configuration was just used to enable the dashboards for viewing.

MDMS Configuration

common-masters/uiCommonConstants.json

roleaction.json

Action test.json:

Charts Configuration Details

OBPS-State DSS consists of multiple graphs which represent the data of OBPS. Each graph has its own configuration which describes the chart and its type.

State DSS consists of the following charts in OBPS:

• Overview-Revenue

• Overview-Service

• Total Cumulative Collection

• Total permits issued vs Total OC submitted vs Total OC issued

• Collection by Payment Mode

• Top 3 Performing States/ULBs/Ward

• Bottom 3 Performing States/ULBs/Ward

• Permits Issued by Risk Type

• Permits Issued by Occupancy Type

• Service Report

More details about the respective charts are below:

Overview-Revenue: The Overview-Revenue chart contains multiple data information as below in the selected time period.

• Today's Collection - This represents today’s collection amount for OBPS Application Fee + Permit Fee.

• Total Collection - This represents the total collection amount for OBPS Application Fee + Permit Fee.

Overview-Service: The Overview-Service chart contains multiple data information as below in the selected time period.

• Total Plans Scrutinized - This represents the total number of plans submitted by an architect for scrutiny for new construction to the concerned authority.

• Total permits issued - This represents the total number of new permits issued by the concerned authority.

• Total sq m of land applied in the BPA system - This represents the total area in square meters approved for construction.

• Avg. days to issue permits - This represents the average number of days taken to issue a permit application.

• SLA Compliance (Permits) - This represents the total percentage of permits issued within SLA.

• Avg. days to issue OC - This represents the average number of days taken to issue an OC.

• SLA Compliance (OC) - This represents the percentage of OCs issued within SLA

Total Cumulative Collection: This graph contains the OBPS collection amount information on a monthly basis as a cumulative line graph for each OBPS collection separately. This changes as per the denomination amount filter selection.

line - this graph/chart is data representation on date histograms or date groupings.

Total permits issued vs Total OC submitted vs Total OC issued: This graph shows the total permits issued vs total OC submitted vs total OC issued for a given time period in the form of a line chart.

line - this graph/chart is data representation on date histograms or date groupings.

Collection by Payment Mode: This chart is a pie chart showing the bifurcation of total collections by payment mode (online, cash, card, cheque) which is the sum of revenue collected from the OBPS module for the applied date filter.

Top 3 Performing ULBs: This card will show the Top 3 Performing ULBs based on the percentage of permits issued. The number of permits issued / Number of applications.

Bottom 3 Performing States: This card shows the bottom 3 Performing States/ULBs/Wards based on the percentage of permits issued. Number of Permits issued / Number of applications

Permits Issued by Risk Type: This chart is a pie chart showing the bifurcation of total permits issued by risk type (low risk, medium risk, high risk) for the applied date filter.

Permits Issued by Occupancy Type: This chart is a pie chart showing the bifurcation of total permits issued by occupancy type (Residential, Institutional etc) for the applied date filter.

Service Report: This tabular chart representation graph shows information about multiple OBPS-related categories like Total Collection or Total Cumulative Collection, Total Plans Scrutinized, Total applications submitted, Total permits issued, Avg. days to issue a permit, SLA Compliance (Permits), Total OC Plans scrutinized, Total OC submitted, Total OC issued, Deviation Percentage, Avg. days to issue OC, SLA Compliance (OC), Total OCs with deviation. This table also shows the data at the state level and also has the drill-down chart for each state to ULB and from ULB to ward level data for the same.

Clicking on any DDR name drills down the charts to show the specified state data.

Clicking on the ULB navigates to the ward-level data for the specified ULB.

Newly Introduced Property Details

isRoundOff: This property is introduced to round off the decimal values. For instance, if the value is 25.43 by using isRoundOff property in the configuration, the value is displayed as 25. Similarly, if the value is 22.56 round of value is displayed as 23. This can be used for insights configuration as well for overview graphs.

Common Properties Available

Key(eg: bpaTotalCollection): This is the visualization code. This key is referred to in further visualization configurations. This is the key which will be used by the client application to indicate which visualization is needed for display.

chartName: The name of the chart which has to be used as a label on the dashboard. The name of the chart will be a detailed name. In this configuration, the Name of the Chart will be the code of Localization which will be used by the Client Side.

queries: Some visualizations are derived from a specific data source. While some others are derived from different data sources and are combined together to get a meaningful representation.

The queries of aggregation which are to be used to fetch out the right data in the right aggregated format are configured here.

queries.module: The module/domain level, on which the query should be applied i.e., OBPS

queries.indexName: The name of the index upon which the query has to be executed is configured here.

queries.aggrQuery: The aggregation query in itself is added here. Based on the Module and the Index name specified, this query is attached to the filter part of the complete search request and then executed against that index

queries.requestQueryMap: Client Request would carry certain fields which are to be filtered. The parameters specified in the Client Request are different from the parameters in each of these indexed documents.

In order to map the parameters of the request to the parameters of the ElasticSearch Document, this mapping is maintained.

queries.dateRefField: Each of these modules have separate indexes. And all of them have their own date fields.

When there is a date filter applied against these visualizations, each of them has to apply it against their own date reference fields.

In order to maintain what is the date field in which index, we have this configured in this configuration parameter.

chartType: As there are different types of visualizations, this field defines what is the type of chart/visualization that this data should be used to represent.

Chart Types Available

metric - this represents the aggregated amount/value for records filtered by the aggregate es query

pie - this represents the aggregated data on grouping. This is can be used to represent any line graph, bar graph, pie chart or donuts

line - this graph/chart is data representation on date histograms or date groupings

perform - this chart represents groping data performance-wise.

table - represents a form of plots and values with headers as grouped on and a list of its key, values pairs.

xtable - represents an advanced feature of the table, it has the addition capabilities for adding dynamic header values.

valueType - In any instance of data, the values which are sent for plotting, might be a percentage, sometimes an amount or sometimes just a count.

In order to represent them and differentiate the numbers from the amount from the percentage, this field is used to indicate the type of value that this visualization will be sending.

action: Some of the visualizations are not just aggregations of data sources. There might be some cases where we have to do a post-aggregation computation.

For example, in the case of the Top 3 performing ULBs, the target and total collection are obtained and then the percentage is calculated. In these kinds of cases, the action that has to be performed on the data obtained is defined in this parameter.

documentType: The type of document upon which the query has to be executed is defined here.

drillChart: If there is a drill down on the visualization, then the code of the Drill Down Visualization is added here. This will be used by Client Service to manage drill-downs.

aggregationPaths : All the queries will be having Aggregation names in it. In order to fetch the value out of each Aggregation Responses, the name of the aggregation in the query will be an easy bet. These aggregation paths will have the names of Aggregation in them.

insights: It is to show the data with the comparison of last year with arrow symbols, it will show the data in how much % is increased or decreased.

_comment: In order to display information on the “i” symbol of each visualization, Visualization Information is maintained in this field.

Postman Collection For OBPS-DSS

Overview

This document mainly covers all the steps that one needs to do for setting up a new instance of eDCR (Development Control Regulations). Say when a new State is to be set up, there are some activities to be executed in a defined order. Setting up an instance of an application server and configuring customer-specific rules, and data, etc are a few of the key activities.

• Centralized Server hosting all the ULBs within a state

• All ULBs access the software over API calls.

• Uniform code base supporting all the ULBs for the state. City-specific changes are maintained using client-specific implementation repositories.

• A separate schema for each ULB in the database.

Prerequisites

• Prior Knowledge of Java/J2EE.

• Prior Knowledge of Spring and Hibernate

• Prior knowledge of Maven

• Prior knowledge of Git.

• Install the below version of the software in local machine

  • maven v3.2.x

  • PostgreSQL v9.6

  • Git 2.8.3

  • JDK 8 update 112 or higher

Configurations and Setup

eDCR Service repository will be used to define default rules. The statewide rules to be defined within the client implementation repository.

How to set up a client implementation repository

After creating a client implementation repository, If you want to override rules processing for features, then create a project under egov directory like egov-client-impl.

The client-specific rules are configurable in the individual client implementation module. Here the rules are fetched by state wise, district wise, ULB wise, or grade-wise.

How to override rule processing across the state for a feature

The EG_CITY table, master data is used to decide the rules.

1. If the rules are the same for a feature across the state then the filename must need to keep like Far_{Client.id}.

3. The client id used with the feature class name and configures in the properties file should match, then only the system will pick features and process otherwise it won't pick the file.

How to override rule processing district, city, and grade wise for a feature

1. If the rules varying across district, city, and grade wise within a state then must need to follow the following naming conventions.

2. If the rules are varying from district to district, then the respective district-related rules need code under separate files with a filename like Far_{District Name}. eg: Far_Udalguri.

3. Similarly, if rules varying for city and grade wise then those respective rules need to code under separate files with a filename like Far_{City Name}, Far_{Grade}. eg: Far_Dispur, Far_Corp

4. The district, city, and grade information will be reading from the eg_city table, so in this table need to update that information before starting the coding.

5. In a state, only for one or two cities if the rules are changing then need to override rules only for those cities in a separate file, for other all cities the default code will pick. Here default code is state level (Far_{Client id}) configured one.

Configuration Changes to setup State and Cities

1. The state is configured by adding property tenant.{domain_name}=schema_name (state_name) in egov-erp-override.properties**.**

2. Each new ULB is enabled by adding a schema name and domain name in egov-erp-override.properties file(Available in Wildfly server under ${HOME_DIR}/wildfly-11.0.0.Final/modules/system/layers/base/org/egov/settings/main/config). Schema names should follow a naming standard, It should be the same as that of the city name.

3. Each ULB can be configured by adding an entry like tenant.{domain_name}=schema_name (city_name) in egov-erp-override.properties file.

4. Insert data into eg_city, in the city table domain URL value should be the same as configured tenant domain_name in the egov-erp-override.properties.

Changes required for local machine workspace setup

2. After set up is done, the local ubuntu machine need to update the domain URLs in the host file which you are going to use for scrutinizing and fetching the plan.

3. Navigate to the root directory and from there open the host config file available in the location 'etc/hosts'. Map the domain URLs with a local IP address in the hosts file and save the changes.

4. Update settings in standalone.xml under ${HOME_DIR}/wildfly-11.0.0.Final/standalone/configuration

5. Add 'max-post-size' attribute with value 100mb in bytes in the below location,

6. <server name="default-server"> <http-listener name="default" socket-binding="http" max-post-size="104857600" redirect-socket="https" enable-http2="true"/> <https-listener name="https" max-post-size="104857600" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/> </host> </server>

MDMS Integration

If you want to fetch master data from MDMS for following ApplicationType, ServiceType, OccupancyType, SubOccupancyType, Usages then the following configurations are needed,

References

Overview

Building plan approval (BPA) is one of the key activities performed by Urban Local Bodies and Planning Authorities. The Online Building Plan Application Software (OBPAS) automates the various steps in the plan approval process. The core intelligence of OBPAS resides in the automatic scrutiny of building plans with reference to the Development Control Regulations of the state. This functionality is called eDCR (eGov-DCR). It involves extracting the key plan parameters from the CADD drawing and evaluating the parameters against the defined rules in the State Development Control Regulations. Once the Plan Scrutiny is completed the application will be processed for other workflow stages like Document Verification, Field Verification, NOC Certificates, Fee Computation, and Permit Generation.

DIGIT offers the complete OBPAS as an open-source application and eDCR is an integral part of it. The automatic scrutiny capability provided by eDCR can be leveraged by States which already have existing BPA software through simple integration. This enables the States to reduce the manual and time-consuming process of evaluation of rules and ensures uniformity of evaluation.

This doc helps in understanding the integration process of eDCR Service with an existing Building Plan Application software. At a broad level, competencies in the below technical and functional areas are necessary for integrating eDCR system,

• Integration expertise is backed by a sound understanding of the architecture of the existing ecosystem, its uniqueness, features, flaws, and a complete understanding of the challenges involved in making them successfully work together.

• Subject matter expertise on Building Plans and DCR Rules to interpret DCR Rule Validation algorithm from the DCR Rules.

• A good understanding of the configuration of the DCR Rule Validations in the Validation Engine of the eDCR Service

eDCR Task Flow Overview

The eDCR process typically involves the below sequence of steps,

1. Capture drawing files in DXF format along with city identifier

2. Submit DXF format drawing file to eDCR system for scrutiny

3. Collect generated reports from eDCR system with status as accepted or rejected. The eDCR system will generate additional information like floor-wise area details, compound wall length, number of wells, etc

4. The DXF file can be resubmitted any number of times into the system, irrespective of the acceptance or rejection status

5. An accepted status of the drawing indicates that it is validated and approved against all the bylaws configured in the system. The integrating system can use this for further processing

6. The eDCR status report and associated details can be retrieved at a later point also by sending the unique Transaction Number to eDCR system

eDCR Architecture

The eDCR service has ​Extraction​, ​Validation, and ​Repository as the key components. The architecture depicted here covers integration aspects and API requirements.

Process Flow Diagrams

The diagram below clearly illustrates the process flow in the eDCR system. There are two major stages in the process:

• Upload and Scrutinize Plan

• Get Details (To check plan scrutiny status)

API Specifications

eDCR system will provide REST APIs to push drawing files (DXF format) along with a unique ID. The Integrating system will provide a unique Transaction Number. The same will be used by both systems to track applications.

eGov will publish two REST APIs.

• Upload And Scrutinize Plan: The integrating system should call this API with the required parameters explained in the API structure. The system will scrutinize the plan and reply with a response as explained in the API structure. The Status "Accepted" indicates the plan is ready to use for further process. "Rejected" will indicate that either plan violates the rule or is missing basic information. Both rejected and accepted plans can be resubmitted. But eDCR system will consider each request as a new one.

• Get Details:​ The integrating system will call this API with parameters specified in the API structure. The eDCR system will search for the details in the eDCR repository and respond with a) Status - accepted/rejected b) Scrutiny report c) Plan details (details present in Dxf) d) DXF file e) Generated Plan pdfs. If the transaction number or Autodcr number does not exist in the system, an appropriate message is published.

Training Pre-requisites For eDCR Integration

For integrating eDCR the below knowledge and infrastructure requirements need to be addressed

• State building by-laws with the latest amendments (hard or soft copy)

• Subject matter expert (SME) from the ULB side, who understands the by-laws and building plan domain

• An architect who can draw diagrams for the team to test – He or She should be able to understand the by-laws given by the SME and create diagrams to validate those by-laws in the diagram scrutiny

• The technical team should have resources with 5+ years of experience in J2EE technology - Java, Spring, Hibernate, Postgress, Jboss/Wildfly, and GIT

• The technical team should be equipped with LINUX machines preferably UBUNTU and the following

  • Maven v3.2.x

  • PostgreSQL v9.6

  • Elastic Search v2.3.5

  • Git 2.8.3

  • JDK 8 update 112 or higher

  • Eclipse or any IDE

• Cloud instance for deployment (Azure / AWS)

Overview

Users can view all the applications assigned to them in the employee inbox. And it provides multiple filters and search options to filter the applications.

Workflow Details

Inbox

OBPS Inbox uses InboxComposer React HOC to create the Inbox through various child components, for both mobile and Desktop Components.

Technical Implementation

The API used to fetch applications in the inbox

For viewing OBPS inbox these roles are necessary "BPA_FIELD_INSPECTOR", "BPA_NOC_VERIFIER", "BPA_APPROVER", "BPA_VERIFIER", "CEMP"

MDMS Data

Refer to the config below for risk type definition:-

Overview

To provide the facility for the employee users to update the BPA application state.

Workflow Details

Application Details

The application details page is used to display the details of the application and also showcase all the actions that can be taken on the application.

The various step for the application:

Document Verification

In this step, the user can upload multiple documents and/or approve the already uploaded documents.

NOC Verification

The user approves the uploaded NOC documents.

Inspection Report

The user fills in the inspection details (date, time, question, remarks) and submits.

Permit Condition

Here the user approves the required permit conditions and can also add new conditions.

Technical Implementation

All the screens are developed using the new-UI structure followed previously in FSM, PGR, PT, and TL. Certain new components have been introduced such as Multi-Document Upload, Approval Checks, etc.

MDMS Data

Throughout the flow, some data is imported from the MDMS. Following is the list of MDMS data:

1. Checklist

2. RiskTypeComputation

Below is the MDMS config used to fetch MDMS data:

Localization

The localization module used across the OBPS module was rainmaker-bpa and rainmaker-common, out of which we initialized rainmaker-bpa with module initialization.

Overview

This page provides details on the Stakeholder Registration workflow in the OBPAS module. Citizens have the option to submit registration applications for various stakeholders such as architects and construction companies.

Workflow Details

Apply For Stakeholder Application

Users can apply for stakeholder application by clicking on the “Register as a Stakeholder”, and while going through the workflow, can add all the information, according to the question asked, in the middle of the workflow after the correspondence address Create API will be called, and at the end of the flow, a summary screen will be visible for the review of the answers and on clicking the submit button an Update API will be called which will change the status from Initiated to Applied and Registration Application will get updated.

Registration Flow

The stakeholder Document Required screen is displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for stakeholders. A citizen info card is also shown at the bottom of the page containing additional information such as the maximum size of the file that can be uploaded.

TimeLine Component

The TimeLine component is present on all pages. It informs the users about the steppers in completing the application for registration.

Licensee Details

In this step, users need to provide information about the License type and Licensee.

License Type

The system asks for the type of license that the user is registering for. If the user selects architecture, then a new field is displayed i.e. architecture number. For all other roles, no additional information user is required. All the roles are populated from the MDMS.

Licensee Details

Here users have to provide the information of the person for whom the license application is being generated. By default, the name and mobile number field will be automatically pre-filled with the logged-in user data. Edits to this detail are disabled. Applicants must fill in the remaining information accordingly.

Address Details

In this step, users have to enter their address details.

Permanent Address

Users have to provide a permanent address. This is mandatory information that the user needs to provide to move to proceed with the application.

Correspondence Address

Here user gets the option to either pre-fill the form with the permanent address provided earlier or enter a different address. Users can also skip this step as it is non-mandatory.

Clicking on the Next button calls the Create API. Further information is available in the technical Implementation details section.

Document Details

Licensee Document Details

This screen displays a list of documents and their type (in dropdown format) from the MDMS. The document list displayed is as per the role selected by the user in the license step. Users have to upload all the mandatory documents in order to proceed further.

Summary Page & Acknowledgement Screen

Users can cross-verify the data entered throughout the flow on the Summary page. In case of any change or update required, the edit icon available adjacent to the section header allows the users to make the changes. It redirects users to the particular section page and the whole flow is repeated again in order to submit the application.

Along with the application details, the fee estimate for the corresponding application is also shown on the summary page.

The Update API is called for the BPAREG Application update. Update API snippet is given below:

If the API response is successful, the Acknowledgement Screen is displayed. Else, the Failed Acknowledgement Screen is displayed.

Click on the Make Payment option to pay the registration fees on the summary screen.

Technical Implementation

All the screen has been developed using the new-UI structure followed previously in FSM, PGR, PT and TL, few new components have been introduced such as TimeLine, Multi upload Document etc

The link for the Stakeholder Registration Main Index is given below, it can be used to understand the starting point of the flow:

The OBPAS module is segregated into a specified structure. The screen configuration details are available in the PageComponent folder and the configuration for routing of the pages is available in the config folder which is common for both citizens as well as employees. New components like TimeLine are defined in the component folder. Below is the snippet for folder structure and routing configuration.

The stakeholder config responsible for the routing of the pages is defined under the config folder. Click on the link below to access the code.

The Pages folder contains the high-level configuration for controlling the whole flow for citizens and employees. The flows for citizens include Apply flows, Send Back flows, Application details etc. These carry the index (the main starting point of the whole flow).

The main difference between the Stakeholder registration flow from the apply flow in other modules is that the Create API is called in between the flow and at the end, the Update API is called.

The code for Create API request object generation is found inside the correspondence address component. This API call is triggered when the user clicks on the Next button on the correspondence address page.

The hook used for this API call is Digit.OBPSService.BPAREGCreate(payload, tenantId) and payload can be found inside the gonext() method in the following file:

Code reference:

The Utils folder basically contains all the methods that are used throughout the OBPAS module, and if any common method needs to be declared here, which in turn can be imported into other files.

For updating an application the Update API from BPAREG is called using the React hooks, which have been declared under hooks/elements/obps as OBPSService.

The response object from the Create API is used for the request object of Update API, with the addition of document details that the user has entered. This marks the status of the Application as Applied instead of initiated.

Below is the hook used for fetching the update API call.

This API is called in the Stakeholder Acknowledgement code, using the useEffect Hook.

Code reference:

MDMS Data

Throughout the flow, a few of the page data is imported from MDMS. Following is the list of pages that use MDMS data. These pages .js files can be found under page components.

For calling the MDMS data, React Hooks are used, so that it could be shared throughout the modules. Below is the little code snippet for the MDMS call.

Localization

Localization keys are added in the ‘rainmaker-bpareg’ locale module. In future, if any new labels are implemented in the OBPS - Stakeholder (Citizen) they should be pushed in the locale DB under rainmaker-bpareg locale module. Below is an example of a few locale labels.

API Call Role Action Mapping

Software to install

• Java 1.8

• Eclipse

• Postgres

• PhpPgAdmin

• Postman (Application)

• Respective Git MiddleWare

• Kubectl

• Kafka

Take the code pull from the git:

Need to consider 2 repositories for code to run locally

1. Municipal services - where our BPA code exists and some dependency services also available here

2. Core Services - Where dependency services exist to run our code locally

Import the required projects to eclipse

From municipal-services import bpa-services, bpa-calculator and land-services. From core-services import user service, idgen service, mdms service, location service, localization service, workflow service, egov-persister.

Before running the application make sure the following setups are complete to ensure the application runs smoothly.

• kafka set up in your system which is running fine. Download the latest version of kafka from here.

Run the below commands based on your system types

For linux: in kafka folder path

Example: D:\kafka_2.13-2.4.0

> bin/zookeeper-server-start.sh config/zookeeper.properties > bin/kafka-server-start.sh config/server.properties

For Windows: in windows path

Example: D:\kafka_2.13-2.4.0\bin\windows start zookeeper-server-start.bat ....\config\zookeeper.properties start kafka-server-start.bat ....\config\server.properties

• Kubectl setup based on the requirement To get the pods: kubectl get pods To port forward: kubectl port-forward <<pod name>> <<port number>>:8080 To get the logs: kubectl get logs

After all the setups are done successfully, try to run the application locally.

BPA-Services How to run the application in local:

Check the services which are connected to local and which are connected to dev

• Which are connected to dev no need to change anything.

• If it is connected to local check the services are in below list IDGEN – can run locally or can point to dev from cmd prompt PERSISTER – can run locally MDMS – can directly point to dev or can run in local LOCATION – can directly point to dev WORKFLOW – can point to dev or can run locally LOCALIZATIONS – we can directly point this to dev USER-SERVICE – need to point to dev from cmd prompt LAND-SERVICE – need to run locally BPA-CALCULATOR – can run locally or can point to dev.

• If the changes are from these services follow the below process to run those respective services.

For core services:

IDGEN:

Approach 1: Directly point this to dev from the application.properties in bpa-services Approach 2: Point this to local and give the port forward to dev by using kubctl.

PERSISTER:

U need to run it in local and need to add respective yaml files in persister resource folder which are bpa-persister.yml and egov-workflow-v2-persister.yml and also land-persister.yml

And need to add these in persister application.properties repo path

MDMS:

to run local: For running this in local need to change in 2 file that is application.properties and MDMSApplicationRunnerImpl

In application.properties need to change the paths for the master-config url as path of master-config.json and for config path as upto pb/bh

In MDMS ApplicationRunnerImpl need to change the data in a function from the path to file.

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

LOCATION

Approach 1: Give it a local connection in BPA application.properties and port forward to dev by using kubectl.

Approach 2: Directly point this to dev from the application.properties in bpa-services

WORKFLOW

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

to run local:

can run locally by pointing to the local database, but for this need to create the workflow locally using the workflow create API.

USER-SERVICE Approach 1: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Approach 2: Directly point this to dev from the application.properties in bpa-services

LOCALIZATIONS

Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Changes from Municipal services

BPA-Calculator:

to run local:

can run locally by pointing to the local database.

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Land-Service:

to run local:

can run locally by pointing to the local database.

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Other than these services can directly by pointing to dev url.

All Dependent Services

• 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, permitorder 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)