Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Introduction

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 needs to be done.

  • Centralized Server hosting all the ULBs within a state

  • All ULBs access the software over the browser or over API call.

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

Configurations and Setup

How to set up a client implementation repository

  1. Branch out and create a client implementation repository from https://github.com/egovernments/eGov-dcr-service master repository. For example, you can refer https://github.com/egovernments/egov-dcr-client how the client implementation setup has been done.

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

How to override rule processing across the state, city, ULB, and grade wise for a feature

Please refer the document, Development Control Rules (Digit-DCR)

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.

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.

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

Note:

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

  2. Should not use city domain URL to scrutinize or fetch, still if you use and scrutinize won’t get any response and will fail.

  3. The tenantId, if you are using {state_name.city_name} naming convention, then the state_name what you are sending in the request and city code in the state schema must be the same.

  • No labels