Setting Up eDCR Service

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.

If the rules are the same for a feature across the state then the filename must need to keep like Far_{Client.id}.
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

If the rules varying across district, city, and grade wise within a state then must need to follow the following naming conventions.
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.
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
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.
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

The state is configured by adding property tenant.{domain_name}=schema_name (state_name) in egov-erp-override.properties.
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.
Each ULB can be configured by adding an entry like tenant.{domain_name}=schema_name (city_name) in egov-erp-override.properties file.
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

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.
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.
Update settings in standalone.xml under ${HOME_DIR}/wildfly-11.0.0.Final/standalone/configuration
Add 'max-post-size' attribute with value 100mb in bytes in the below location,
<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,

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

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

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.
One should not use the city domain URL to scrutinize or fetch plan if used that way, the response will be empty.
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

Title

Link

Design and Architecture

API Contracts

Repository the default rule processing code available

Sample client implementation repository

Configuring MDMS

PreviousConfiguration FAQs NextAdding Roles To System

Last updated 4 years ago

Was this helpful?