Introduction

This document mainly covers all the steps that one needs to do for setting up a new instance of BPA. 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, workflows and data, etc are few of the key activities.

Prerequisites 

• BPA product set up needs to be done.
• Centralized Server hosting all the ULBs within a state
• All ULBs access the software over the browser. There is no offline system.
• Uniform code base supporting all the ULBs for the state. City specific changes are maintained using client specific implementation repositories.
• Separate schema for each ULB in the Database.
• Dashboard to aggregate data across ULBs for state-level analysis

Functionality

There is an open source product for BPA which is made by eGov Foundation as a base application. Any state/city specific changes that come across during the implementations need to be accommodated in a separate repository. Only the custom changes will go to this repository. Deployable will contain both the base product and the custom code.

Configurations and Setup

For setting up a new instance there are many activities involved. Below listed are a few of those.

How to Setup New City/State

Each city/state has its own rule book which explains the flow of the application, application input format, notice format, permit format, fee calculation, restrictions for stakeholder, local language support, etc. The workflow is also decided by the city based on the availability of designation or posts present in the concerned city. The following changes to be added to each city to make it live.

1. Each city is enabled by adding a separate schema in the database. Schema names should follow a naming standard. It should be the same as that of the city name. Also, all the client-specific implementations should be pushed to a separate repository. For Eg:https://github.com/egovernments/eGov-Bihar-Implementation. Add the following master data for each city.
   1. City information
   2. Boundary information
   3. Employees information
   4. Configuration changes
   5. Workflow (if required)
   6. Fee rates (if city-specific otherwise add state level)
   7. City Name in Tenant Master
2. Each city/state will have specific formats for the permit order, certificates and so on. These need to be done specifically and pushed to client specific repository. For instance, Permit format order changes are added as  https://github.com/egovernments/eGov-Bihar-Implementation/blob/master/egov/egov-bihar-impl/src/main/java/org/egov/bihar/bpa/service/notice/impl/PermitOrderFormatImpl_Bihar.java
3. State-level configurations or any data have to be added commonly under the main.

How to setup client specific repository in eclipse

1. Clone client specific repository, for example,  git clone https://github.com/egovernments/eGov-Bihar-Implementation.git
2. Import client specific repository to eclipse (digit-bpa workspace).
3. Add client specific egov-ear to the server and remove digit-bpa egov ear.
4. Point the client specific repository settings.xml in maven >user settings.
5. Delete temp/data and ear file from deployments folder and redeploy to wildfly.

How and where to keep in the client-specific database scripts

1. Any database scripts should be checked into the appropriate location. All migration scripts are kept in the resources/db/migrations folder with subfolders like main, sample, statewide, <tenantname>. Various properties which control the migration behavior is read from application-config.properties. The migrations will happen when the application server starts.
2. There is a numbering pattern to be followed, which the flyway will understand to decide the sequence of execution. First character has to be "V" followed by timestamp in yyyymmddhhmmss format. This will be followed by "__"(double underscore) and then the name of the file with .sql extension. One example can be V20150920070251__egf_eg_action_DML.sql
3. egov-database is one of the modules in the EAR to do DB migration happen over maven build, this project is responsible for aggregating all the migration script resources and running the migration when maven build runs.

Support Information

References and Notes