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.

Prerequisites

• eDCR service set up done.

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

• Install below version of software in local machine,

  • maven v3.2.x

  • PostgreSQL v9.6

  • Jboss Wildfly v11.x

  • Git 2.8.3

  • JDK 8 update 112 or higher

Configurations and Setup

How to set up a client implementation repository

1. Branch out and create a eDCR implementation repository from https://github.com/egovernments/eGov-dcr-service - Connect to preview master repository. Refer https://github.com/egovernments/egov-dcr-client - Connect to preview for the client implementation setup has been done.

2. 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. The EG_CITY table, master data used to decide these values.

a. How to override rule processing across the state for a feature

1. If the rules are the same for a feature across the state then the filename must need to keep like Far_{Client.id}.
2. Here client id nothing but a state name, the client.id need to update with the state name in application-config-client.properties file (Available in https://github.com/egovernments/egov-dcr-client/blob/master/egov/egov-client-impl/src/main/resources/config/application-config-client.properties) or 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).
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.
4. Eg: https://github.com/egovernments/egov-dcr-client/blob/master/egov/egov-client-impl/src/main/java/org/egov/client/edcr/Far_Client.java Here filename to be added as Far_Assam.java for the Assam state rules.

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

How to Setup New State and ULB’s

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

1. After doing above all changes like adding city data, the domain name updation in the config file for state and ulb's, etc..
2. In a local ubuntu machine need to update the domain URLs in the host file which you are going to use for scrutinizing and fetching plan.
3. Navigate to the root directory and then navigate path '/etc/hosts' and press enter, then map the domain URLs in this file local IP address.

Integration with MDMS

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

1. Enable fetch master data from MDMS by adding mdms.enable=true property in application-config-client.properties file (Available in https://github.com/egovernments/egov-dcr-client/blob/master/egov/egov-client-impl/src/main/resources/config/application-config-client.properties) or 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).
2. Add the property and update the MDMS hostname, mdms.host={HOST_NAME} in application-config-client.properties file or egov-erp-override.properties file
3. Add the property and update the MDMS search URL, mdms.searchurl=/egov-mdms-service/v1/_search in application-config-client.properties file or egov-erp-override.properties file

Note:

1. By default, the master data will be fetched from the database.
2. If you want to fetch from MDMS instead of the database then the above configurations are required.

eDCR API’s

The following API’s are used in the integration of eDCR system-

Scrutinize Plan API

Purpose: This API will scrutinize the building plan drawing(.dxf) file send along and gives the plan scrutiny result as response along with a unique eDCR number on successful processing.

Fetch scrutinized plan details API

Purpose: This API is used to fetch the details of the plan that is already scrutinized in the system by providing a transaction number or a eDCR number.

Extract Plan API

Purpose: This API will extract the building plan drawing(.dxf) file send along and gives the extracted data.

Comparison report for occupancy certificate plan scrutiny API

Purpose: Send the unique eDCR number and ocDCR number for getting the comparison report and This API is used to generate an occupancy certificate comparison report.

Refer API contracts https://github.com/egovernments/digit-bpa/blob/master/egov/egov-edcr/dcrasservice.yaml

Note:

1. For the above APIs one must use state domain URL and in the contract tenantId of concern city have to be passed to scrutinize multiple cities.

2. One should not use the city domain URL to scrutinize or fetch plan if used that way, the response will be empty.

3. The tenantId used should follow {state_name.city_name} naming convention, then the state_name passed in the request and city code in the state schema must be the same.

References and Notes