Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Details coming soon...
Learn all about setting up DIGIT and its various components.
Details for these pages coming up soon...
Details coming soon...
Details coming soon...
Details coming soon...
This section contains documents and information required to configure the DIGIT platform
Learn how to configure the DIGIT platform. Partner with us to enhance and integrate more into the platform.
Details coming soon...
Details coming soon...
Learn how to setup DIGIT master data.
DIGIT environment setup is conducted at two levels.
MDMS stands for Master Data Management Service. MDMS is One of the applications in the eGov DIGIT core group of services. This service aims to reduce the time spent by developers on writing codes to store and fetch master data ( primary data needed for module functionality ) which doesn’t have any business logic associated with them.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.
Prior knowledge of Git.
Advanced knowledge on how to operate JSON data would be an added advantage to understand the service.
The MDMS service reads the data from a set of JSON files from a pre-specified location.
It can either be an online location (readable JSON files from online) or offline (JSON files stored in local memory).
The JSON files will be in a prescribed format and store the data on a map. The tenantID of the file serves as a key and a map of master data details as values.
Once the data is stored in the map the same can be retrieved by making an API request to the MDMS service. Filters can be applied in the request to retrieve data based on the existing fields of JSON.
For deploying the changes in MDMS data, the service needs to be restarted.
The changes in MDMS data could be adding new data, updating existing data, or deletion.
The config JSON files to be written should follow the listed rules
The config files should have JSON extension
The file should mention the tenantId, module name, and the master name first before defining the data
Title
Description
tenantId
Serves as a Key
moduleName
Name of the module to which the master data belongs
MasterName
The Master Name will be substituted by the actual name of the master data. The array succeeding it will contain the actual data.
Example Config JSON for “Billing Service”
Title
Link
Reference Doc Link 1
MDMS-Service
Reference Doc Link 2
MDMS-Rewritten
Link
API Contract Reference
Configuring Master Data for a new module requires creating a new module in the master config file and adding masters data. For better organizing, create all the master data files belongs to the module in the same folder. Organizing in the same folder is not mandatory it is based on the moduleName in the Master data file.
Before you proceed with the configuration, make sure the following pre-requisites are met -
User with permissions to edit the git repository where MDMS data is configured.
These data can be used to validate the incoming data.
After adding the new module data, the MDMS service needs to be restarted to read the newly added data.
Adding new module
The Master config file is structured as below. Each key in the Master config is a module and each key in the module is a master.
The new module can be added below the existing modules in the master config file.
Creating Masters data
Please check the link to create new master Adding New Master
Title
Link
Sample Master config file
Sample Module folder
MDMS supports the configuration of data at different levels. While we enable a state there can be data that is common to all the ULB’s of the state and data specific to each ULB’s. The data further can be configured at each module level as state-specific or ULB’s specific.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.
Prior knowledge of Git.
Advanced knowledge on how to operate JSON data would be an added advantage to understand the service.
State Level Masters are maintained in a common folder.
ULB Level Masters are maintained in separate folders named after the ULB.
Module Specific State Level Masters are maintained by a folder named after the specific module that is placed outside the common folder.
For deploying the changes(adding new data, updating existing data or deletion) in MDMS, the MDMS service needs to be restarted.
State Level Master Configuration
The common master data across all ULB’s and modules like department, designation, etc are placed under the common-masters folder which is under the tenant folder of the MDMS repository.
The common master data across all ULB’s and are module-specific are placed in a folder named after each module. These folders are placed directly under the tenant folder.
ULB Level Master Configuration
Modules data that are specific to each ULB like boundary data, interest, penalty, etc are configured each ULBwise. There will be a folder per ULB under the tenant folder and all the ULB’s module-specific data are placed under this folder.
Tenant represents a body in a system. In the municipal system, a state and its ULBs (Urban local bodies) are tenants. ULB represents a city or a town in a state. Tenant configuration is done in MDMS.
Before proceeding with the configuration, the following pre-requisites are met -
Knowledge of json and how to write a json is required.
Knowledge of MDMS is required.
User with permissions to edit the git repository where MDMS data is configured.
For login page city name selection is required. Tenant added in MDMS shows in city drop-down of the login page.
In reports or in the employee inbox page the details related to ULB is displayed from the fetched ULB data which is added in MDMS.
Modules i.e., TL, PT, MCS can be enabled based on the requirement for the tenant.
After adding the new tenant, the MDMS service needs to be restarted to read the newly added data.
Tenant is added in tenant.json. In MDMS, file tenant.json, under tenant folder holds the details of state and ULBs to be added in that state.
Naming Convention for Tenants Code
“Code”:“uk.citya” is StateTenantId.ULBTenantName"
Localization should be pushed for ULB grade and ULB name. The format is given below.
Localization for ULB Grade
Localization for ULB Name
Format of localization code for tenant name <MDMS_State_Tenant_Folder_Name>_<Tenants_Fille_Name>_<Tenant_Code> (replace dot with underscore)
Boundary data should be added for the new tenant.
Summary of DIGIT OpenSource GitRepos and it's purpose. If you are a partner/contributor you may choose to fork or clone depending on need and capacity.
ULB level setup involves the configuration of ULB specific data parameters such as ULB boundaries, ULB bank accounts, and hierarchy details.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Key configurations at the state level include -
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
For creating a new master in MDMS, create the JSON file with the master data and configure the newly created master in the master config file.
Before proceeding with the configuration, make sure the following pre-requisites are met -
User with permissions to edit the git repository where MDMS data is configured.
After adding the new master, the MDMS service needs to be restarted to read the newly added data.
Creating Master JSON The new JSON file needs to contain 3 keys as shown in the below code snippet. The new master can be created for Statewide or ULB wise. Tenant id and config in the master config file determines this.
Configuring the master config file The Master config file is structured as below. Each key in the Master config is a module and each key in the module is a master.
Each master contain the following data and keys are self-explanatory
Whenever an android mobile App is developed it has to be published on the Google play store in order to let the users avail its service. This page provides information about configuring the google play store account to make DIGIT mobile apps available for easy download.
In order to start the configuration for the google play store following would be required:
Data given in the table is sample data.
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Ask the state team/client to create an email account on Gmail.
Ask the client to log in to the google play console and make the required payment so that further tasks could be processed.
Ask the client to share the email id and password in the template.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
An Urban Local Body (ULB) is defined as a tenant. The information which describes the various attributes of a ULB is known as tenant information. This detail is required to add the ULB into the system.
Data given in the table is a sample data.
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning as given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you and discuss the same to clear out the doubts.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist by taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity. There are no checklist activities exists which are specific to the entity.
An email account of the client/state team has to be set up in order to receive/send the email notifications.
In order to achieve the functionality, an email account has to be set up at there server since most of the states would defer from creating an account with the Gmail/public server. Further, this email account has to be integrated with the various DIGIT modules.
In order to achieve the above functionality, we require the below-mentioned details
The values mentioned here are sample data.
Below steps could be followed in order to fill the template:
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Ask the state to gather all the data related to the technical configuration from the email server settings.
Get the attached template filled from the state and a sample data is provided in the data table section for reference.
The data would be available in the POP and IMAP account settings at the server level.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Not Applicable
DIGIT has modules which require the user to pay for the service that he/ she is availing for example property tax, trade license etc. . In order to achieve the functionality, we have a common payment gateway developed which acts a liaison between DIGIT apps and external payment gateways (which depends on the client requirements).
This module facilitates payments and lookup of transaction status.
Following are the details required from the payment gateway vendor in order to configure the payment gateway:
Data given in the table is a sample data.
The payment gateway is a vendor oriented service that is integrated with different modules in order to facilitate the transactions. Below mentioned are the steps which are followed:
The client has to finalize a payment gateway vendor (for example PAYU, Paytm, HDFC, AXIS atc.) depending upon the requirements.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
After which the details/ documents mentioned in the template would be provided by the vendor.
These details are to be received separately for both prods as well as UAT.
Get the IP address for UAT and Production environments whitelisted from the vendor.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
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.
ex: ///common-masters/ Here “pb” is the tenant folder name.
ex: ///TradeLicense/ Here “pb” is the tenant folder name and “TradeLicense“ is the module name.
ex: ////TradeLicense/ Here “amritsar“ is the ULB name and “TradeLicense“ is the module name. All the data specific to this module for the ULB are configured inside this folder.
All content on this page by is licensed under a .
To enable tenant the above data should be pushed in tenant.json file. Here "ULB Grade" and City "Code" are important fields. ULB Grade can have a set of allowed values that determines the ULB type, (, Municipality (municipal council, municipal board, municipal committee) (Nagar Parishad), etc). City "Code" has to be unique to each tenant. This city-specific code is used in all transactions. Not permissible to change the code. If changed we will lose the data of the previous transactions done.
"logoId": "", Here the last section of the path should be "/<tenantId>/logo.png". If we use anything else, logo will not be displayed on the UI. <tenantId> is the tenant code ie “uk.citya”.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
To see common checklist refer to the page consisting of all the activities which are to be followed to ensure completeness and quality of data.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
Link
API Contract Reference
Title
Link
Sample Master file
Sample Master configuration
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Sr. No.
Checklist Parameter
Example
1
Make sure that the email account is created on Gmail since the play store works on Google accounts only
-
2
Email Id and Password is required in order to login to the google play store for configuration
-
S. No.
ULB Name*
ULB Code*
ULB Grade*
City Name*
City Local Name
District Name*
District Code*
Region Name
Region Code
1
Sonepur Nagar Panchayat
47
Corp
Sonepur
Sonepur
Banka
BN47
Bihar
BBD47
Contact Number*
Address*
ULB Website*
Latitude
Longitude
Email Address
GIS Location Link
Call Center No.
Facebook Link
Twitter Link
Logo file Path*
98362532657
Main Hall, Sonepur
24.8874° N
86.9198° E
snp@bihar.gov.in
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
ULB Name
Text
256
Yes
Name of ULB. E.g. Kannur Municipal Corporation/ Saptarishi Municipal Council
2
ULB Code
Alphanumeric
64
Yes
It is a unique identifier which is assigned to each ULB. LGD (Local Government Directory) has already assigned a code urban local bodies and the same is used here
3
ULB Grade
Alphanumeric
64
Yes
Grade of ULB. e.g. Corporation, Municipality, Nagar Panchayat etc
4
City Name
Text
256
Yes
Name of city/ town which is covered by the ULB. E.g. Kannur/ Saptarishi
5
City Local Name
Text
256
No
Name of the city in the local language. e.g Telugu, Hindi etc
6
District Name
Text
256
Yes
Name of the District where the city is situated
7
District Code
Alphanumeric
64
Yes
It is a unique identifier which is assigned to each district. LGD (Local Government Directory) has already assigned code districts and the same is used here
8
Region Name
Text
256
No
Name of the region the listed district belongs to
9
Region Code
Alphanumeric
64
No
Unique code of the region to uniquely identify it
10
Contact Number
Alphanumeric
10
Yes
Contact person phone no. of ULB
11
Address
Text
256
Yes
Postal address of the ULB for the correspondence
12
ULB Website
Alphanumeric
256
Yes
URL address of the website for the ULB
13
Email Address
Alphanumeric
64
No
Email of the address of ULB where the email from the citizen can be received
14
Latitude
Alphanumeric
64
No
Latitude part of coordinates of the centroid of the city
15
Longitude
Alphanumeric
64
No
Longitude part of coordinates of the centroid of the city
16
GIS Location Link
Text
NA
No
GIS Location link of the ULB
17
Call Center No
Alphanumeric
10
No
Call centre contact number of ULB
18
Facebook Link
Text
NA
No
Face book page link of ULB
19
Twitter Link
Text
NA
No
Twitter page link of the ULB
20
Logo file Path
Document
NA
Yes
URL of logo file path to download the logo of ULB
Sr. No.
Email ID
Your Name
Account Type
Incoming Mail Server
Outgoing Mail Server (SMTP)
Password
Incoming Server POP3 Port
Outgoing server SMTP Port
Encrypted Connection Type
Days after which the email should be removed from the server
1
Bihar
POP3
SMTP
SMTP
****
192.172.82.12
192.172.82.12
Auto
14
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
1
Email ID
Alphanumeric
N/A
Yes
Email id which is being configured
2
Your Name
Text
256
Yes
The name on behalf of which the email would be sent in order to receive the updates
3
Account Type
Alphanumeric
64
Yes
The type of email account type protocol which will be used to download messages
4
Incoming Mail Server
Numeric
(12,2)
Yes
The IP address of the email server through which messages would be received
5
Outgoing Mail Server(SMTP)
Numeric
(12,2)
Yes
The IP address of the email server through which messages would be sent
6
Password
Alphanumeric
64
Yes
The password of the email server
7
Incoming Server POP3 Port
Numeric
(12,2)
Yes
The port number through which the emails are received
8
Outgoing server SMTP Port
Numeric
(12,2)
Yes
The port number through which the emails are to be sent
9
Encrypted Connection Type
Alphanumeric
64
Yes
The encryption type which is used for the connection
10
Days after which the email should be removed from the server
Numeric
(12,2)
Yes
The number of days after which the email should be deleted from the server (not from the local device)
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Sr. No
Integration Kit
API Documentation
Redirect Working Key
Merchant Id
Test credential of Debit Card/ Net banking
1.
File Name
File Name
XYZ#123
UDDUK
File Name
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Integration Kit
Document
NA
Yes
This is a document that is sent by the vendor which contains information on how to integrate the service
2
API Documentation
Document
NA
Yes
This is a separate document which is sent by the vendor in order to help ideally helps us to retrieve the transaction status
3
Redirect Working Key
Alphanumeric
64
Yes
The working key is provided by the vendor for the generation of the redirection URL
4
Merchant Id
Alphanumeric
64
Yes
Merchant id provided by the vendor
5
Test credential of Debit Card/ Net Banking
Document
NA
Yes
These are the details of the debit/credit card or net banking credentials which would help us test the gateway
This contains the card number/Code/Account number etc.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Sr. No.
Checklist Parameter
Example
1
While finalizing a payment gateway vendor make sure that the vendor should support transactions into multiple bank accounts based on the key( which would be tenantid)
-
2
Do get the details for both the environments separately i.e UAT and Production
-
Sr. No
Email Id
Password
1.
*******
Sr. No.
Column Name
Data Type
Data Size
Mandatory
Description
1
Email Id
Alphanumeric
NA
Yes
Gmail account id through which the app would be published on the google play store
2
Password
Alphanumeric
NA
Yes
Password for the Gmail account
Title
Link
State Level Common-Master Data
State Level Module Specific Common-Master Data
ULB Specific Data
Title
Link
tenant json file
content
Point of Sales (POS) machine is a machine that helps in handling transaction processing. This machine accepts and verifies the payments which are made by citizens for prevailing the services of DIGIT.
POS facilitates a middleware app developed in order to verify the payment process between the DIGIT module and the payment.
In this case, no data is required from the state team.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
The departments are defined as different sections within the ULB based on which the functions performed by ULBs and employees in ULB are grouped. The budgets details of the ULBs are also defined by the department. It is suggested that the ULB across the state adopt the same department naming terminology. This document will help you in filling the department detail in the template provided.
Sr. No.
Department Code*
Department name (In English)*
Department Name (In Local Language)*
1
ACC
Accounts
लेखा
2
PHS
Public Health And Sanitation
सार्वजनिक स्वास्थ्य और स्वच्छता
3
REV
Revenue
राजस्व
4
TP
Town Planning
नगर नियोजन
Data given in the table is a sample data.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Department Code*
Alphanumeric
64
Yes
Unique code for the department to identify a department
2
Department Name ( In English)*
Text
256
Yes
The name of the department in the ULB in English
3
Department Name (In Local Language)*
Text
256
Yes
The name of the department working in the ULB in local language e.g. Telugu, Hindi etc. whichever is applicable
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify all the departments in ULB well before start filling then into the template.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed after the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
To see the common checklist refer to the Checklist page consisting of all the activities which are to be followed to ensure complete and quality data.
This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.
Localization is a practice to localize various UI visible data into the local wordings according to the client's requirements. This practice of localization is enforced on various clients so that it becomes easier for the people using the service to understand the common terminology and make the best use of the available system.
The following texts (but not limited to) on the web page can be localized:
Labels
Messages: Alert messages, success messages, validation messages and other notifications etc.
Help Texts
The module-specific master data would already have been made available in the localized form while collecting the data for the respective module-specific configuration.
Sr. No.
Code*
Module*
Message (In English)*
Message (In Local Language)*
1
ACTION_TEXT_APPLICATION
Trade License
Search Trade Licenses
व्यापार लाइसेंस खोजें
2
ACTION_TEST_TL_REPORTS
Trade License
Trade License Reports
ट्रेड लाइसेंस रिपोर्ट
3
CORE_COMMON_CITY
Property Tax
City
शहर
Data mentioned in the data table is a sample data.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
1
Code
Alphanumeric
64
Yes
The code for which the localized language is to be provided
2
Module
Alphanumeric
64
Yes
The module in which the code belongs to
3
Message(In English)
Text
256
Yes
The English language that is being displayed on the UI
4
Message(In Local Language)
Text
256
Yes
The text in the local language that the client wants to be displayed
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Present the client the full sheet of codes as well as the English language for which the localized texts are required.
Ask the client to fill the localized text in the last column which is the message(local language) column.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
SSL is Secure Sockets Layer is an encryption-based network security protocol developed for the assurance of privacy, authenticity and data integrity in internet communications.
Ideally, the domain name configuration and the SSL certification are obtained consecutively without fail from the state’s IT team.
No data is needed from the state team for this.
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
The SMS service is a way of communicating necessary information/updates to the users on their various transactions on DIGIT applications.
In order to update the users, there are certain notification parameters that are system configured for various steps in the application process. These configurations can be changed/reconfigured based upon the ULB requirements.
We have the below-mentioned parameters which we use for configuration:
Sr. No.
Parameter
Value
1
sms.provider.url
www.xyz.com
2
sms.username.parameter
mnsbihar@001
3
sms.username.value
***
The data given in the above table is sample data. The parameters and its values are SMS service provided specific and may vary accordingly.
For the SMS service to be integrated there are various things for which the vendor more or less guides us for the steps to be followed but below mentioned are a few basic steps and the generic data definitions which could be followed.
Below mentioned are the descriptions of the parameters which are needed for configuration:
Sr. No.
Column Name
Data Type
Data Size
Mandatory
Description
1
Parameter
Alphanumeric
64
Yes
The parameter required to be configured
2
Value
Alphanumeric
64
Yes
The corresponding value of the parameter
Parameter names could differ from vendor to vendor.
Since the SMS service is a vendor delivered service for which the below steps would have to be followed:
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
The SMS vendor has to provide the data in the data template attached.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of.
This checklist covers the activities which are specific to the entity.
Sr. No.
Checklist Parameter
Example
1
Make sure that the vendor should support multiple language functionality and especially the local language of the state.
-
The domain name is the address through which the internet users can access the website rather than entering the whole IP address in the search bar of the browser.
This domain name is ideally chosen by the state/client since its a product which has to be used for/by them.
Following is the table through which the information can be shared.
Sr. No.
Domain Name
EXTERNAL-IP
192.78.98.12
Data given in the table is a sample data.
Since all state governments/clients prefer to host the websites on their servers, this activity is ideally done by them.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
Domain Name
Alphanumeric
253
Yes
The name/address of the website being used to access the website/ module
EXTERNAL-IP
Alphanumeric
32
Yes
It is the IP address that has to be mapped to the domain name
Following are the steps which are to be followed:
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
If the state agrees to host the website on their server, provide them with the 2 columns mentioned in the attached template.
If the state disagrees to host on their server, then a domain name has to be purchased by any of the external vendors and the EXTERNAL-IP address has to be mapped with them.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of.
This checklist covers the activities which are specific to the entity:
Sr. No.
Checklist Parameter
Example
No mistake should be done in providing the EXTERNAL-IP address
-
2.
Only one domain name and its corresponding IP address have to be provided
-
A designation is an act of pointing someone out with a name, a title or an assignment. For example, someone being named president of an organization. This document is to help to gather various designations data which are generally used in ULBs.
Sr. No.
Designation Code*
Designation Name* (In English )
Designation Name* (In Local Language)
1
ACT
Accountant
अकाउंटेंट
2
AO
Accounts Officer
लेखा अधिकारी
3
AC
Additional Commissioner
अपर आयुक्त
Data given in the table is a sample data.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Designation Code
Alphanumeric
64
Yes
Unique Identifier for designation which is used as a reference for child configuration mapping
2
Designation Name (In English)
Text
256
Yes
Designation name in English
3
Designation Name (In Local Language)
Text
256
Yes
Designation Name in the local language. e.g. Hindi, Telugu etc. whichever is applicable
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify all the designations exists in the ULB, refer to governments gazette to define the designations in ULBs.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed after the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
To see the common checklist refer to the Checklist page consisting of all the activities which are to be followed to ensure complete and quality data.
This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.
This is the 3rd step that comes after the boundary data collection. Cross hierarchy mapping happens in case a child has a relationship with more than 2 parents. This double relationship between the child and parents could happen between different hierarchies as well.
For example: In Admin level boundary hierarchy a mohalla M1(child) could be a part of 2 Wards(parent) W1 and W2. In such a case a single Mohalla(child) has to be mapped to 2 Wards(parent).
Below is the data table for the Boundary:
Hierarchy Type
Hierarchy Type 1*
Hierarchy Type 2*
Sr.No
Boundary Type*
Boundary Code*
Boundary Type*
Boundary Code*
1
Ward
W1
Mohalla
M1
Ward
W2
Mohalla
M1
2
Ward
W3
Mohalla
M2
Ward
W4
Mohalla
M2
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Hierarchy Type 1
Text
256
Yes
2
Hierarchy Type 2
Text
256
Yes
3
Boundary Type
Text
64
Yes
4
Boundary Code
Alphanumeric
64
Yes
5
Boundary Type
Text
64
Yes
6
Boundary Code
Alphanumeric
64
Yes
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Firstly Identify all the child levels which have a relation with more than 2 parent boundary types and their hierarchy types as well.
Fill up the boundary hierarchy (names/ codes) types in place of boundary type 1/2.
Then along with the codes start filling in one by one with the proper mapping between every child and parent.
The Sr. No should be in an incremental order for every new child level.
Prepare a new table for every different parent-child relation.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity. There is no entity-specific checklist activity applicable here.
At times in the different modules, there is a need to capture the address of the user’s place of residence or where the person is doing a trade, for which the user has to enter his/her full address which creates a task. In order to simplify the process, we can have google map geolocation service in place which would help us get the exact coordinates of the place on the map and help us identify the place.
This service is paid and the client has to purchase the below items:
Google Map API's
https://developers.google.com/maps/documentation/javascript/get-api-key "Maps Javascript API", "Places API" and "Geolocation API" are needed and first 200$ usages are free, once it exceeds, the price per 1000 requests as given below.
Maps JavaScript API (web-client) Return the location and accuracy radius of a device, based on Wi-Fi or cell towers. $5
Geolocation API Return the location and accuracy radius of a device, based on Wi-Fi or cell towers. $5
Places API for Web (web-server) Turn a phone number, address, or name into a place, and provide its name and address. $17
Sr. No
Google API URL*
API Key*
1458-ASD785-987722
Note:
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
Google API URL
Alphanumeric
64
Yes
The URL of the API that is being purchased
2.
API Key
Alphanumeric
64
Yes
The key which the google would provide after the purchase for the API has been done
The data provided is sample data
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Ask the clients to purchase the above-mentioned APIs in the Introduction section.
Get the details for the API URL and key from the client.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
A ULB is divided into certain categories of boundaries by ULB administrative authorities in order to carry out ULB’s functions better. A ULB/City could be divided by a different set of delimitation of boundaries based on functions as given below.
Revenue - Delimitation of ULB into boundaries to perform the target setting and collection of revenue.
Administration - Delimitation of ULB into boundaries for the better administration of ULB.
Locality/ Location - Delimitation of ULB into boundaries based on the places known to citizen with names and easily identifiable by the common person.
All these authorities have designated certain levels of boundary classification for a certain ULB.
The below mention table is used to collect data for the types of hierarchy being followed:
Sr. No.
Code*
Boundary Hierarchy Type*
Description
1
ADM
Administration
Administration level boundary classified on the basis of administrative functions such as scrutinize certain rules and regulations
2
REV
Revenue
Revenue-based classification of a ULB is done on the basis of revenue collection
3
LOC
Locality
Location-based classification could be done in order to identify a certain place. For example, Locality of a house of a citizen could follow the below hierarchy:
House no.
Mohalla
Area
Ward
City
The above-mentioned data for the boundary hierarchy is sample data.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Code
Alphabet
64
Yes
Code is used to identify a certain classification of the type of boundary hierarchy
2
Boundary Hierarchy Type
Alphanumeric
256
Yes
The meaningful name to define one group of boundaries defined to perform one function
3
Description
Alphanumeric
256
Yes
A brief description of the boundary hierarchy
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Identify all the types of boundaries which are being used in the state in order to carry out various administrative/revenue functions.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Then fill up the hierarchy types and the codes in the respective columns in the template.
Code should be created for the type of boundary being classified.
A brief description of the boundary hierarchy type would be helpful.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity.
Sr. No.
Checklist Parameter
Example
1
Make sure that the hierarchies types should be uniform across all the ULB’s /cities in the state
-
2
Only 3 types of boundary hierarchies are allowed
-
Q. What if mandatory field value is not available and not filled?
The mandatory field value is must to provide, without having those filled into template data can not be accepted.
Q. What if non-mandatory field value is not available and not filled?
It is fine with not providing the non-mandatory field values. These are the fields which are nice to have.
Q. What if the codes are not readily available for the records?
Code is must to provided. In case, code is not readily available simple sequencing of numbers can be used as codes.
Q. What if the definition of column header is not clear?
Contact with the person who has shared the template with you.
Q. Can the order of the columns be changed while filling the data?
Order of columns must remain intact and should not be altered.
Q. What if the entities which are supposed to be defined at the state level but can not be defined?
In a case where the entities which are suggested to define at the state level does not work. Then those can be defined at ULB level but then again can not be moved to state-level once configured.
Q. What are the benefits of defining state level?
The benefits of defining the entity at the state level are given below.
Decision Support System - State level definition and consolidation of data makes data analysis and decision making easy.
Maintenance of such data is easy and correction can be performed quickly.
Avoids the data duplicacy in the configuration for those values which are most common across the ULBs.
Support standardization of processes rules across the ULBs.
Content of pages within this document is designed to help implementation parties and end-users in providing the required data in minimal interaction and iterations and ensure the quality, consistency and shape of data needed to configure into the system.
This page is intended to help stakeholders as given below on data gathering activities.
State Team
eGov Onsite Team/ Implementation Team
ULB Team (Nodal and DEO)
Implementation Partners
The artefacts of this document are the data template of a configurable entity, a page with content defining the entity template and helping on how to fill the template with required data.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
State Portal is a website for the state. Any content or information which is displayed on this site needs to be provided by the State.
This document is to define a template to collect the portal content and information. And to help in filling up the content into the template.
This section talks about the template and the table given below represents the template. Full template to fill with the portal content is attached with this page at the last into attachments sections.
This section consists of the information about the meaning of each and every section in the template and then how to fill the templates in a few easy steps.
Below table consist of a standard section of any portal. The additional section as required will have to capture as part of customization.
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
It is a ULB bank account which is operative at least to receive or deposit the day to day revenue collection done by the ULB. It is used by online payment integrator to disburse the amount in ULBs accounts which have been collected through a payment gateway into a pool account managed by the payment gateway.
Below given data table represents the excel template attached. Data given in the table is a sample data.
Data given in the table is sample data.
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify the bank account which is to be used to transfer the amount which is collected online for various services.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every checklist point/ activity mentioned in the checklist.
The checklist is a set of activities to be performed after the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
Human Resource Management System (HRMS) is a key module, a combination of systems and processes that connect human resource management and information technology through HR software. The HRMS module can be used for candidate recruiting, payroll management, leave approval, succession planning, attendance tracking, career progression, performance reviews, and the overall maintenance of employee information within an organization.
HRMS module enables users to -
Create User Roles
Create System Users
Employee Information Report
This is the next step after collating all the boundary hierarchies which are being used in the state. In a hierarchy, there are certain types of boundary classification and in all the levels there will be a mapping which we could define as a parent-child mapping in order to link certain levels of the classification.
For example, a hierarchy could be:
Administration Hierarchy: City/ULB → Zone → Ward → Locality
In the above-mentioned hierarchy, a City/ULB is being divided into different into zones followed by zones into wards and at the end wards into the locality.
Data has to be collected for every boundary hierarchy type and boundary type with a mapping between the boundary code and its parent boundary code. Following is the table which is to be used across all the hierarchy types.
Data given in the table is a sample data.
Following is the definition of the data columns which are being used in the template:
Following are the steps which should be used to fill the template:
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
After Identifying all the boundary hierarchy, get the sub-classification of all the hierarchies.
Figure out the codes for all the sub-classification for a particular city/ULB.
Start filling the template from the top of the hierarchy in a drill-down approach.
A parent-child mapping code has to be created for every boundary level except for the top level.
Follow the steps until you reach the last sub-classification.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
Master data templates allow users to configure the key parameters and details required for the effective functioning of the modules. This section offers comprehensive information on how to configure the master data templates for each module.
The individual master data templates for specific modules are availed in the Product & Modules section of our docs. Click on the links given below to navigate to view the specific module setup details.
All content on this page by is licensed under a .
States and ULBs can configure their web portal to deploy the DIGIT portal effectively. State-level and ULB level web portal configuration details are covered in this section.
All content on this page by is licensed under a .
A user role defines permissions for users to perform a group of tasks. In a default application installation, there are some predefined roles with a predefined set of permissions. Each role has a certain number set of tasks it is allowed to perform and these roles are Super Admin, Trade License Approver, Data Entry Admin and Trade License document verifier etc.
Data given in the table is sample data for reference.
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify all different types of user roles on the basis of ULB’s functions.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
A ULB portal is a specially designed website for a ULB that serves as the single point of access for information. It can also be considered a library of personalized and categorized content. A ULB web portal helps in search navigation, personalization, notification and information integration, and often provides features like task management, collaboration, and business intelligence and application integration.
This section tells about the template and table given below represents the template. Full template to fill with the portal content is attached with this page at the last into attachments sections.
Data given in the table is a sample data.
This section consists the information about the meaning of each and every section in the template and then how to fill the templates in a few easy steps.
Below table consist of a standard section of any portal. The additional section as required will have to capture as part of customization.
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers all the activities which are specific to the entity.
A system user is a person who uses the application service. A user often has a user account and is identified to the system by a username. A user is a person who accesses a particular application to perform a set of actions.
Each user has a certain number of set tasks, the user would be allowed to perform a task by assigning particular roles which are Super Admin, Trade License Approver, Data Entry Admin and Trade License document verifier etc.
Data given in the table is sample data for reference.
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
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.
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.
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.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The type of hierarchy 1 the boundary belongs to which is to be mapped with other boundaries in hierarchy 2. Refer
The type of hierarchy 2 the boundary belongs to which is to be mapped with other boundaries in hierarchy 1. Refer
This is the type of boundary from hierarchy 1. Refer
This is the code of the boundary for the boundary from hierarchy 1. Refer
This is the type of boundary from hierarchy 2. Refer
This is the code of the boundary for the boundary from hierarchy 2. Refer
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.
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 is licensed under a .
All content on this page by is licensed under a .
To see the common checklist refer to the page consisting of all the activities which are to be followed to ensure complete and quality data.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
Sr. No
Section Name
Section Content
1
Government Logo
2
Chief Minister Message
.
.
.
.
20
About Website
Sr. No.
Section Name
Data Type
Data Size
Is Mandatory?
Description / Definition
1
Government Logo
Document
N/A
Yes
Resolution: 80 * 80 pixels
Logo of the state to be updated on the website
2
Governor’s Message
Template
N/A
Yes
Message from the governor of the state to the citizens needs to be updated under this section
3
Chief Minister Message
Template
N/A
Yes
Message from the chief minister needs to be updated under this section
4
State News
Template
N/A
Yes
Under this section we have will add current news about the state
5
State Events
Template
N/A
Yes
Under this section, we will add the Ongoing and Upcoming Events in the state
6
Recruitment Listing
Template
N/A
Yes
Recruitment listing/vacancies within the state need to be mentioned in this section
7
Tender Listing
Template
N/A
Yes
All the tender issued by the state government needs to be added under this section
8
Project Info
Template
N/A
Yes
All the Information of upcoming or ongoing project within the state should be added under this section
9
Recent Announcement
Template
N/A
Yes
Any kind of announcements by the state government with title and description which are in public interest needs to be uploaded under this section
10
Home Screen Flash Announcement
Template
N/A
Yes
Any kind of announcements by the state government with title and description and by highlighting link which are in public interests can bee added under this section
11
Public Notice
Template
N/A
Yes
The notices announced by the state government for the citizens with description, Rule and Regulation and timelines
12
Government Resolution
Template
N/A
Yes
Directions, resolutions, and other legal instruction and acts issued by the department should be captured here
13
RTI Listing
Template
N/A
Yes
All the RTI received by the state government shall be listed under this section
14
Help Document for Online services
Template
N/A
Yes
Under this section, we will add the Document or link with the title of online services for citizens
15
Required documents list for Online Services
Template
N/A
Yes
This section tells us about the list of required documents and data like old receipt or old transaction no for each service
16
Forms for services
Template
N/A
Yes
This section tells us about the services are not online, offline forms can be uploaded for the users to download
17
Contact Us
Template
N/A
Yes
All details of the contact person should be added under this section
18
List of ULBs (links to the ULB sites)
Template
N/A
Yes
All website Link of ULBs within the state should be added under this section
19
About Website
Template
N/A
Yes
This section talks about the all over details whatever is there on the state website
20
Tourist Places
Template
N/A
Yes
Under this section, we will add all the tourist place in the state with details and images
21
Slider Images
Document
N/A
Yes
Slider images of resolution 1280 * 450 pixels to be shown on the website
22
State Map
Document
N/A
Yes
This section will have a map for the State
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Sr. No.
Checklist Parameter
Example
1
All the sections with data type ‘Template’, data to be filled into the section-wise template provided as an attachment
NA
Sr. No.
Code*
ULB Name*
Bank Name*
Branch Name*
Account Number*
Account Type*
IFSC*
1
dehradun
Dehradun Municipal Corporation
SBI
Rajpur
XXXX0082XX01
Saving
SBIX0921
2
haridwar
Haridwar Municipal Corporation
PNB
Chauk
XXXX9820XX9
Saving
PNBX8320
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory
Definition/ Description
1
Code
Alphanumeric
64
Yes
Unique code is given to the bank detail record e.g. dehradun
2
ULB Name
Text
256
Yes
Name of Urban Local Body
3
Bank Name
Text
256
Yes
Name of the bank where the account exists
4
Branch Name
Text
256
Yes
Name of the bank branch where the account exists
5
Account Number
Alphanumeric
64
Yes
Bank account number to be used to transfer the amount
6
Account Type
Text
256
Yes
Account type. e.g. Saving, Current etc.
7
IFSC
Alphanumeric
64
Yes
IFS code of branch as per FBI guidelines
Sr. No.
Activity
Example
1
Code should not consist of any special characters
E.g. dehradun is allowed but dehradun@1 is not allowed
2
The account number should not consist of any special characters.
As issued by the bank
Sr. No.
Boundary Code*
Boundary Name* (In English)
Boundary Name* ( In Local Language)
Parent Boundary Code*
Boundary Type*
Hierarchy Type Code*
1
W1
Ward no.1
वार्ड नंबर 1
Z1
Ward
ADM
2
W2
Ward no.2
वार्ड नंबर 2
Z1
Ward
ADM
3
W3
Ward no.3
वार्ड नंबर 3
Z2
Ward
ADM
4
W4
Ward no.4
वार्ड नंबर 4
Z3
Ward
ADM
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
1
Boundary Code
Alphanumeric
64
Yes
This is a code for the sub-classification for a particular boundary. Should be unique across all boundaries defined
2
Boundary Name (In English)
Text
256
Yes
The name of the boundary that is being defined in the English language
3
Boundary Name (In Local Language)
Text
256
Yes
The name of the boundary that is being defined in the local language of the state e.g. Telugu, Hindi etc.
4
Parent Boundary Code
Alphanumeric
64
Yes
This is the boundary code of the parent which identifies to which parent the child belongs to
5
Boundary Type
Text
256
Yes
The name of the boundary type i.e. Ward, Zone etc.
6
Hierarchy Type Code
Alphanumeric
64
Yes
The code of the Boundary Hierarchies for which this particular boundary is defined
Sr. No.
Activity
Example
1
Make sure that each and every point in this reference list has been taken care of
Sr. No.
Activity
Example
1
Every boundary type of data should be filled separately
-
Sr. No.
Code*
Name*
Description
1
TL_APPROVER
TL Approver
Trade License Approver
2
GRO
Grievance Routing Officer
Grievance Routing Officer
3
CSR
Customer Support Representative
An employee who files and follows up complaints on behalf of the citizen
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Code
Alphanumeric
64
Yes
A unique code that identifies the user role name.
2
Name
Text
256
Yes
The Name indicates the User Role while creating an employee a role can be assigned to an individual employee
3
Description
Text
256
No
A short narration provided to the user role name
Sr. No
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Sr. No.
Activity
Example
1
The Code should be alphanumeric and unique
TL_APPROVER, GRO
2
The Name should not contain any special characters
TL Approver : [Allowed]
#TL Approver! : [Not allowed]
Sr. No.
Section Name
Section Content
1
City Introduction
Kesariya Stupa is a Buddhist stupa in Kesariya, located at a distance of 110 kilometres (68 mi) from Patna, in the Champaran (east) district of Bihar, India. Kesaria Stupa has a circumference of almost 1,400 feet (430 m) and raises to a height of about 104 feet (32 m).
2
Mayor’s Message
It is with immense gratitude to the citizens of Kesaria for reposing their faith in me to serve them as Chairman of Kesaria Nagar Panchayat that I write this message. I shall endeavour to prove that they have made the right choice.
.
.
.
.
22
Contact Us
All details of the contact person should be added under this section.
Sr. No.
Section Name
Data Type
Data Size
Is Mandatory?
Description/ Definition
1
ULB Logo
Document
N/A
Yes
Logo of resolution: 80 * 80 pixels of the ULB to be shown on the top of the website.
2
Slider Images
Document
N/A
Yes
Slider images of resolution 1280 * 450 pixels to be shown on the website.
3
City Introduction
Text
N/A
Yes
This section talks about the city hence introducing the city to be filled here to display it to the final audience/traffic onto the portal
4
City Map
Document
N/A
Yes
This section will have a map for the city mainly the area which the municipality/ panchayat takes care of and which indicates ULB boundary
5
Public Utility Services
Template
N/A
Yes
This section should include the infrastructure services provided to the citizen. E.g. Public Toilet, Govt School, Temples managed by Municipal Corporations/ Nagar Palika/ Panchayat etc.
6
Tourist Locations
Template
N/A
Yes
All tourist places in the city should be captured under this section. Tourist locations with pictures and other relevant information should be captured here
7
Mayor’s Message
Template
N/A
Yes
Message from the ULB chairman needs to be updated under this section
8
Commissioner’s Message
Template
N/A
Yes
Message from the ULB’s EO/commissioner needs to be updated under this section
9
ULB News
Template
N/A
Yes
Under this section we have will add current news about the ULB
10
ULB Events
Template
N/A
Yes
Under this section, we will add the Ongoing and Upcoming Events by the ULB
11
Recruitment Listing
Template
N/A
Yes
Recruitment listing/vacancies within the ULB needs to be mentioned in this section
12
Projects Info
Template
N/A
Yes
The description of the govt. Projects which ULBs take care of needs to be updated here with all other relevant details
13
Recent Announcements
Template
N/A
Yes
Any kind of announcements with title and description which are in public interest needs to be uploaded under this section
14
Home screen flash Announcement
Template
N/A
Yes
Any kind of announcements with title and description and by highlighting link which are in public interests can bee added under this section
15
Public Notice
Template
N/A
Yes
The notices announced by the ULB for the citizens with description, Rule and Regulation and timelines
16
Government Resolutions
Template
N/A
Yes
Directions, resolutions, and other legal instruction and acts issued by the department should be captured here
17
RTI listing
Template
N/A
Yes
All the RTI received by the ULBs shall be listed under this section
18
Help Documents for Online Services
Template
N/A
Yes
Under this section, we will add the Document or link with the title of online services for citizens
19
Required documents list for Online Services
Template
N/A
Yes
This section tells us about the list of required documents and data like old receipts or old transaction no for each service
20
Forms for services
Template
N/A
Yes
This section tells us about the services are not online, offline forms can be uploaded for the users to download
21
Tender Listing
Template
N/A
NO
All the tender issued by the ULB needs to be added under this section
22
Contact Us
Template
N/A
Yes
All details of the contact person should be added under this section
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of.
Sr. No.
Checklist Parameter
Example
1
All the sections with data type ‘Template’, data to be filled into the section-wise template provided as an attachment
NA
Sl No.
Name*
Mobile No*
Father/Husband's Name *
Gender *
Date of Birth*
Correspondence Address *
ULB*
Role*
Employment Type *
Current Assignment
Status *
Hierarchy *
Boundary Type *
Boundary *
Assigned from Date*
Department*
Designation*
1
Pooja
9999999999
Mr.Bala Chandra
FEMALE
22/01/1987
Nagar Nigam Haldwani-PIN CODE-263139
Haldwani
Super User
PERMANENT
Yes
EMPLOYED
REVENUE
City
Haldwani
05/10/2019
Revenue
Tax Inspector
2
M.C. Joshi
9999999999
Late Jai Dutt Joshi
MALE
04/08/1965
Nagar Nigam Haldwani
Haridwar
TL Counter Employee
PERMANENT
Yes
EMPLOYED
REVENUE
City
Haldwani
30/10/2019
Revenue
Tax Collector
Sr No
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Name
Text
256
Yes
The Name of his/her to whom the access to the system is provided, so he/she can use the application to perform the role function assigned
2
Mobile Number
Alphanumeric
10
Yes
The Mobile number of his/her to whom the access to an application provided. The mobile number is relevant so in an emergency case the person can be contacted
3
Father/Husband's Name
Text
256
Yes
The Name of the Father/Husband of his/her to whom the access to an application provided. This information is for internal records
4
Gender
Text
64
Yes
The Gender of the individual person. This information is for internal records
5
Date of Birth
Date
10
Yes
The Date of birth of the individual person. This information is for internal records
6
Alphanumeric
256
No
The email id of his/her, this email id is linked to receiving all the official communication from the customers and other counterparts
7
Correspondence Address
Text
256
Yes
The address of his/her, this information is saved for internal records
8
ULB
Text
256
Yes
A ULB to be assigned against the individual employee, So that the assigned role can perform his/her duty within that assigned ULB
9
Role
Text
256
Yes
A Role is a permission for users to perform a group of tasks, a role is assigned to the user to perform a function within the application. A user can be assigned multiple roles. Click User Roles for the Role master Data
10
Employment Type
Text
256
Yes
The employment types indicate the type of contract which he/she hold with the organization. This indicates whether he/she is a permanent employee or a contract employee for short period. The employment type “Permanent”, “Temporary”, “DailyWages” and “Contract” either one should be selected
11
Current Assignment
Text
64
Yes
The current assignment type to indicate whether the employee is currently assigned to a particular department and designation. A user can be also be assigned multiple assignments to perform his/her function
12
Status
Text
256
Yes
The Status indicates the type of status which he/she hold, whether employed or not within the organization
13
Hierarchy
Text
256
Yes
The hierarchy indicates the hierarchy type for the Boundary to which he/she is assigned
14
Boundary Type
Text
256
Yes
The boundary type indicates assigning a city to his/her role within the organization. A user can be assigned multiple Boundary Type to perform in different function. (Example: City, Zone, Block and Locality)
15
Boundary
Text
256
Yes
The boundary indicates assigning a particular city to his/her role wherein they perform role function of the application for the particular city. A user can be assigned multiple Boundary to perform in a different location (Example: City Name and Tenant Zone)
16
Assigned from Date
Date
10
Yes
The assigned from date indicates the date from which his/her role is assigned to perform the role function assigned
17
Department
Text
256
Yes
The Department indicates the particular department to which his/her role is assigned
18
Designation
Text
256
Yes
The designation indicates a particular designation is assigned to his/her role
Sr. No
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Sr. No.
Activity
Example
1
The Name should not have any special character
Pooja : [Allowed]
#Pooja! : [Not allowed]
2
The date should be in DD/MM/YYYY format
DD/MM/YYYY : [Allowed]
YYYY/DD/MM : [Not allowed]
3
The Email ID should be valid Id, email Id should contain the Company/Firm name or an individual personal name before the “@” and the “XXXXX.com” after the “@”
Details coming soon!!
Details coming soon!!
Details coming soon...
Details coming soon...
Details coming soon...
Tax is levied by the government in certain brackets, i.e there are certain components of a tax which sum up and make the final trans-actionable amount. For example, a property tax could have swatch-ta tax, fire cess and certain other components which sum up and make a final amount.
Sr. No.
Code*
Service*
Category*
Name*
Is Debit*
Is Actual Demand*
Order*
1
PT_UNIT_PENALTY
PT
Penalty
PT Penalty
FALSE
FALSE
1
2
PT_UNIT_EXEMPTION
PT
Exemption
PT Exemption
TRUE
TRUE
2
Data given in the table is sample data for reference.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
1.
Code
Alphanumeric
64
Yes
The code for the tax that is being levied
2.
Service
Text
256
Yes
This is the module or the name of the service for which the tax head is being mentioned
3.
Category
Text
256
Yes
The category to which the tax head belongs such as Penalty or exemption or cess
4.
Name
Text
256
Yes
This is the name/description of the tax head
5.
Is Debit
Text
NA
Yes
In case the tax head is an amount that needs to be added up to the property tax, then this needs to be TRUE else FALSE
6.
Is Actual Demand
Text
NA
Yes
In case the tax head is an amount that needs to be subtracted from the property tax, then this needs to be TRUE else FALSE
7
Order
Integer
5
Yes
The order in which the mentioned tax head should appear on the screen
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Get all the tax heads for a particular module and then proceed to the next module.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed on the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Tax is levied by the government in certain brackets, i.e there are certain components of a tax which sum up and make the final trans-actionable amount. For example, a property tax could have swatch-ta tax, fire cess and certain other components which sum up and make a final amount.
Sr. No.
Code*
Service*
Category*
Name*
Is Debit*
Is Actual Demand*
Order*
1
PT_UNIT_PENALTY
PT
Penalty
PT Penalty
FALSE
FALSE
1
2
PT_UNIT_EXEMPTION
PT
Exemption
PT Exemption
TRUE
TRUE
2
Data given in the table is sample data for reference.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
1.
Code
Alphanumeric
64
Yes
The code for the tax that is being levied
2.
Service
Text
256
Yes
This is the module or the name of the service for which the tax head is being mentioned
3.
Category
Text
256
Yes
The category to which the tax head belongs such as Penalty or exemption or cess
4.
Name
Text
256
Yes
This is the name/description of the tax head
5.
Is Debit
Text
NA
Yes
In case the tax head is an amount that needs to be added up to the property tax, then this needs to be TRUE else FALSE
6.
Is Actual Demand
Text
NA
Yes
In case the tax head is an amount that needs to be subtracted from the property tax, then this needs to be TRUE else FALSE
7
Order
Integer
5
Yes
The order in which the mentioned tax head should appear on the screen
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Get all the tax heads for a particular module and then proceed to the next module.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed on the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Key Performance Indicators(KPI) are a way of showing certain insights from the data available which would help the key management authorities to take important business decisions in order to improve the business, enhance the business process and help the people improve the way of functioning. This exercise largely becomes dependent on the data.
The insight could be shown in various available forms such as line graph, bar graph or a tabular format.
Sr. No
Module*
KPI Chart Type*
Description*
PGR
Line Chart
Showing the status of closed complaints over a year month-wise
Pie Chart
Showing the various type of complaints
Metric
Showing the rate of different complaint status by percentage in a tabular format
2.
Property Tax
Horizontal Bar Graph
Showing the various information about property application status month-wise over a year
Sr. No.
Column Name
Data Type
Data Size
Mandatory
Description
1
Module Name
Text
256
Yes
The name of the module for which the KPI chart types have to be defined
2
KPI Chart Type
Text
256
Yes
The type of chart which has to display information
3
Description
Text
256
Yes
A brief description of the information that the chart has to display. Steps to fill Data
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Present the client with information about various available chart types.
Show the client how the various KPI’s will look on the web page by showing the reference page from the attachments.
After which the gather the information for various chart types and the information that the chart types have to display in the description column.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity:
Sr. No.
Checklist Parameter
Example
Make sure that the chart types are chosen from the list of available chart types from the attachment section
-
The Billing and Payments module serves the billing requirements of various ULB departments. The module caters to fulfil the demands generated by the revenue collection needs of the business services.
The module enables ULBs to -
Generate bills
Search bills
Update bills
ULB Level
None
Bill format can be configured on a module level. Few components on the DIGIT sample bill can be configured on a state level and few at ULB level. Components that can be changed on a module level can be categorized as mentioned:
Important messages: Values can be configured on a module level - state level
Sr. No.
Business
Category
Particulars
1
Water Charges
Important messages
5% rebate to be given on advance payment on the bills
Data given in the table is sample data for reference.
Sr. No.
Column Name
Data Type
Data Size
Mandatory
Description
1
Category
Text
64
Yes
To list out the components on the bill, every particular can be grouped into a category
2
Particulars
Alphanumeric
256
Yes
Each category can have multiple entries under it, ie particulars
3
Business
Text
64
Yes
The business for which the Bill format is to be configured
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Get information about the bill format followed by state
Classify the components on the bill and place it under any category
Map the particulars under each category with DIGIT sample bill
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No.
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Entity Specific Checklist is not required separately.
Workflow levels are defined for a service with Rights/Role to perform a set of Workflow Actions. There would one or more than one levels involved in a workflow process. This page helps to understand and then define all the levels with its job description and fill in a standard template.
Sr. No.
Module
Service
Workflow Level
Task
Role
1
Finance
Bill Accounting
Level 1
Create Bill
Accounts Clerk
2
Finance
Bill Accounting
Level 2
Create and Approve
Accounts Clerk
3
Finance
Bill Accounting
Level 3
Forward for Approval
Chief Accountant
4
Finance
Bill Accounting
Level 4
Verify the Bill
Chief Accountant
5
Finance
Bill Accounting
Level 5
Approval
Approver
Data given in the above table is sample data.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Module
Text
64
Yes
The module indicates for which the user would be mapped for a specific module to perform the action
2
Service
Text
64
Yes
The service indicates the type of process which the user performs in a particular module
3
Workflow Level
Integer
2
Yes
The workflow level indicates when a process has executed the level at which the flow of the process in progress
4
Task
Text
64
Yes
The task refers to which state the action is in progress during the workflow
5
Job Description
Text
256
Yes
A short description provided for the role (Example: Designation of the Role)
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify all different types of services on the basis of ULB’s functions to create a workflow.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Please discuss with a relevant department head before finalizing the workflow.
Workflow action defined as an activity which is performed by a workflow user on a service request/ application during the workflow. All the workflow actions are predefined and performed a well-defined job once performed.
In its nature actions are not configurable, only the localization of actions is permissible as a configuration.
S. No.
Action
Description
Module(s)
1
Initiate
The action will start the application for citizen and CEMP
Trade Licenses, Property Tax, Building Plan Approval
2
Edit
Using this action the application can be opened in editable form and any changes can be performed
Trade Licenses, Property Tax, Building Plan Approval
3
Submit
This action will freeze the application from citizen or CEMP and proceed further for workflow
Trade Licenses, Property Tax, Building Plan Approval
4
Verify and Forward
This action will proceed application to the next stage of the workflow process and also assigns tasks to the next user in the workflow (if needed)
Trade Licenses, Property Tax, Building Plan Approval
5
Pay
This action will help to pay application fees
Trade Licenses, Property Tax, Building Plan Approval
6
Approve
This action will be the last stage of application workflow which will grant permission for a specific application
Trade Licenses, Property Tax, Building Plan Approval
7
Activate connection
This action will create a consumer no. against the application and demand generation can start
Water and Sewerage Charges
8
Reject
This action will reject the application, the application rejected can’t be processed further or with the help of it, citizens can not re-apply. He has to start a new application next time.
Trade Licenses, Property Tax, Building Plan Approval
9
Send Back
An actor can assign back the application to the previous state if any edits/changes are required
Trade Licenses, Property Tax, Building Plan Approval
10
Send Back to Citizen
An actor can assign back the application to the citizen if any edits/changes are required
Trade Licenses, Property Tax, Building Plan Approval
11
View
Anyone in the workflow can view the application and task details
Trade Licenses, Property Tax, Building Plan Approval
12
Comment
Comments can be recorded before any action is taken which can change the state of the application
Trade Licenses, Property Tax, Building Plan Approval
13
Download/ Print
Download/Print of any artefacts can be configured as per the requirement for application processing
All Modules
14
Forward
This action will not create any bill but will be forwarded to the next level review and approve
Finance
15
Create and Approve
In this action, the user who initiates the action can create and approve the bill. (Here there should a threshold amount to be set up)
Finance
16
Save
In this action, the approver can Save the bill before it is approved or rejected
Finance
17
Verify and Approve
This action will help the approver to approve the bill if he/she feels all the information is updated correctly
Finance
18
Reject
This action will help the approver to reject the bill if he/she feels all the information is not correct and may need further clarification.
Finance
19
Send back to Assistant
This action will help to send back the notification on the bill is rejected from the approver
Finance
20
Cancel
This action will help the approver to cancel the bill if he/she feels that the bill need to be rejected
Finance
Actions are standard and are not configurable, hence the template, data definition and standard procedure to fill the template are not needed. This page is created to provide the information and helping the defined workflow process.
Not applicable
Not applicable
Not applicable
Not applicable
The workflow process is a set of steps through which information flows in sequence and the workflow roles which derives the actors are assigned to a step to complete the work defined for that level. The states of each level are derived based on the information received from the previous step.
Sr. No.
Current State
Workflow Actions
Next State
Role Name
SLA
1
Create and Approve
Approved
Assistant
NA
2
Forward
Pending for Approval
Assistant
NA
3
Pending for Approval
Verify and Approve
Approved
Supervisor
NA
4
Pending for Approval
Save
Pending for Approval
Supervisor
NA
5
Pending for Approval
Reject
Rejected
Supervisor
NA
6
Pending for Approval
Send Back to Assistant
Rejected for Review
Supervisor
NA
7
Rejected for Review
Forward
Pending for Approval
Assistant
NA
8
Rejected for Review
Cancel
Rejected
Assistant
NA
Data given in the above table is sample data.
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
Current State
Text
256
Yes
The Current State indicates the stage at which the process of the workflow in progress
2
Action
Reference
64
Yes
The Action indicates the activity that can be performed at the respective stage in the workflow. This refers to Workflow Actions
3
Next State
Text
256
Yes
The Next State is the state in the workflow that gets updated to in the respective stage on performing the action. (Example: assigning the for approval from one person to next person)
4
Role Name
Reference
64
Yes
The role is the different hierarchy of people with designation who are authorized to initiate, approval or rejecting the process. It refers to Workflow Levels
5
SLA
Integer
2
No
The SLA indicates the time-frame within which the action to be completed
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Sr. No
Checklist Parameter
Example
1
Make sure that each and every point in this reference list has been taken care of
Please discuss with a relevant department head before finalizing the workflow.
The checklist is the set of activities which are there to perform on completion of a task to ensure the fullness and quality of the task.
The data type is an attribute of data, is a particular kind of data item, as defined by the values it can take, the computer system used, or the operations that can be performed on it. In order to help to fill the right kind of data for a data field/ column in excel, the below-given table has different data types with its description.
Sr. No.
Data Type
Definition/ Description
1
Alphanumeric
It contains alphabets and numbers. And generally used to define the code
2
Decimal
Floating point number with a fraction value up to 2 decimal places
3
Integer
Whole number without having a fraction part in it
4
Text
A string of alphabets, numbers, spaces, and symbols
5
Date
It represents a date and is captured in the format of ‘DD/MM/YYYY’
6
Reference
It is a code of a record from the referred entity and having a related record in the prevailing entity
7
Document
It represents a document which is needed as an attachment with other relevant details in the template
Sr. No.
Activity
Example
1
The entity is to be decided to be defined at the state level and all the ULBs are agreed on the same.
NA
2
Data filled into templates should cater to the needs of each and every ULBs.
NA
Sr. No.
Activity
Example
3
Order of headers should remain unchanged in the template while filling the data.
NA
4
Value filled into the template doesn’t exceed the given data size limit.
NA
5
Codes filled in the template for all the records are unique. It means no 2 records in the template share the same code.
Below records in code, value pair is not acceptable.
RES - Residential
RES - Non-residential
6
All the columns marked with an asterisk must be filled with the values and not even a single record left without a value.
NA
7
Reference value in the template must also exist in the referred entity template. A value without being present in the referred entity template is invalid.
NA
8
None of the values filled in the template should have a character which is not allowed.
NA
9
Mobile Numbers filled into the template must be 10 digit valid mobile numbers without country code.
NA
10
Email id filled into template should be a valid email ID.
NA
11
Local language values should be Unicode charset only.
NA
S.No.
Activity
Example
12
Values of data type alphanumeric consist of the alphabet and numeric values only. All the entity code should follow this.
Allowed - ABC01
Not allowed - ABC#01
13
Values of data type decimal must be a number having fraction part up to 2 places of decimal.
Allowed - 23.87
Not allowed - 12.0982
14
Values of data type integer must be a number which is not a fraction but a whole number.
Allowed - 15
Not allowed - 12.01
15
Values of data type text must be a string of alphabets, numbers, special characters, and spaces.
NA
16
Values of data type date must be a date in the format ‘DD/MM/YYYY’. Here DD means day, MM means month and YYYY means years.
Allowed - 31/12/2019
Not allowed - 12/31/2019, 31/12/19, etc.
17
Values of data type reference must be a reference to another entity referring to a value in that entity. Only the code of the referred record from the referred entity is provided as a value here.
NA
18
Value of the data type document must be a document which is to be provided separately as an attachment while submitting the data along with a filled data template.
NA
Document list represents the documents which are needed to avail a service across the modules. Mostly these are standard documents issued by various government departments.
Sr. No.
Code
Document Name
Purpose
Description
1
RC
Ration Card
ID Proof, Address Proof
This document is used as proof of identity if presented with photo and address proof.
2
AC
Aadhar Card
ID Proof, Address Proof
This document is used as proof of identity as well as address.
3
DL
Driving License
ID Proof, Address Proof
This document is used as proof of identity as well as address.
4
VC
Voter ID Card
ID Proof, Address Proof
This document is used as proof of identity as well as address.
5
PS
Passport
ID Proof, Address Proof
This document is used as proof of identity as well as address.
6
AL
Arms License
ID Proof, Address Proof
This document is used as proof of identity as well as address.
7
CC
Cast Certificate
ID Proof, Address Proof
This document is used as proof of identity if presented with photo and address proof.
8
DC
Domicile Certificate
ID Proof, Address Proof
This document is used as proof of identity if presented with photo and address proof.
9
PC
PAN Card
ID Proof
This document is used as proof of identity.
10
EB
Electricity Bill
Address Proof
This document is used as proof of address only.
11
TB
Telephone Bill
Address Proof
This document is used as proof of address only.
12
WB
Water Bill
Address Proof
This document is used as proof of address only.
13
RSA
Registered Sale Agreement
Address Proof
This document is used as proof of address only.
14
RLA
Registered Lease Agreement
Address Proof
This document is used as proof of address only.
15
VRC
Vehicle Registration Certificate
Address Proof
This document is used as proof of address only.
16
IAO
Income Tax Assessment Order
Address Proof
This document is used as proof of address only.
17
HT
House Tax Slip
Others
These are the documents which are specifically needed to avail a service.
18
FL
Food License
Others
These are the documents which are specifically needed to avail a service.
19
LL
Liquor Licence
Others
These are the documents which are specifically needed to avail a service.
20
GST
GST Registration
Others
These are the documents which are specifically needed to avail a service.
Every Service integrated with egov-workflow-v2 service needs to first define the workflow configuration which describes the states in the workflow, the action that can be taken on this states, who all can perform those action, SLA etc. This configuration is created using API’s and is stored in DB. The configuration can be created either state level or tenant level based on the requirements.
Before you proceed with the configuration, make sure the following pre-requisites are met -
egov-workflow-v2 service is up and running
Role Action mapping is added for the BusinessService API’s
Create and modify workflow configuration
Configure State level as well BusinessService level SLA
Control access to workflow actions from the configuration
Validates if the flow defined in the configuration is complete during the creation
Deploy the latest version of egov-workflow-v2 service
Add Role-Action mapping for BusinessService API’s (preferably add _create and update only for SUPERUSER. search can be added for CITIZEN and required employee roles like TL__CEMP etc. )
Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)
Add businessService persister yaml path in persister configuration
Create the businessService JSON based on product requirement. Following is a sample json of a simple 2 step workflow where an application can be applied by citizen or counter employee and then can be either rejected or approved by the approver.
Once the businessService json is created add it in the request body of _create API of workflow and call the API to create the workflow.
To update the workflow first search the workflow object using _search API and then make changes in the businessService object and then call _update using the modified search result. (States cannot be removed using _update API as it will leave applications in that state in an invalid state. In such cases first, all the applications in that state should be moved forward or backward state and then the state should be disabled through DB directly)
The workflow configuration can be used by any module which performs a sequence of operations on an application/Entity. It can be used to simulate and track processes in organisations to make it more efficient and increase accountability.
Integrating with workflow service provides a way to have a dynamic workflow configuration which can be easily modified according to the changing requirements. The modules don’t have to deal with any validations regarding workflow such as authorisation of the user to take an action if documents are required to be uploaded at certain stage etc. as they will be automatically handled by egov-workflow-v2 service based on the configuration defined. It also automatically keeps updating SLA for all applications which provide a way to track the time taken by an application to get processed.
To integrate, host of egov-workflow-v2 should be overwritten in helm chart
/egov-workflow-v2/egov-wf/businessservice/_search should be added as the endpoint for searching workflow configuration. (Other endpoints are not required once workflow configuration is created)
The configuration can be fetched by calling _search API
(Note: All the API’s are in the same postman collection therefore the same link is added in each row)
__
Configuring Report for a module requires adding the required report configuration as per the standard format and with the minimum development time.
UI can have different types of filters such as date, dropdown etc.. and even the sum of a column can also be easily displayed in UI. Pagination and downloading the report in pdf format, xls format is already present in the report UI.
Type of Reports which can be configured :
Count of applications
Statewide collections
Application status
Cancelled receipts
Migrated records / Data entry records
Limitation of this framework is for reports having requirements with complex queries with multiple joins as the report uses the query to fetch the data from the database, It is resource-intensive and response might be slow in those scenarios.
Before you proceed with the configuration, make sure the following pre-requisites are met -
User with permissions to edit the git repository to add the report configuration
User with permissions to add action and role action in the mdms
Showcase the data in the required and cleaner format.
The UI is rendered with the help of configuration in the report and there is no extra effort in building UI for different reports.
For Implementation specific report requirements, customization is easy and turn around time is less.
After adding the new report/ editing existing report configuration in the respective module, the report service needs to be restarted.
Create a reports.yml file and add report configuration as per standard format.
Add the action and role action in the mdms.
Add the github raw path of the report.yml file in the report.config file
The objective of PDF generation service is to bulk generate pdf as per requirement. This document contains details about how to create the config files which are required to generate new pdf.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Prior knowledge of JavaScript.
Prior knowledge of Node.js platform.
JSONPath for filtering required data from json objects.
Provide flexibility to customise the PDF as per the requirement.
Supports localisation.
Provide functionality to add an image, Qr Code in PDF.
Provide functionality to call external service for creating PDF with external service response
Create data config and format config for a PDF according to product requirement.
Add data config and format config files in PDF configuration
Add the file path of data and format config in the environment yml file
Deploy the latest version of pdf-service in a particular environment.
Config file: A json config file which contains the configuration for pdf requirement. For any pdf requirements, we have to add two configs file to the service.
PDF generation service read these such files at start-up to support PDF generation for all configured module.
Sample structure of variable definition in data config
Example to show date in PDF
Example of external API calling to MDMS service
Example of adding Qr Code
For adding Qr code there is separate mapping with the name “qrcodeConfig“ in data config. This mapping can use variables defined in “direct” and “external“ mappings along with the static text. The information on the QR Code scan will be defined as value. The variable defined in this mapping can directly be used in the format config as an image. ex:-
Data Config for Qr Code:
Example of adding footer in PDF (adding page number in the footer)
Example of adding Qr Code
Format Config for Qr Code
For Integration with UI, please refer to the links in Reference Docs
(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)
__
Through report service, useful data get shown for a specific module based on some given criteria like date, locality, financial year, etc.
For example, PT dump report of property tax service you have to select from date to date, financial year etc and based on the criteria we can see all the data full filling the criteria. In the response we see all the details of a property which is paid between the given from date and to date, if we selected financial year then we can see the property which is paid for that specific financial year.
Before you proceed with the configuration, make sure the following pre-requisites are met -
User with permissions to edit the git repository where Reports are configured and knowledge on YAML.
Prior Knowledge of YAML.
Prior Knowledge of SQL queries.
Prior Knowledge of the relation between the tables for which module you are going to write a report.
User can write queries (like SQL queries) for fetching the real-time data to display in a UI application.
User can apply filters like from date, to date, financial year, etc based on the report configuration.
User can download the result in PDF and XLS format.
User can select or deselect the columns user wants to see.
User can choose the number of records he/she wants to see on a page.
Once the changes have been done in the report configuration file we have to restart the report service so the report service will read the new configuration.
<Module Name>=file:///work-dir/configs/reports/config/<report file name>.yml
ex: pgr=file:///work-dir/configs/reports/config/pgr-reports.yml
Write the report configuration. Once it is done commit those changes.
Add the role and actions for the new report.
Restart the MDMS and report service.
Rainmaker has report framework to configure new reports. As part of the report configuration, we have to write a native SQL query to get the required data for the report. So if the query takes huge time to execute or query result has huge data, then it will impact on the whole application performance.
The following cases where we can see the application performance issue because of heavy reports.
Filtering with long date range data or applying fewer filters which in turns return huge data
Join the multiple tables for getting required data and missing creating index on join columns
Implementing conditional logic inside the queries itself
Writing multiple sub-queries inside a single query for getting required data
Because of heavy reports, the following things will impact the platform
When we execute a complex query on the database, thread from connection pool will block to execute the query
When threads from connection pool are blocked completely, the application will become very slow for incoming requests
When max request timeout is crossed, API gateway will return timeout error, But still, connection thread on the database is active, Then all these types of idle threads will occupy database resources like memory, CPU which in turns increase the load on the database
Some times when running huge queries, because of time taken by the query will lead to broken pipe issue which causes more memory leaks and out of heap memory type issues. Because of this, the service will frequently restart automatically.
If a query returns huge data, the browser will become unresponsive and application will become unresponsive.
The objective of PDF generation service is to bulk generate pdf as per requirement.
Before you proceed with the documentation, make sure the following pre-requisites are met -
All required data and format file path is added in the environment yml file
pdf-service is up and running
Provide functionality to download and print PDF’s
Provide functionality to download and print bulk PDF’s
Create data config and format config for a PDF according to product requirement.
Add data config and format config files in PDF configuration
Add the file path of data and format config in the environment yml file
Deploy the latest version of pdf-service in a particular environment.
For Configuration details please refer to the Customizing PDF Receipts & Certificates document in Reference Docs
The PDF configuration can be used by any module which needs to show particular information in PDF format that can be printed/downloaded by the user.
Functionality to generate PDFs in bulk
Avoid regeneration
Support QR codes and Images
Functionality to specify a maximum number of records to be written in one PDF
Uploading generated PDF to filestore and return filestore id for easy access
The following are the steps for integrating TL certificate in UI.
In footer.js file which is present in /frontend/web/rainmaker/dev-packages/egov-tradelicence-dev/src/ui-config/screens/specs/tradelicence/applyResource , Create two object (download and print object) in footerReview function.
Example
In tlCertificateDownloadObject give the proper label name and key for the pdf. In the link function get the object whose mapping is required for PDF, in this case, we want a license object. Call the function downloadCertificateForm (details about this function is described in the next step). Add icon details which we want to use in UI to represent that option. The same thing for tlcertificatePrintObject only difference is we have to call generateReceipt function. Again create the same two object with similar content in downloadPrintContainer function.
Mention the function name “downloadCertificateForm“ and “generateReceipt“ in import , because the functions is define in /frontend/web/rainmaker/dev-packages/egov-tradelicence-dev/src/ui-config/screens/specs/utils/index.js and /frontend/web/rainmaker/dev-packages/egov-tradelicence-dev/src/ui-config/screens/specs/utils/receiptPDF.js
In index.js define the function which is responsible for calling the Create API of PDF service to create respective PDF. In that function, you have to mention the tenant ID and proper key value which is the same as the key mentioned in the data and format config. Also mentioned the URL : /pdf-service/v1/_create and action as get and also call the function downloadReceiptFromFilestoreID which is responsible to call filestore service with filestoreid and return the URL for pdf.
Example of function downloadCertificateForm
Example of function generateReceipt
(Note: All the API’s are in the same postman collection therefore the same link is added in each row)
__
Digit system supports multiple languages. To add a new language, it should be configured in MDMS.
Before proceeding with the configuration, following are the pre-requisites -
Knowledge of json and how to write a json is required.
Knowledge of MDMS is required.
User with permissions to edit the git repository where MDMS data is configured.
Users can view the web page of digit application in the language of their choice by selecting it from the available languages.
SMS and Emails of information about the transactions on digit application, can be received in languages based on the selection.
After adding the new language, the MDMS service needs to be restarted to read the newly added data.
A new language is added in StateInfo.json In MDMS, file StateInfo.json, under common-masters folder holds the details of language to be added.
The label’s text is displayed in UI for language selection. The value text is used as key to refer the language.
Language is added as an array element under the array named “languages”. Each language element is a label and value pair. By default English language is added. Other languages can be added as an additional/new language which system will support. System to support multiple ie., more than one language, those languages are added in StateInfo.json as below.
"हिंदी" and "ಕನ್ನಡ",”language3” are more than one languages(Hindi,Kannada,somelangauge) added other than "ENGLISH".
In UI the labels and master values that populates in dropdown or textboxes are added as a key for localization. For eg., when a user logs in, at the top of inbox page, a welcome message in English language shows as “Welcome User name“. The text “Welcome” is English localization for the Key “CS_LANDING_PAGE_WELCOME_TEXT”.
For all the labels or master value keys, localization should be pushed to the database through the endpoints for all the languages added in system.The SMS/Email are also added as keys for which values are pushed in all the languages to the data base.
Localization format for keys
Sample of localization
In Hindi language
In English language
For the languages added in the system if values are not pushed to database then for the labels or master data, key will appear in UI. If values for SMS/Email is missed to pushed the SMS/Email can’t be received.
Any one language from the multiple added language, can be set as default. For example if English, Hindi, Kannada are three languages added in the StateInfo.json and kannada is required to be set as a default language then in StateInfo.json for the text "defaultLanguage" the language key is need to be set as its value.
A workflow process is a series of sequential tasks that are carried out based on user-defined rules or conditions, to execute a business process. It is a collection of data, rules, and tasks that need to be completed to achieve a certain business outcome.
In DIGIT, workflow for a business process is divided into three units out of which two are completely configurable while the remaining is fixed and lays the foundation of the other two.
This is the first unit which defines the actions and its nature which are basically executed during the workflow process by the workflow actors. It plays the foundation and configurable in nature as per the ground needs.
This is the second unit which defines the number of steps a workflow process may have and then trigger the creation role for each and every step with appropriate rights to perform a set of actions at each step. It is completely configurable.
This is the third unit which defines the workflow process including the steps, roles with actions and the present, next and previous state of a step/level of the workflow process. It is completely configurable.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The Decision Support System in DIGIT platform can be configured to provide customized insights and statistics on the dashboard. This section offers information on how to configure the DSS parameters for maximized efficiency.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The common configuration details required for all modules are available in this section. Refer to the list of standard documents required for processing applications across modules, learn which documents are mapped to which services, find the standard checklist for filling master data templates, and get the answers to common configuration FAQs.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
This section provides a step by step guide to setting up workflows and configuring the workflows for DIGIT entities.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
This section contains docs that walk you through the various steps required to configure DIGIT services.
All content on this page by is licensed under a .
Always define the Yaml for your APIs as the first thing using Open API 3 Standard ()
APIs path should be standardised as follows:
/{service}/{entity}/{version}/_create: This endpoint should be used to create the entity
/{service}/{entity}/{version}/_update: This endpoint should be used to edit an entity which is already existing
/{service}/{entity}/{version}/_search: This endpoint should be used to provide search on the entity based on certain criteria
/{service}/{entity}/{version}/_count: This endpoint should be provided to give a count of entities that match a given search criteria
Always use POST for each of the endpoints
Take most search parameters in the POST body only
If query params for search need to be supported then make sure to have the same parameters in POST body also and POST body should take priority over query params
Provide additional Details objects for _create and _update APIs so that the custom requirements can use these fields
Each API should have a object in request body at the top level
Each API should have a object in response body at the top level
Mandatory fields should be minimum for the APIs.
minLength and maxLength should be defined for each attribute
Read-only fields should be called out
Use common models already available in the platform in your APIs. Ex -
(Citizen or Employee or Owner)
(Response sent in case of errors)
TODO: Add all the models here
For receiving files in an API, don’t use binary file data. Instead, accept the file store ids
If there is only one file to be uploaded and no persistence is needed, and no additional json data is to be posted, you can consider using direct file upload instead of using filestore id
APIs developed on digit follow certain conventions and principles. The aim of this document is to provide some do’s and don’ts while following these principles.
Persister Service persists data in the database in a sync manner providing very low latency. The queries which have to be used to insert/update data in the database are written in yaml file. The values which have to be inserted are extracted from the json using jsonPaths defined in the same yaml configuration. Below is a sample configuration which inserts data in a couple of tables.
The above configuration is used to insert data published on the kafka topic save-pgr-request in the tables eg_pgr_service_v2 and eg_pgr_address_v2. Similarly, the configuration can be written to update data. Following is a sample configuration:
The above configuration is used to update the data in tables. Similarly, the upsert operation can be done using ON CONFLICT() function in psql. Following table describe each field in the configuration.
Workflow is defined as a sequence of tasks that has to be performed on an application/Entity to process it. The egov-workflow-v2 is a workflow engine which helps in performing these operations seamlessly using a predefined configuration. We will discuss how to create this configuration for a new product in this document.
Before you proceed with the configuration, make sure the following pre-requisites are met -
egov-workflow-v2 service is up and running
Role-Action mapping are added for business Service API’s
Create and modify workflow configuration according to the product requirements
Configure State level as well BusinessService level SLA to efficiently track the progress of the application
Control access to perform actions through configuration
Deploy the latest version of egov-workflow-v2 service
Add businessService persister yaml path in persister configuration
Add Role-Action mapping for BusinessService API’s
Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)
The Workflow configuration has 3 levels of hierarchy: a. BusinessService b. State c. Action The top-level object is BusinessService, it contains fields describing the workflow and list of States that are part of the workflow. The businessService can be defined at tenant level like pb.amritsar or at the state level like pb. All objects maintain an audit sub-object which keeps track of who is creating and updating and the time of it.
Each State object is a valid status for the application. The State object contains the information of the state and what actions can be performed on it.
The action object is the last object in the hierarchy, it defines the name of the action and the roles that can perform the action.
The workflow should always start from the null state as the service treats new applications as having null as the initial state. eg:
In action object whatever nextState is defined, the application will be sent to that state. It can be to another forward state or even some backward state from where the application has already passed (generally, such actions are named SENDBACK)
SENDBACKTOCITIZEN is a special keyword for action name. This action sends back the application to the citizen’s inbox for him to take action. A new State should be created on which Citizen can take action and should be the nextState of this action. While calling this action from module assignees should be enriched by the module with the uuids of the owners of the application
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
This section walks you through the steps to adding a new language or setting up the default language on the DIGIT system.
All content on this page by is licensed under a .
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.
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.
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.
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.
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.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
Format Config file: This config file define the format of PDF. In format config, we define the UI structure ex: css, layout etc. for pdf as per PDFMake syntax of pdf. In PDF UI, the places where values are to be picked from the request body are written as “” as per ‘mustache.js’ standard and are replaced by this templating engine. ex:
Data Config file: This file contains a mapping to pick data from request body, external service call body if there is any and the variable which defines where this value is to be replaced in format by the templating engines (mustache.js). The variable which is declared in the format config file must be defined in the data config file. ex:
If the format field is not specified in date variable declaration then in PDF date is shown with the default format of DD/MM/YYYY. For more details refer this page
The position of page number in the footer is configurable. For more detail refer this document
All content on this page by is licensed under a .
To add a new report first add the file path in the reportFileLocationsv1[ (In this file, the path of the report configuration files get stored).
Once file path is added in the file reportFileLocationsv1, go to the folder /configs/reports/config [ Create a new file and name the file what you have given in file reportFileLocationsv1.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
For integration-related steps please refer to the document .
All content on this page by is licensed under a .
Title
Link
Workflow Service Documentation
Link
_create
_update
_search
Attribute
Description
key
The key for the pdf, it is used as a path parameter in URL to identify for which PDF has to generate.
baseKeyPath
The json path for the array object that we need to process.
entityIdPath
The json path for the unique field which is stored in DB. And that unique **field value is mapped to file-store id, so we can directly search the pdf which was created earlier with the unique field value and there will be no need to create PDF again.
Direct Mapping
In direct mapping, we define the variable whose value can be fetched from the array object which we extracted using baseKeyPath.
ExternalApi Mapping
The externalApi mapping is used only if there is a need for values from other service response. In externalApi mapping, API endpoint has to be set properly with the correct query parameter.
Derived mapping
In derived mapping, the estimation of variable characterized here is equivalent to the esteem acquired from the arithmetic operation between the direct mapping variable and externalApi mapping variable.
Qr code Config mapping
This mapping is used to draw QR codes in the PDFs. The text to be shown after scan can be a combination of static text and variables from direct and externalApi mappings.
Attribute
Description
key
The key for the pdf, it is used as a path parameter in URL to identify the PDF that has to be generated.
Content
In this section, the view of pdf is set. What has to appear on pdf is declared here, it is just like creating a static HTML page. The variable which is defined in data config is declared here and place in position as per the requirement. We can also create a table here and set the variable as per requirement.
Style
This section is used to style the component, set the alignment and many more. Basically, it's like a CSS to style the HTML page.
Title
Link
PDF Generation service technical documentation
Steps for Integration of PDF in UI for download and print PDF
API Swagger Documentation
Link
pdf-service/v1/_create
pdf-service/v1/_createnosave
pdf-service/v1/_search
Variable Name
Description
serviceName
The module name to which the configuration belongs
version
Version of the config
description
Detailed description of the operations performed by the config
fromTopic
Kafka topic from which data has to be persisted in DB
isTransaction
Flag to enable/disable perform operations in Transaction fashion
query
Prepared Statements to insert/update data in DB
basePath
JsonPath of the object that has to be inserted/updated.
jsonPath
JsonPath of the fields that has to be inserted in table columns
type
Type of field
dbType
DB Type of the column in which field is to be inserted
Title
Link
PDF Generation service technical documentation
Customizing PDF Receipts & Certificates
API Swagger Documentation
Link
pdf-service/v1/_create
pdf-service/v1/_createnosave
pdf-service/v1/_search
Attribute Name
Description
tenantId
The tenantId (ULB code) for which the workflow configuration is defined
businessService
The name of the workflow
business
The name of the module which uses this workflow configuration
businessServiceSla
The overall SLA to process the application (in milliseconds)
state
Name of the state
applicationStatus
Status of the application when in the given state
docUploadRequired
Boolean flag representing if document are required to enter the state
isStartState
Boolean flag representing if the state can be used as starting state in workflow
isTerminateState
Boolean flag representing if the state is the leaf node or end state in the workflow configuration. (No Actions can be taken on states with this flag as true)
isStateUpdatable
Boolean flag representing whether data can be updated in the application when taking action on the state
currentState
The current state on which action can be performed
nextState
The resultant state after action is performed
roles
A list containing the roles which can perform the actions
auditDetails
Contains fields to audit edits on the data. (createdTime, createdBy,lastModifiedTIme,lastModifiedby)
Title
Link
Workflow Service Documentation
Setting Up Workflows
Link
_create
_update
_search
Title
Link
StateInfo.json
Details coming soon..
Title
Link
Sample report.yml file
Sample report.config file
Title
Link
report config folder
The main reason to Setup Base Product Localization is because Digit system supports multiple languages. By setting-up Localization, we can have multiple language support to the UI. So, that user can easily understand the Digit Operations
Before you proceed with the configuration, make sure the following pre-requisites are met -
Before Starting the Localization setup one should have knowledge on React and eGov FrameWork.
Before setting-up Localization, make sure that all the Keys are pushed to the Create API and also get prepared with the Values that need to be added to the Localization key specific to particular languages that are being added in the product.
Make sure where to add the Localization in the Code.
Once the Localization is done, the user can view the Digit Screens in their own language to complete the whole application process easier as digit gives the user to select the language of their choice.
Once The key is added to the code as per requirement, Deployment can be done in the same way, how the code is being deployed.
Select a label which is needed to be localized from the Product code. Here is the example code for a header before setting-up Localization.
As we see the above which supports only the English language, To setup Localization to that header we need to the code in the following manner.
we can see below code is added when we compare with code before Localization setup.
{
labelName: "Trade Unit ",
labelKey: "TL_NEW_TRADE_DETAILS_TRADE_UNIT_HEADER"
},
Here the Values to the Key can be added by two methods either by using the localization Screen which is Developed Recently or by updating the values to the keys to create API using the postman application.
Title
Link
Adding New Language to Digit System. You can refer the link provided for how languages are added in DIGIT
Notification service can notify the user through SMS and email for there action on DIGIT as an acknowledgement that their action has been successfully completed.
ex: actions like property create, TL create, etc.
To send SMS we need the help of 2 services, one on which the user is taking action and the second SMS service.
To send an email we need the help of 2 services, one on which the user is taking action and second email service.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Prior Knowledge of Spring boot.
Prior Knowledge of Kafka.
Prior Knowledge of localization service.
For a specific action of the user, he/she will get a SMS and email as an acknowledgment.
Users can get SMS and email based on the localization language.
If you want to take action for a specific action on that action the service has to listen to a particular topic so that each time any record comes to the topic consumer will know that action has been taken and can trigger a notification for it.
ex: if you want to trigger a notification for Property create then the property service’s NotificationConsumer class should listen to topic egov.pt.assessment.create.topic so that each time any record comes to the topic egov.pt.assessment.create.topic NotificationConsumer will know that Property creates action that has been taken and can trigger a notification for it.
when any record comes into the topic first the service will fetch all the required data like user name, property id, mobile number, tenant id, etc from the record which we fetched from the topic.
Then we will fetch the message contain from localization and the service replaces the placeholders with the actual data.
Then put the record in SMS topic in which SMS service is listening.
email service is also listening to the same topic which SMS service is listening.
Title
Link
NotificationConsumer
Through SMS and Emails necessary information/updates are communicated to the users on their various transactions on DIGIT applications. For example, when a Trade License application is initiated or forwarded or approved or payment is done in DIGIT system, the applicant and payer (if the payer is other than the applicant) will be informed about the status of Trade License application through SMS/Email. The language for SMS and Email can be set as per requirement/choice.
Before proceeding with the configuration, make sure the following pre-requisites are met -
Knowledge of DIGIT applications is required.
User should be aware of transactional steps in the DIGIT application.
User can receive Emails and SMS of necessary information/updates in the decided language.
The language can be decided by the end-users (either Citizen or Employee). End-users can select the language before logging in or after logging, from inbox page.
If the language is not chosen by end-user, then SMS/Email is received in the language of, State requirement based state-level configured language.
Sms and Email localization should be pushed to the database through the endpoints for all the languages added in the system. Localization format for SMS/Email
Sample of SMS localisation for Trade License application initiation English localization
Hindi localization
The placeholder <1>,<2>,<3> will the replaced by the actual required value which gives important information to the applicant. For example, the message will be received by the applicant as: Dear Kamal, Your Trade License application number for Ramjhula Provisional Store has been generated. Your application no. is UK-TL-2020-07-10-002058 You can use this application number….
The default language for SMS and Email can be set by
Clicking on the preferred language from the available language button, in language selection page, which opens before the login page.
In Citizen or Employee inbox page, the language can be selected from the drop-down, which can be seen in the right corner of the inbox title bar.
If the language is not chosen by Citizen or Employee, then SMS/Email is received in default configured language. For example in a State if Hindi, English, Kannada are added as three languages in the system and out of these three languages if State decides that Kannada should be configured as default language then Kannada is set as the default language in MDMS. So when end-user does not choose any language then SMS/Email is sent in Kannada language.
The selected language key is sent as a parameter along with other required transaction parameters to the back end code.
In the back end, to send SMS/Email logic, language key is checked and based on the language key and SMS unique key, the message is fetched from the database.
Roles define the permissions of a user to perform a group of tasks. For example for a Trade License application initiate, forward, approve or payment are tasks which require permission. User assigned with role Citizen or Counter Employee can perform initiation and payment. TL Document Verifier can forward the application and the only user assigned with the role named TLApprover can approve the application.
Before proceeding with the configuration, make sure the following pre-requisites are met -
Knowledge of DIGIT applications is required.
User should be aware of transactional steps in the DIGIT application.
Knowledge of json and how to write a json is required.
Knowledge of MDMS is required.
User with permissions to edit the git repository where MDMS data is configured.
With Roles, permission to perform a certain task can be restricted based on the requirement. For example, only user with Role TLApprover can approve the Trade License initiated application.
While creating an employee in the system from HRMS Admin, the roles can be assigned to the employees based on the requirement. The roles added in mdms will show for “roles drop down” in employee create screen.
In digit system workflow for a module can be implemented based on roles. For example for Trade License module a Trade License application workflows as per the role is like: CounterEmployee/Citizen>TLDocVerifier>TLApprover>CounterEmployee/Citizen Trade License application workflow based on roles:
S.No.
Role
Workflow in Trade License
1
CounterEmployee
Initiates the TL application for Citizen from counter. Initiated TL application goes to TLDocVerifier inbox.
2
Citizen
Initiates the TL application. Initiated TL application goes to TLDocVerifier inbox.
3
TLDocVerifier
User with role TLDocVerifier can forward or reject the TL application after verifying the initiated application. The rejected application shows for re-submission in initiator inbox. The forwarded application goes to TLApprover inbox.
4
TLApprover
TLApprover can approve or reject based on the requirement. The rejected application goes back to TLDocVerifer for re-verification. The approved application shows for payment pending in initiator inbox.
5
CounterEmployee
Once the initiated application is approved by the user with role TLApprover, CounterEmployee can do the payment and download the receipt.
6
Citizen
Once the initiated application is approved by the user with role TLApprover, Citizen can do the payment and download the receipt.
After adding the new role, the MDMS service needs to be restarted to read the newly added data.
Roles are added in roles.json In MDMS, file roles.json, under ACCESSCONTROL-ROLES folder roles are added. Sample roles:
A role is added as an array element under the array named “roles”.
Each role is defined with three key-value pairs. keys are “code”, ”name” and “description”.
Sr. No.
key
Data Type
Data Size
Is Mandatory?
Definition/ Description
1
code
Alphanumeric
64
Yes
A unique code that identifies the user role name.
2
name
Text
256
Yes
The Name indicates the User Role while creating an employee a role can be assigned to an individual employee.
3
description
Text
256
No
A short narration provided to the user role name.
Localization needs to be pushed for all the roles added in roles.json
Sample Localization for roles In English:
In Hindi:
code "code": "ACCESSCONTROL_ROLES_ROLES_TL_CEMP", is the localization key for role. The key has three parts: a) ACCESSCONTROL_ROLES : It is folder and module name of MDMS, file roles.json in which roles are added. Hypen (- ) in name "ACCESSCONTROL-ROLES" is replaced with underscore ( _ ). b) ROLES : It is the role.json file name and array name under which roles as array elements are added. c)TL_CEMP : It is the unique role code.
If localization is not pushed for the roles then the key will appear in UI.
Title
Link
Sample roles.json
Reference link
To use the generic GET/POST SMS gateway, first, configure the service application properties
sms.provider.class=Generic
This will set the generic interface to be used. This is the default implementation, which can work with most of the SMS Provider. The generic implementation supports below
GET or POST based API
Supports query params, form data, JSON Body
To configure the URL of the SMS provider use sms.provider.url property.
To configure the http method used configure the sms.provider.requestType property to either GET or POST.
To configure form data or json api set sms.provider.contentType=application/x-www-form-urlencoded or sms.provider.contentType=application/json respectively
To configure which data needs to be sent to the API below property can be configured:
sms.config.map={'uname':'$username', 'pwd': '$password', 'sid':'$senderid', 'mobileno':'$mobileno', 'content':'$message', 'smsservicetype':'unicodemsg', 'myParam': '$extraParam' , 'messageType': '$mtype'}
sms.category.map={'mtype': {'*': 'abc', 'OTP': 'def'}}
sms.extra.config.map={'extraParam': 'abc'}
sms.extra.config.map is not used currently and is only kept for custom implementation which requires data that doesn't need to be directly passed to the REST API call
sms.config.map is a map of parameters and their values
Special variables that are mapped
$username maps to sms.provider.username
$password maps to sms.provider.password
$senderid maps to sms.senderid
$mobileno maps to mobileNumber from kafka fetched message
$message maps to the message from the kafka fetched message
$<name> any variable that is not from above list, is first checked in sms.category.map and then in application.properties and then in environment variable with full upper case and _ replacing -, space or .
So if you use sms.config.map={'u':'$username', 'p':'password'}. Then the API call will be passed <url>?u=<$username>&p=password
Message success delivery can be controlled using below properties
sms.verify.response (default: false)
sms.print.response (default: false)
sms.verify.responseContains
sms.success.codes (default: 200,201,202)
sms.error.codes
If you want to verify some text in the API call response set sms.verify.response=true and sms.verify.responseContains to the text that should be contained in the response
It is possible to whitelist or blacklist phone numbers to which the messages should be sent. This can be controlled using the below properties:
sms.blacklist.numbers
sms.whitelist.numbers
Both of them can be given a , separated list of numbers or number patterns. To use patterns use X for any digit match and * for any number of digits match.
sms.blacklist.numbers=5*,9999999999,88888888XX will blacklist any phone number starting with 5, or the exact number 9999999999 and all numbers starting from 8888888800 to 8888888899
Few 3rd parties require a prefix of 0 or 91 or +91 with the mobile number. In such a case you can use sms.mobile.prefix to automatically add the prefix to the mobile number coming in the message queue.
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
maven v3.2.x
PostgreSQL v9.6
Git 2.8.3
JDK 8 update 112 or higher
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}.
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).
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.
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.
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
Setup your eDCR service workspace by following the instructions provided in https://github.com/egovernments/eGov-dcr-service/blob/master/README.md
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,
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).
Add the property and update the MDMS hostname, mdms.host={HOST_NAME} in application-config-client.properties file or egov-erp-override.properties file
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.
Title
Link
Design and Architecture
API Contracts
Repository the default rule processing code available
Sample client implementation repository
Configuring MDMS
This documentation talks about building a new dashboard in the DSS and also it defines the configurations required for the analytics service. Analytics microservice which is responsible for building, fetching, aggregating, and computing the data on ElasticSearch to a consumable data response. Which shall be later used for visualizations and graphical representations.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Prior Knowledge on JSON
Prior Knowledge on Elasticsearch Query Language
Prior Knowledge on Kibana
DSS setup
Adding new Roles for Dashboards
Adding a new Dashboard
Adding new Visualizations in existing Dashboard
Adding new charts for visualizations :
To add a new role, We have to make changes in the RoleDashboardMappingsConf.json (roles node) configuration file has to be modified as below. In the roles array, every JSON object is unique based on the id. The name of the role is defined in the roleName attribute.
If we want to assign any dashboard to a particular role, Add the id and name of the dashboard in the dashboards array. This dashboard id is unique and it’s referred to as the MasterDashboardConfig.json file configuration.
Any number of roles & dashboards can be added
Below is a sample to add a new role object
2. Adding a new Dashboard
To add a new dashboard, We have to make changes in the MasterDashboardConfig.json (dashboards node) that has to be modified as below.
Add the new JSON object in the dashboards array. Add the dashboard name in the name attribute, Id should be unique, which is used for assigning a role for the dashboard. We will talk about visualizations below.
Dashboards array add a new dashboard as given below
To add new visualizations, We have to make changes again in the MasterDashboardConfig.json (vizArray node) that has to be modified as below. Add the visualization name to the name attribute. We will add all the visualizations in the vizArray array.vizArray will contain the name of the visualization, vizType as visual type, noUnit, and charts.
charts array contains chart API configuration query details. The id is referred to as the chartapiconfig.json file’s key to fetch the required data from elastic search’s index. And the name attribute is referred to as the name of the chart in localization.
To add a new chart, chartApiConf.json has to be modified as shown below. A new chartid (key of the JSON) has to be added with the chart node object. In the chartid JSON contains the chart name, chart type, valueType, documentType, aggregationPaths and queries attribute.
Types of the chart: Metric, Pie, Line, Table, and xtable
AggregationPaths: Query result will take from this path.
valueType: Based on the value type result will be shown in the UI. Different types of valueType are Amount, percentage, and number.
queries array will contain the information of the module, requestQueryMap (request param of the API), dateRefField (Based on this field date data will be filtered), indexName, and aggrQuery. We can add multiple modules queries in a single chart.
For more information please refer the reference documents listed below.
Title
Link
DSS Backend Configuration Manual
DSS Dashboard - Technical Document for UI
DSS Technical Documentation
Roles define the permissions of a user to perform a group of tasks. The tasks are created as API calls to do certain actions when a request for those calls is sent by the system. Access permission is grated by mapping roles with API. User assigned with the roles to provide access for the API
Before proceeding with the configuration, make sure the following pre-requisites are met -
Knowledge of DIGIT applications is required.
User should be aware of transactional steps in the DIGIT application.
Knowledge of json and how to write a json is required.
Knowledge of MDMS is required.
Knowledge on how to create a new API.
APIs developed on digit follow certain conventions and principles. The aim of this document is to provide some do’s and don’ts while following those principles
APIs path should be standardised as follows:
/{service}/{entity}/{version}/_create: This endpoint should be used to create the entity
/{service}/{entity}/{version}/_update: This endpoint should be used to edit an entity which is already existing
/{service}/{entity}/{version}/_search: This endpoint should be used to provide search on the entity based on certain criteria
/{service}/{entity}/{version}/_count: This endpoint should be provided to give a count of entities that match a given search criteria
Always use POST for each of the endpoints
Take most search parameters in POST body only
For further more information about how new API is developed could be referred in this link API Do's and Don'ts
Adding New APIs(actions) and Mapping Roles with that APIs provides permission to perform certain task can be restricted based on the requirement.
After mapping Roles with APIs, the MDMS service needs to be restarted to read the newly added data.
APIs are added in actions-test.json and called as action. In MDMS, file actions-test.json, under ACCESSCONTROL-ACTIONS-TEST folder APIs are added.
API Sample -
APIs are added as action array element with the request url and other required details for the array "actions-test"
Each action is defined as a key-value pair:
Sr. No.
key
Data Type
Is Mandatory?
Definition/ Description
1
id
Numeric
Yes
A unique id that identifies action.
2
name
Text
No
A short narration provided to the action.
3
url
Text
Yes
It is the endpoint of API or type like url or card.
4
displayName
Text
No
It is the display name.
5
orderNumber
Numeric
Yes
A number to represent order to display in UI
6
parentModule
Text
No
Code of the service referred to as parent
7
enabled
boolean
Yes
To enable or disable display in UI.
8
serviceCode
Text
No
Code of the service to which API belongs.
9
code
Text
No
10
path
Text
No
11
navigationUrl
Text
Yes
Url to navigate in UI
12
leftIcon
Icon
No
13
rightIcon
Icon
No
Roles are added in roles.json In MDMS, file roles.json, under ACCESSCONTROL-ROLES folder roles are added. More about roles can be checked in the below link: Adding roles to System
Mapping of Roles and APIs/action is added in roleactions.json, under the folder ACCESSCONTROL-ROLEACTIONS. Sample mapping:
Role and API/action mapping is added as an array element under array roleactions. Each mapping is defined with key-value pairs. keys are rolecode, actionid, actioncode and tenantId.
Sr. No.
key
Is Mandatory?
Definition/ Description
Sr. No.
key
Is Mandatory?
Definition/ Description
1
rolecode
Yes
The unique code of the role which is defined in roles.json and which required mapping for API.
2
actionid
Yes
The unique id of the API/action which is defined in actions-test.json and which is required to be mapped with the role.
3
actioncode
No
The code of the API/action which is defined in actions-test.json and which is required to be mapped with the role.
4
tenantid
Yes
tenant id of state.
Title
Link
Sample actions-test.json
Sample roles.json
Sample roleactions.json Roles APIs mapping
Roles define the permissions of a user to perform a group of tasks. The tasks are created as API calls to do certain actions when a request for those calls is sent by the system. For example, the key tasks for a Trade License application include initiate/apply, forward, approve or payment. For Trade License initiate two API calls, “create” and “update” is required. Create API creates and save the application in the database and return an application number. Update API saves the required attached documents in the file store and return the success acknowledgement message of the application created. These create and update API access permission is granted to the roles named Citizen and TL counter employee. Access permission is grated by mapping roles with API. User assigned with the roles Citizen or TL counter employee can initiate/apply the Trade License application.
Before proceeding with the configuration, make sure the following pre-requisites are met -
Knowledge of DIGIT applications is required.
User should be aware of transactional steps in the DIGIT application.
Knowledge of json and how to write a json is required.
Knowledge of MDMS is required.
User with permissions to edit the git repository where MDMS data is configured.
Mapping Roles with APIs, permission to perform a certain task can be restricted based on the requirement. For example, only the user with Role TL Counter Employee or Citizen can initiate the Trade License applications.
After mapping Roles with APIs, the MDMS service needs to be restarted to read the newly added data.
APIs are added in actions-test.json and called as action. In MDMS, file actions-test.json, under ACCESSCONTROL-ACTIONS-TEST folder APIs are added. API Sample:
APIs are added as action array element with the request url and other required details for the array "actions-test"
Each action is defined as a key-value pair:
Sr. No.
key
Data Type
Is Mandatory?
Definition/ Description
1
id
Numeric
Yes
A unique id that identifies an action.
2
name
Text
No
A short narration provided to the action.
3
url
Text
Yes
It is the request URL of API call.
4
displayName
Text
No
It is the display name.
5
enabled
boolean
Yes
To enable or disable display in UI.
6
servicecode
Text
No
Code of the service to which API belongs.
Roles are added in roles.json In MDMS, file roles.json, under ACCESSCONTROL-ROLES folder roles are added. More about roles can be checked in the below link: Adding roles to System
Mapping of Roles and APIs/action is added in roleactions.json, under the folder ACCESSCONTROL-ROLEACTIONS. Sample mapping:
Role and API/action mapping is added as an array element under array roleactions. Each mapping is defined with key-value pairs. keys are rolecode, actionid, actioncode and tenantId.
Sr. No.
key
Is Mandatory?
Definition/ Description
1
rolecode
Yes
The unique code of the role which is defined in roles.json and which required mapping for API.
2
actionid
Yes
The unique id of the API/action which is defined in actions-test.json and which is required to be mapped with the role.
3
actioncode
No
The code of the API/action which is defined in actions-test.json and which is required to be mapped with the role.
4
tenantid
Yes
tenant id of state.
Title
Link
Sample actions-test.json
Sample roles.json
Sample roleactions.json Roles APIs mapping
Indexer uses a config file per module to store all the configurations pertaining to that module. Indexer reads multiple such files at start-up to support indexing for all the configured modules. In config we define source and, destination elastic search index name, custom mappings for data transformation and mappings for data enrichment. Below is the sample configuration for indexing TL application creation data into elastic search.
Variable Name
Description
serviceName
Name of the module to which this configuration belongs.
summary
Summary of the module.
version
Version of the configuration.
mappings
List of definitions within the module. Every definition corresponds to one index requirement. Which means, every object received onto the kafka queue can be used to create multiple indexes, each of these indexes will need configuration, all such configurations belonging to one topic forms one entry in the mappings list. The keys listed henceforth together form one definition and multiple such definitions are part of this mappings key.
topic
The topic on which the data is to be received to activate this particular configuration.
configKey
Key to identify to what type of job is this config for. values: INDEX, REINDEX, LEGACYINDEX. INDEX: LiveIndex, REINDEX: Reindex, LEGACYINDEX: LegacyIndex.
indexes
Key to configure multiple index configurations for the data received on a particular topic. Multiple indexes based on a different requirement can be created using the same object.
name
Index name on the elastic search. (Index will be created if it doesn't exist with this name.)
type
Document type within that index to which the index json has to go. (Elasticsearch uses the structure of index/type/docId to locate any file within index/type with id = docId)
id
Takes comma-separated JsonPaths. The JSONPath is applied on the record received on the queue, the values hence obtained are appended and used as ID for the record.
isBulk
Boolean key to identify whether the JSON received on the Queue is from a Bulk API. In simple words, whether the JSON contains a list at the top level.
jsonPath
Key to be used in case of indexing a part of the input JSON and in case of indexing a custom json where the values for custom json are to be fetched from this part of the input.
timeStampField
JSONPath of the field in the input which can be used to obtain the timestamp of the input.
fieldsToBeMasked
A list of JSONPaths of the fields of the input to be masked in the index.
customJsonMapping
Key to be used while building an entirely different object using the input JSON on the queue
indexMapping
A skeleton/mapping of the JSON that is to be indexed. Note that, this JSON must always contain a key called "Data" at the top-level and the custom mapping begins within this key. This is only a convention to smoothen dashboarding on Kibana when data from multiple indexes have to be fetched for a single dashboard.
fieldMapping
Contains a list of configurations. Each configuration contains keys to identify the field of the input JSON that has to be mapped to the fields of the index json which is mentioned in the key 'indexMapping' in the config.
inJsonPath
JSONPath of the field from the input.
outJsonPath
JSONPath of the field of the index json.
externalUriMapping
Contains a list of configurations. Each configuration contains keys to identify the field of the input JSON that is to be enriched using APIs from the external services. The configuration for those APIs also is a part of this.
path
URI of the API to be used. (it should be POST/_search API.)
queryParam
Configuration of the query params to be used for the API call. It is a comma-separated key-value pair, where the key is the parameter name as per the API contract and value is the JSONPath of the field to be equated against this parameter.
apiRequest
Request Body of the API. (Since we only use _search APIs, it should be only RequestInfo.)
uriResponseMapping
Contains a list of configuration. Each configuration contains two keys: One is a JSONPath to identify the field from response, Second is also a JSONPath to map the response field to a field of the index json mentioned in the key 'indexMapping'.
mdmsMapping
Contains a list of configurations. Each configuration contains keys to identify the field of the input JSON that is to be denormalized using APIs from the MDMS service. The configuration for those MDMS APIs also is a part of this.
path
URI of the API to be used. (it should be POST/_search API.)
moduleName
Module Name from MDMS.
masterName
Master Name from MDMS.
tenantId
Tenant id to be used.
filter
Filter to be applied to the data to be fetched.
filterMapping
Maps the field of input json to variables in the filter
variable
Variable in the filter
valueJsonpath
JSONPath of the input to be mapped to the variable.
In this document, we are coming to learn how to upload apk to play store and available to the end user to download and use from play store.
Before starting the process of upload the apk to play store the following requirements are a must.
Make sure that signed apk (signed apk has key generated, which is used to release different versions of the apk ) is generated for the application that you want to upload to play store.
Make sure that you have account for google play console by agreeing to terms and conditions, also payment shd have been done for the account and is ready for uploading an apk to play store.
two screenshots of your app and they must be at least 320 pixels wide and be in a PNG or JPEG format.
You must also add your high resolution app icon. It must be 512 by 512 pixels and it must be in 32-bit PNG format. This icon will be visible on the Google Play app’s page and in search results.
Next, a Feature Graphic image, which will be visible at the top of the Google Play app’s page. This image must be 1024 by 500 pixels, and maybe in JPEG or 24-bit PNG format.
Also, prepare a small description about app in four to five lines.
The use of deploying the apk to the play store is to enable the user to download the apk from the play store and use whenever needed. By uploading the apk to play store our app will be available to all end-users around the world just on the fingertips.
Now, we are going to learn step by step procedure of uploading apk to play store.
Open google play console by entering the url (https://play.google.com/apps/publish/) and log in with the user credentials.
After login in the following screen can be seen.
Now on the top-right click on create Application button and you get a popup to enter the title of the apk. Refer the screenshot below and click on create.
Under product details section, enter the description that we have prepared in the beginning.
Under the assets section, we need to attach at-least two screenshots of the application, high-resolution thumbnail icon and Feature Graphic image.
Under Categorization, select the application type, category
Coming to the contact section, add website URL, email and also phone number if you wish to add one.
After next comes the privacy policy section where you can enter the link of the privacy and policy page and save it as a draft.
After saving as a draft on the “right side menu” select the option “App Release”. In the app release page under the “production Track” click on the manage, then click on create a release in the next screen. Then in the next page under the “ App signing by google play” click the continue.
In the next page, under android app bundles and APK to add section add your APK generated also enter the release name and add the description inside the <en-US> tag related to that APK and save the entered data.
After that click on the “calculate Rating” then in the click “apply Rating Button”.
Next will be the “Pricing and Distribution” in the “Right side Menu”. In this page we have the option to select the cost of APK to download or free, also select the countries app needs to be available and also answer the questionnaires that are asked and click on the save Drafts.
Finally, again go the “App Release” in the right side menu and click on the “ Edit Release” button in the Production Track section and save the details and at the end click “Start role out to production” and click confirm.
The following screen acknowledges your process is ended.
That is all about uploading APK to the play store. You can check the status of the application on the right side menu under the “ All Application”. It takes some hours to appear in the play store. Wait for the APK to appear in the play store. We can also check the details of the APK in the Dashboard.
This document describes the steps to be followed to set up a new instance of Finance. When a new state or city 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 configuration changes etc are a few of the key activities.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring and Hibernate
Prior knowledge of Maven
Prior knowledge of Git.
Maven v3.2.x
PostgreSQL v9.6
Git 2.8.3
JDK 8 update 112 or higher
Create subdomains under the main domain for each of the cities that are to be set up
Create a schema per city in the database
The Co-existence repository is the base repository for the finance product and the client-specific data needs to be defined in the Client implementation repository
Fork and create a client implementation repository from Client implementation repository to keep client-specific data and configurations.
Any configurations and data specific to the client should be added in the client repository.
The default application configurations of the finance service are present in the application configuration file. To enable or disable any feature, either update the values in the application configuration file or the override configuration file.
The override configuration is the template and the values for the template are present either in the finance service values yaml file or in the environment named yaml file. The finance service values yaml is the common file to override the default values and the changes made to this file are applicable for all environments (dev, qa, uat, prod etc).
Any specific configuration change is required for any specific environment then update the environment named yaml file.
Sample environment named yaml files for your reference
Add or update the db url in the environment specific file using the below property
Update the db username and password, which are configured in the environment named secrets yaml file.
For example, for the qa environment, update the qa-secrets.yaml
Finance co-existence service uses schema-based multi-tenancy, this means there will be one schema present for a city. The following are the configuration changes to set up this kind of database.
Enable multi-tenancy by enabling the following property
Each ULB is enabled by adding a schema name and domain name. 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)
The default tenants are configured in the finance service yaml file using the below configuration.
To override and have separate tenants for a specific environment then update the environment-specific file like below.
Here citya.egovernments.org, cityb.egovernments.org are the domains and citya, cityb are the schemas/tenants.
Example environment specific configuration file for your reference.
Update the domainurl in the eg_city table.
Domain URL value should be the same as configured tenant domain_name Ex:
The default database migration configurations are present in the application configuration file.
Override the default values by updating the properties either in the finance service values yaml file or the environment-specific yaml file. The following are different properties.
Configure the following property either in the finance service values yaml file or the environment-specific yaml file.
Add one user in the system for system integration - SIFINANCE mapped with role SYS_INTEGRATOR_FINANCE by using the user service createnovalidate API.
Find the createnovalidate API details below
To enable or disable an event to push the bills and vouchers to the elastic search indexer the below need to be configured either in the finance service values yaml file or the environment-specific yaml file.
Configure the following property either in the finance service values yaml file or the environment-specific yaml file.
Configure the following property either in the finance service values yaml file or the environment-specific yaml file.
Finance service reads data from multiple other DIGIT services. The following are the different services finance system reads data from. Update the domain URL of the respective service based on the service where it is running.
The following master data is present in the MDMS repository.
Department
Designation
BusinessServiceMapping
TaxHeadMasterGlCodeMapping
InstrumentGLcodeMapping
AccountCodeTemplate
FinanceInstrumentStatusMapping
tenants
OnlineGLCodeMapping
Define all the departments in the Departments json
Define all the designations in the Designations json
Configure finance tenants in the Citymodule json to enable finance module in the ULB.
Define business services mapping in the Business Service Mapping json to integrate different business services like Property Tax, Trade License and FireNOC etc with Finance and to post vouchers like demand and receipt vouchers. Enabling and disabling voucher posting for any service can be configured here.
Define the Tax head and instrument glcode mappings in the Account Head Mapping json. This file contains each tax head wise glcode mapping and each instrument wise glcode mappings.
Different instrument statuses can be defined in the Instrument Status Mapping json file.
Different types of contractor bill templates are defined in the AccountCode Template file. These templates will be used in the contractor bill creation screen to auto-populate the account codes.
Service-wise glcode mapping for the online instrument type for the particular city is defined in the Online Instrument Type json.
Define the business service wise bank account mappings in the BankAccount Service Mapping json file. These details to be configured city wise as the bank details are specific to a city.
MDMS serach url is configured in the Application Configuration file.
Setup Finance service workspace by following the instructions provided in README.
After set up is done, make the changes to the host file in the local machine, by mapping the domain URLs with a local IP address and save the changes. Restart your local machine to make the host mapping effective.
Title
Link
API Contracts
Co-existence finance code available
Sample client implementation repository
Configuring MDMS
Adding new service and CI/CD
A decision support system (DSS) is a composite tool that collects, organizes, and analyzes business data to facilitate quality decision-making for management, operations, and planning. A well-designed DSS aids decision-makers in compiling a variety of data from many sources: raw data, documents, personal knowledge from employees, management, executives, and business models. DSS analysis helps organizations to identify and solve problems, and make decisions
This document explains the steps on how to define the configurations & set up for the new dashboard in the DSS.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Prior Knowledge of Spring boot
Prior Knowledge of Kafka
Prior Knowledge of Elastic Search
Prior Knowledge of Kibana
Prior Knowledge of EQL (Elastic Query Language)
Prior Knowledge of JSON
Creating a DSS dashboard schema
DSS ingest service APIs
Ingest service configurations
Creating Kafka sync connector to push the data to Elastic search
When we are going to start indexing the DSS collection v2 index. We should create the schema in the ES using the Kibana query as there in the below file.
2. DSS ingest service API
Micro Service which runs as a pipeline and manages to validate, transform and enrich the incoming data and pushes the same to ElasticSearch Index. Ingest service will fetch the data from the index(
paymentsindex-v1) which is specified in the indexing service API as below. The ingest service will read the configuration files which are there with v1. All the configuration files will be there here.
3. Ingest service configurations
Transform collection schema for V2
This transform collection v1 configuration file is used to map with the incoming data. This mapped data will go inside the data object in the DSS collection v2 index.
Click here for an example configuration
Here: $i, the variable value that gets incremented for the number of records of paymentDetails.
$j, the variable value that gets incremented for the number of records of billDetails.
Enrichment Domain Configuration
This configuration defines and directs the Enrichment Process which the data goes through.
For example, if the Data which is incoming is belonging to a Collection Module data, then the Collection Domain Config is picked. And based on the Business Type specified in the data, the right config is picked.
In order to enhance the data of Collection, the domain index specified in the configuration is queried with the right arguments and the response data is obtained, transformed and set.
Click here for an example configuration
Topic Context Configuration
Topic Context Configuration is an outline to define which data is received on which Kafka Topic.
Indexer Service and many other services are sending out data on different Kafka Topics. If the Ingest Service is asked to receive those data and pass it through the pipeline, the context and the version of the data being received has to be set. This configuration is used to identify as in which Kafka topic consumed the data and what is the mapping for that.
Click here for an example configuration
JOLT Domain Transformation Schema
JOLT is a JSON to JSON Transformation Library. In order to change the structure of the data and transform it in a generic way, JOLT has been used.
While the transformation schemas are written for each Data Context, the data is transformed against the schema to obtain transformed data.
Click here for an example configuration
Validator Schema
Validator Schema is a configuration Schema Library from Everit Bypassing the data against this schema, it ensures whether the data abides by the rules and requirements of the schema which has been defined.
Click here for an example configuration
Enhance Domain configuration
This configuration defines and directs the Enrichment Process which the data goes through.
For example, if the Data which is incoming is belonging to a Collection Module data, then the Collection Domain Config is picked. And based on the Business Type specified in the data, the right config is picked and the final data is placed inside the domain object.
In order to enhance the data of Collection, the domain index specified in the configuration is queried with the right arguments and the response data is obtained, transformed and set.
Click here for an example configuration
For Kafka connect to work, Ingest pipeline application properties or in environments direct push must be disabled.
es.push.direct=false
If DSS collection index data is indexing directly ( without Kafka connector) to ES through the ingest pipeline then, make the application properties or in environments, direct push must be enabled.
es.push.direct=true
4. Creating a Kafka sync connector to push the data to the Elasticsearch
Configure the Kafka topics in the environments or Ingest pipeline application properties as shown below.
To Start the indexing we will create a connecter that will take data from the topic and push it to the index we have mentioned in the "transforms.TopicNameRouter.replacement" and mention the ES host in the Kafka connection we have to mention the host URL in “connection.url”.
To create the Kafka connector run the below curl command inside the playground pod:
Title
Link
DSS Backend Configuration Manual
DSS Dashboard - Technical Document for UI
DSS Technical Documentation
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.
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.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Branch out and create a eDCR service 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.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
vizArray is to hold multiple visualizations
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.
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.
After clicking the create you will be redirected to the page where we need to enter the product details, graphics assets, Categorization ..etc.
Now in the right side menu to the “content rating” and click on continue button which will redirect to “Welcome to the Content Rating Rating Questionnaire page”, where we need to enter the email id and also select your app category in provided categories and fill all the Questionnaire in the form that comes after selecting the app category and click on the “save Questionnaire”, you will receive an email after clicking on the “save Questionnaire”.
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.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.