Setting Up eDCR Service


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.


  • 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

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
Branch out and create a eDCR service repository from ​ - Connect to preview
master repository. Refer ​ - Connect to preview
for the client implementation setup has been done.
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. 1.
    If the rules are the same for a feature across the state then the filename must need to keep like Far_{}.
  2. 2.
    Here client id nothing but a state name, the need to update with the state name in file (Available in or in file(Available in Wildfly server under ${HOME_DIR}/wildfly-11.0.0.Final/modules/system/layers/base/org/egov/settings/main/config).
  3. 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. 1.
    If the rules varying across district, city, and grade wise within a state then must need to follow the following naming conventions.
  2. 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. 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. 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. 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. 1.
    The state is configured by adding property tenant.{domain_name}=schema_name (state_name) in**.**
  2. 2.
    Each new ULB is enabled by adding a schema name and domain name in 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. 3.
    Each ULB can be configured by adding an entry like tenant.{domain_name}=schema_name (city_name) in file.
  4. 4.
    Insert data into eg_city, in the city table domain URL value should be the same as configured tenant domain_name in the
Changes required for local machine workspace setup
  1. 1.
    Setup your eDCR service workspace by following the instructions provided in​
  2. 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. 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. 4.
    Update settings in standalone.xml under ${HOME_DIR}/wildfly-11.0.0.Final/standalone/configuration
  5. 5.
    Add 'max-post-size' attribute with value 100mb in bytes in the below location,
  6. 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,
Enable fetch master data from MDMS by adding mdms.enable=true property in file (Available in or in file(Available in Wildfly server under ${HOME_DIR}/wildfly-11.0.0.Final/modules/system/layers/base/org/egov/settings/main/config).
Add the property and update the MDMS hostname,{HOST_NAME} in file or file
Add the property and update the MDMS search URL, mdms.searchurl=/egov-mdms-service/v1/_search in file or file
  1. 1.
    By default, the master data will be fetched from the database.
  2. 2.
    If you want to fetch from MDMS instead of the database then the above configurations are required.
  1. 1.
    After setup is done APIs one must use state domain URL and in the contract tenantId of concern, the city has to be passed to scrutinize multiple cities.
  2. 2.
    One should not use the city domain URL to scrutinize or fetch plan if used that way, the response will be empty.
  3. 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.


Design and Architecture
API Contracts
Repository the default rule processing code available
Sample client implementation repository
Configuring MDMS
Creative Commons License
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
​All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.