1 of 100

Configure DIGIT

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.

Git Repos

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.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Setting up DIGIT

Learn all about setting up DIGIT and its various components.

Configuring InfraOps
Setting Up DIGIT Environment
Email And SMS Setup
FileStore Setup
Setting Up SSL Certificate
Perioding Log Cleanup

Details for these pages coming up soon...

Configuring InfraOps

Details coming soon...

Setting up DIGIT Environment

Details coming soon...

Email And SMS Setup

Details coming soon...

FileStore Setup

Details coming soon...

Setting Up SSL Certificate

Details coming soon...

Periodic Log Cleanup

Details coming soon...

Setting up Master Data

Learn how to setup DIGIT master data.

MDMS Overview
Configuring Master Data
Adding New Master
Configuring Tenants
State Level vs City Level Master

MDMS Overview

Overview

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.

Pre-requisites

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.

Key Functionalities

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.

Deployment Details

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.

Configuration Details

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

{
  "tenantId": "uk",
  "moduleName": "BillingService",
  "{$MasterName}":[ ]
}

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”

{
  "tenantId": "pb",
  "moduleName": "BillingService",
 "BusinessService": 
 [
    {
      "businessService": "PropertyTax",
      "code": "PT",
      "collectionModesNotAllowed": [ "DD" ],
      "partPaymentAllowed": true,
      "isAdvanceAllowed": true,
      "isVoucherCreationEnabled": true
    }
]
}

Reference Docs

Doc Links

Title

Link

Reference Doc Link 1

MDMS-Service

Reference Doc Link 2

MDMS-Rewritten

API List

Link

API Contract Reference

Configuring Tenants

Overview

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.

Pre-requisites

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.

Key Functionalities

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.

Deployment Details

After adding the new tenant, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

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.

{
  "tenantId": "uk",  //<ReplaceWithDesiredTenantId>
  "moduleName": "tenant",
  "tenants": [ {
      "code": "uk.citya", //<state.ulbname>
      "name": "City A",  //<name of the ulb>
      "description": "City A", //<ulb description>
      "logoId": "https://s3.ap-south-1.amazonaws.com/uk-egov-assets/uk.citya/logo.png",  //<ulb logo path - To display ulb logo on login>
      "imageId": null,
      "domainUrl": "", //<ulb website url>
      "type": "CITY",
      "twitterUrl": null,
      "facebookUrl": null,
      "emailId": "complaints.citya@gmail.com",  //<ulb email id>
      "OfficeTimings": {
        "Mon - Sat": "10.00 AM - 5.00 PM"
      },
"city": {
"name": "City A",
"localName": null,
"districtCode": "CITYA",
"districtName": null,
"regionName": null,
"ulbGrade": "Municipal Corporation",
"longitude": 78.0322,
"latitude": 30.3165,
"shapeFileLocation": null,
"captcha": null,
"code": "248430"
},
"address": "City A Municipal Cornoration Address",
"contactNumber": "91 (135) 2653572"
}]}

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, (Municipal corporation (Nagar Nigam), 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.

Naming Convention for Tenants Code

“Code”:“uk.citya” is StateTenantId.ULBTenantName"

"logoId": "https://s3.ap-south-1.amazonaws.com/uk-egov-assets/uk.citya/logo.png", 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”.

Localization should be pushed for ULB grade and ULB name. The format is given below.

Localization for ULB Grade

{
     "code": "ULBGRADE_MUNICIPAL_CORPORATION",
     "message": "MUNICIPAL CORPORATION",
     "module": "rainmaker-common",
     "locale": "en_IN"
  }

Localization for ULB Name

{
     "code": "TENANT_TENANTS_UK_HALDWANI",    
     "message": "Haldwani",
     "module": "rainmaker-tl",
     "locale": "en_IN"
}

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.

Reference Docs

Doc Links

Title

Link

tenant json file

content

Configuring Master Data

Overview

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.

Pre-requisites

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.

Key Functionalities

These data can be used to validate the incoming data.

Deployment Details

After adding the new module data, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

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.

{
  "<module1>":{
    "<master1>":{},
    "<master2>":{},
    ...
  },
  "<module2>":{
    <master3>:{},
    <master4>:{},
    ...
  },
  ...
}

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

Reference Docs

Doc Links

Title

Link

Sample Master config file

Sample Module folder

Adding New Master

Overview

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.

Pre-requisites

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.

Deployment Details

After adding the new master, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

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.

{
  "tenantId": "< TENANT ID >",
  "moduleName": "< MODULE NAME >",
  "< MASTER NAME >": []
}

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.

{
  "<module1>":{
    "<master1>":{},
    "<master2>":{},
    ...
  },
  "<module2>":{
    <master3>:{},
    <master4>:{},
    ...
  },
  ...
}

Each master contain the following data and keys are self-explanatory

"master":{
    "masterName": "<>",
    "isStateLevel": true,
    "uniqueKeys": []
}

Reference Docs

Doc Links

Title

Link

Sample Master file

Sample Master configuration

State Level Vs City Level Master

Overview

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.

Pre-requisites

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.

Key Functionalities

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.

Deployment Details

For deploying the changes(adding new data, updating existing data or deletion) in MDMS, the MDMS service needs to be restarted.

Configuration Details

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.

Reference Docs

Doc Links

API List

Master Data Collection Templates

Objective

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.

Audience

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

Output Artefacts

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 is licensed under a .

Environment Setup

DIGIT environment setup is conducted at two levels.

State Level Setup

Key configurations at the state level include -

Tenants Information
SMS Account Configuration
Email Account Configuration
Google Play Store Account
Payment Gateway Configuration
POS Configuration
Domain Name Configuration
SSL Configuration
ULB Departments
ULB Designations
Localization
Google Map Configuration

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Tenants Information

Introduction

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 Table

S. No.

ULB Name*

ULB Code*

ULB Grade*

City Name*

City Local Name

District Name*

District Code*

Region Name

Region Code

Sonepur Nagar Panchayat

Corp

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

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

ULB Name

Text

256

Yes

Name of ULB. E.g. Kannur Municipal Corporation/ Saptarishi Municipal Council

ULB Code

Alphanumeric

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

ULB Grade

Alphanumeric

Yes

Grade of ULB. e.g. Corporation, Municipality, Nagar Panchayat etc

City Name

Text

256

Yes

Name of city/ town which is covered by the ULB. E.g. Kannur/ Saptarishi

City Local Name

Text

256

Name of the city in the local language. e.g Telugu, Hindi etc

District Name

Text

256

Yes

Name of the District where the city is situated

District Code

Alphanumeric

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

Region Name

Text

256

Name of the region the listed district belongs to

Region Code

Alphanumeric

Unique code of the region to uniquely identify it

Contact Number

Alphanumeric

Yes

Contact person phone no. of ULB

Address

Text

256

Yes

Postal address of the ULB for the correspondence

ULB Website

Alphanumeric

256

Yes

URL address of the website for the ULB

Email Address

Alphanumeric

Email of the address of ULB where the email from the citizen can be received

Latitude

Alphanumeric

Latitude part of coordinates of the centroid of the city

Longitude

Alphanumeric

Longitude part of coordinates of the centroid of the city

GIS Location Link

Text

GIS Location link of the ULB

Call Center No

Alphanumeric

Call centre contact number of ULB

Facebook Link

Text

Face book page link of ULB

Twitter Link

Text

Twitter page link of the ULB

Logo file Path

Document

Yes

URL of logo file path to download the logo of ULB

Steps to fill 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.

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

To see common checklist refer to the page Checklist consisting of all the activities which are to be followed to ensure completeness and quality of data.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There are no checklist activities exists which are specific to the entity.

Attachments

SMS Account Configuration

Introduction

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.

Data Table

We have the below-mentioned parameters which we use for configuration:

Sr. No.

Parameter

Value

sms.provider.url

www.xyz.com

sms.username.parameter

mnsbihar@001

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.

Procedure

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.

Data Definition

Below mentioned are the descriptions of the parameters which are needed for configuration:

Sr. No.

Column Name

Data Type

Data Size

Mandatory

Description

Parameter

Alphanumeric

Yes

The parameter required to be configured

Value

Alphanumeric

Yes

The corresponding value of the parameter

Parameter names could differ from vendor to vendor.

Steps to fill Data

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.

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Sr. No.

Checklist Parameter

Example

Make sure that the vendor should support multiple language functionality and especially the local language of the state.

Attachments

Email Account Configuration

Introduction

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.

Data Table

In order to achieve the above functionality, we require the below-mentioned details

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

Bihar

POP3

SMTP

****

192.172.82.12

Auto

The values mentioned here are sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Email ID

Alphanumeric

N/A

Yes

Email id which is being configured

Your Name

Text

256

Yes

The name on behalf of which the email would be sent in order to receive the updates

Account Type

Alphanumeric

Yes

The type of email account type protocol which will be used to download messages

Incoming Mail Server

Numeric

(12,2)

Yes

The IP address of the email server through which messages would be received

Outgoing Mail Server(SMTP)

Numeric

(12,2)

Yes

The IP address of the email server through which messages would be sent

Password

Alphanumeric

Yes

The password of the email server

Incoming Server POP3 Port

Numeric

(12,2)

Yes

The port number through which the emails are received

Outgoing server SMTP Port

Numeric

(12,2)

Yes

The port number through which the emails are to be sent

Encrypted Connection Type

Alphanumeric

Yes

The encryption type which is used for the connection

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)

Steps to fill 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.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

Not Applicable

Attachments

Google Play Store Account

Introduction

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.

Data Table

In order to start the configuration for the google play store following would be required:

Sr. No

Email Id

Password

*******

Data given in the table is sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Mandatory

Description

Email Id

Alphanumeric

Yes

Gmail account id through which the app would be published on the google play store

Password

Alphanumeric

Yes

Password for the Gmail account

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.
Ask the state team/client to create an email account on Gmail.
Ask the client to log in to the google play console here 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.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Sr. No.

Checklist Parameter

Example

Make sure that the email account is created on Gmail since the play store works on Google accounts only

Email Id and Password is required in order to login to the google play store for configuration

Attachments

Payment Gateway Configuration

Introduction

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.

Data Table

Following are the details required from the payment gateway vendor in order to configure the payment gateway:

Sr. No

Integration Kit

API Documentation

Redirect Working Key

Merchant Id

Test credential of Debit Card/ Net banking

File Name

XYZ#123

UDDUK

File Name

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Integration Kit

Document

Yes

This is a document that is sent by the vendor which contains information on how to integrate the service

API Documentation

Document

Yes

This is a separate document which is sent by the vendor in order to help ideally helps us to retrieve the transaction status

Redirect Working Key

Alphanumeric

Yes

The working key is provided by the vendor for the generation of the redirection URL

Merchant Id

Alphanumeric

Yes

Merchant id provided by the vendor

Test credential of Debit Card/ Net Banking

Document

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.

Steps to fill 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.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Sr. No.

Checklist Parameter

Example

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)

Do get the details for both the environments separately i.e UAT and Production

Attachments

POS Integration Configuration

Introduction

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.

Data Table

Not applicable.

Procedure

Not applicable.

Checklist

Not applicable.

Attachments

Not applicable.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Domain Name Configuration

Introduction

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.

Data Table

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.

Procedure

Since all state governments/clients prefer to host the websites on their servers, this activity is ideally done by them.

Data Definition

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

Yes

It is the IP address that has to be mapped to the domain name

Steps to fill data

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.

Checklist

This checklist covers all the activities which are common across the entities.

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of.

Entity Specific Checklist

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

Only one domain name and its corresponding IP address have to be provided

Attachments

SSL Configuration

Introduction

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.

Data Table

Not Applicable

Procedure

Not Applicable

Data Definition

Not Applicable

Steps to fill data

Not Applicable

Checklist

Not Applicable

Attachments

Not Applicable

ULB Designations

Introduction

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.

Data Table

Sr. No.

Designation Code*

Designation Name* (In English )

Designation Name* (In Local Language)

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Steps to fill data

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.

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.

Attachments

Localization

Introduction

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.

Data Table

Sr. No.

Code*

Module*

Message (In English)*

Message (In Local Language)*

Data mentioned in the data table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

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

Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Google Map Configuration

Introduction

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

"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

Data Table

Sr. No

Google API URL*

API Key*

Note:

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

The data provided is sample data

Steps to fill the 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.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

ULB Level Setup

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 is licensed under a .

Cross Hierarchy Mapping

Introduction

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

Data Table

Below is the data table for the Boundary:

Hierarchy Type

Hierarchy Type 1*

Hierarchy Type 2*

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

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

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist activity applicable here.

Attachments

ULB Bank Accounts

Introduction

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.

Data Table

Below given data table represents the excel template attached. Data given in the table is a sample data.

Sr. No.

Code*

ULB Name*

Bank Name*

Branch Name*

Account Number*

Account Type*

IFSC*

Data given in the table is sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory

Definition/ Description

Steps to fill 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.

Checklist

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Setting Up SMS Gateway

XState-Chatbot Integration Document

Overview

XState-Chatbot is a revamped version of the chatbot, which provides functionality to the user to access PGR module services like file complaint, track complaint, notifications from whats app, It allows the user to view receipts and pay the bills for Property, Trade Licence, FireNOC, Water and Sewerage and BPA service module.

Key Functionalities

File PGR complaint
Track PGR complaint
Support images when filing complaints
Notifications to citizen when an employee performs any action on the complaint
Allow user to search and pay bills of different modules.
Allow user to search and view receipts of different modules.
Allow user to change the language of their choice to have a better experience.
Put user interactions on an elastic search for Telemetry.

Integration

Integration Scope

XState chatbot can be integrated with any other module to improve the ease of search and view bills/past payment receipts and to improve speed and convenience for bill payment. It can be integrated with the PGR module for easiness of creation and tracking of the complaint.

Integration Benefits

Increase in convenience and ease of making the bill payment.
Increase in no. of users opting for online payment.
Improvement in demand collection efficiency
Creating an additional channel for payment.
Remove dependency on mobile/web app or counter.

Integration Details

Integration of New Whatsapp Provider

Whatsapp provider is a third-party service that works in the middle of a user's WhatsApp client and XState-Chatbot server. All messages coming/going to/from user pass through WhatsApp provider. Chatbot calls WhatsApp provider to send messages to the user. When a user responds with any WhatsApp message the WhatsApp provider calls Chatbot service’s configured endpoint with details ex:- user sent message, sender’s number etc.

If any new WhatsApp provider is to be used with a chatbot, code must be written to convert the provider’s incoming messages to the format that the chatbot understands and also final output from the chatbot should be converted to WhatsApp provider’s API request format.

Currently, the XState-Chatbot service is using ValueFirst as the WhatsApp Provider. This will require provider-specific environment variable to be configured. If the provider changes then, all these environment variable will also change. Few of those environment variables are stored as secrets, so these values need to be configured in env-secrets.yaml.

As this is a revamped version of the chatbot service, all of the secrets should already be present. There is no need to create new secrets.

Integration of PGR complaint feature in XState-Chatbot

The integration of PGR with a chatbot can be enabled and disabled by making changes in this file. By exporting the respective PGR service file, the PGR service feature can be sable and vice versa.

Configuration of PGR version in chatbot

To configure the PGR module to use in Xstate-chatbot - the below variable values need to change in the environment file as per the requirement.

pgrVersion
pgrUpdateTopic

To configure PGR v2 in XState chatbot then pgrVersion should be ‘v2' and pgrUpdateTopic should be 'update-pgr-request’.

Configuration of city and locality search with nlp-search engine

To enable the fuzzy search for city and locality selection in PGR complaint flow The variable nlp-geoSearch has to be set true in the environment file. To use the nlp-search engine with xstate chatbot, make sure that stable build is deployed and all the mdms data are present for that particular environment. To know more about the nlp-search engine service please refer to the Reference document section.

Adding Information Image in PGR complaint creation and Open search information image

To configure the filestoreid for informational image follow the steps mention below

Download the images from the section Information Images for PGR and Open Search
Upload the image into filestore server. Use the upload file API from this postman collection(https://www.getpostman.com/collections/bdb059c5af698f0d81d6)
For PGR information image mention the filestore id here in environment file .
For Open search information image mention the filestore id here in environment file .

For example:

a) if supportedLocales: process.env.SUPPORTED_LOCALES || 'en_IN,hi_IN'

then valuefirst-notification-resolved-templateid: "12345,6789"

b) if supportedLocales: process.env.SUPPORTED_LOCALES || 'hi_IN,en_IN'

then valuefirst-notification-resolved-templateid: "6789,12345"

(Note: Both the list should not be empty, it must contain at least one element)

Configuration of push notification template messages with button

Template messages with button are maintained in the same way as describe in previous section (Configuration of push notification template messages)

There are two type of button message

Quick Reply
Call To Action

More details can be found in the value first document.

Integration of Bill Payment and Receipt Search feature in Xstate-Chatbot:

The integration of the Bill payment and receipt search feature with the chatbot can be enabled and disable by making changes in this file. By exporting the respective bill service and receipt service file, the payment and receipt search feature can be enabled and vice versa.

Configuration of module for Bill payment and Receipt search

To configure the list of modules to appear as an option for payment and receipt, Add the module business service code in the list present in the environment file.

For example: If bill-supported-modules: "WS, PT, TL" then Water and Sewerage, Property, Trade license module would appear for bill payment and receipt search.

Also add the message bundle, validation and service code for locality searcher in egov-bill and egov-receipt file.

Environment Variables

Description

WHATSAPP_BUSINESS_NUMBER

The mobile number to be used on server

VALUEFIRST_USERNAME

Username for configured number for sending messages to user through whatsapp provider API calls

VALUEFIRST_PASSWORD

Password for configured number for sending messages to user through whatsapp provider API calls

GOOGLE_MAPS_API_KEY

Maps API key to access geocoding feature

ROOT_TENANTID

Contains state level tenantid value

SUPPORTED_LOCALES

This variable contains the list supported language in chatbot. If there is a need to add new language in chatbot, then its respective locale need to add in this list.

PGR_VERSION

Contains PGR version value to use (i.e v1 or v2)

PGR_UPDATE_TOPIC

Depends on PGR version respective PGR update kafka topic name should mention here. Example: If PGR_VERSION: 'v2' then PGR_UPDATE_TOPIC: 'update-pgr-request'

BILL_SEARCH_LIMIT

Limit for showing maximum number of bills on search.

RECEIPT_SEARCH_LIMIT

Limit for showing maximum number of receipts on search.

COMPLAINT_SEARCH_LIMIT

Limit for showing maximum number of complaints on search.

BILL_SUPPORTED_MODULES

Contains the list of modules to be use for bill payment and receipts search.

INFORMATION_IMAGE_FILESTORE_ID

Contains the filestoreid of informational image, which shows how to share the user current location.

OPEN_SEARCH_IMAGE_FILESTORE_ID

Contains the filestoreid of open search informational image, which shows how to use open search pay feature for bill payment

USER_SERVICE_HARDCODED_PASSWORD

This variable contain fixed value of login password and otp. This value has to configured in env-secrets.yaml.

GEO_SEARCH

Boolean flag to enable and disable city / locality nlp search

Configuration of Telemetry File

Add this telemetry file in config repo and mention the filename in respective environment yaml file.

Searcher config file:

Cron job mdms entry:

Localisation for PGR service

Information Images for PGR and Open Search

Reference Docs

Doc Links

Title

Link

Chatbot Message Localisation

nlp-search engine

API List

Title

Link

/xstate-chatbot/message

/xstate-chatbot/reminder

/xstate-chatbot/status

Dashboard Analytics - Backend

DSS Backend Configuration Manual

Overview

DSS has two sides to it. One is the process in which the Data is pooled to ElasticSearch and the other being the way it is fetched, aggregated, computed, transformed and sent across. As this revolves around a variety of Data Set, there is a need for making this configurable. So that, tomorrow, given a new scenario is introduced, then it is just a configuration away from getting the newly introduced scenario involved in this flow of the process.

This document explains the steps on how to define the configurations for both sides of DSS. Analytics and Ingest Pipeline Services.

Abbreviations

Ingest: Micro Service which runs as a pipeline and manages to validate, transform and enrich the incoming data and pushes the same to ElasticSearch Index

Analytics: Micro Service 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.

JOLT: JSON to JSON transformation library written in Java where the "specification" for the transform is itself a JSON document

Modules / Domain Level: These are the Services in this context. Each of the services, such as Property Tax, Trade License, Water and Sewerages are considered as Modules / Domains

Chart: Each individual graphical representation is considered as a Chart in specific. For example, a Metric of Total Collection is considered as a Chart.

Visualization: Group of different Charts is considered as a Visualization. For example, the group of Total Collection, Target Collection and Target Achieved is considered as a Metric Collection of Charts and thus it becomes a Visualization.

Ingest Pipeline Configurations

Below is the list of configurations -

Topic Context Configurations
Validator Schema
JOLT Transformation Schema
Enrichment Domain Configuration
JOLT Domain Transformation Schema

Descriptions

Topic Context Configurations

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 which kafka topic consumed the data and what is the mapping for that.

Click here for Full Configuration

Parameter Name

Description

topic

Holds the name of the Kafka Topic on which the data is being received

dataContext

Context Name which needs to be set for further actions in the pipeline

dataContextVersion

Version of the Data Structure is set here as there might be different structured data at a different point in time

Validator Schema

Validator Schema is a configuration Schema Library from EveritBy passing 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

JOLT 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 a transformed data.

Follow the slide deck for JOLT Transformations

Click here for an example configuration

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

Paremter Name

Description

Unique Identifier for the Configuration within the configuration document

businessType

This defines as in which kind of Domain / Service is the data related to. Based on this business type, query and enhancements are decided

indexName

Based on Business Type, Index Name is defined as to which index has to be queried to get the enhancements done from

query

Query to execute to get the Domain Level Object is defined here.

targetReferences

sourceReference

Fields which are variables in order to get the domain level objects are defined here. The variables and where all the values has to be picked from are documented here

JOLT Domain Transformation Schema

As a part of Enhancement, once the domain level object is obtained, we might not need the complete document as is in the end data product.

Only those parameters which should be or can be used for aggregation and representation are to be held and others are to be discarded.

In order to do that, we make use of JOLT again and write schemas to keep the required ones and discard the unwanted ones.

The above configuration is used to transform the data response in the enrichment layer.

Click here for an example configuration

Use case:- JOLT Transformation Schema for collection V2

JOLT transformation schema for payment-v1 has taken as a use case to explain the context collection and context version v2. The payment records are processed/transformed with the schema. The schema supports splitting the billing records into an independent new record. So if there are 2 bill items in the collection/payment incoming data then this results in 2 collection records in turn.

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.

Note: For kafka connect to work, Ingest pipeline application properties or in environments direct push must be disabled.

es.push.direct=false

Analytics Configurations

Below is the list of configurations

Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration

Description

Chart API Configuration

Each Visualization has its own properties. Each Visualization comes from different data sources (Sometimes it is a combination of different data sources)

In order to configure each visualization and its properties, we have Chart API Configuration Document.

In this, Visualization Code, which happens to be the key, will be having its properties configured as a part of the configuration and are easily changeable.

Click here for an example configuration

Parameter Name

Description

Key (e.g: totalApplication)

This is the Visualization Code. This key will be referred to in further visualization configurations. This is the key that will be used by the client application to indicate which visualization is needed for display.

chartName

The name of the Chart has to be used as a label on the Dashboard. The name of the Chart will be a detailed name. In this configuration, the Name of the Chart will be the code of Localization which will be used by Client Side

queries

Some visualizations are derived from a specific data source. While some others are derived from different data sources and are combined together to get a meaningful representation. The queries of aggregation which are to be used to fetch out the right data in the right aggregated format are configured here.

queries.module

The module / domain level, on which the query should be applied on. Property Tax is PT, Trade License is TL. If the query is applied across all modules, the module has to be defined as COMMON

queries.indexName

The name of the index upon which the query has to be executed is configured here.

queries.aggrQuery

The aggregation query in itself is added here. Based on the Module and the Index name specified, this query is attached to the filter part of the complete search request and then executed against that index

queries.requestQueryMap

Client Request would carry certain fields which are to be filtered. The parameters specified in the Client Request are different from the parameters in each of these indexed documents. In order to map the parameters of the request to the parameters of the ElasticSearch Document, this mapping is maintained

queries.dateRefField

Each of these modules has separate indexes. And all of them have their own date fields.

When there is a date filter applied against these visualizations, each of them has to apply it against their own date reference fields. In order to maintain what is the date field in which index, we have this configured in this configuration parameter

chartType

As there are different types of visualizations, this field defines as what is the type of chart / visualization that this data should be used to represent.

Chart types available are:

metric - this represents the aggregated amount/value for records filter by the aggregate es query

pie - this represents the aggregated data on grouping. This is can be used to represent any line graph, bar graph, pie chart or donuts

line - this graph/chart is data representation on date histograms or date groupings

perform - this chart represents groping data as performance-wise.

table - represents a form of plots and value with headers as grouped on and list of its key, values pairs.

xtable - represents an advanced feature of the table, it has additional capabilities for dynamic adding header values.

valueType

In any case of data, the values which are sent to plot might be a percentage, sometimes an amount and sometimes it is just a count. In order to represent them and differentiate the numbers from the amount from percentage, this field is used to indicate the type of value that this Visualization will be sending.

action

Some of the visualizations are not just aggregating on data source. There might be some cases where we have to do a post aggregation computation. For Example, in the case of Top 3 Performing ULBs, the Target and Total Collection is obtained and then the percentage is calculated.

In these kinds of cases, what is the action that has to be performed on that data obtained, is defined in this parameter.

documentType

The type of document upon which the query has to be executed is defined here.

drillChart

If there is a drill down on the visualization, then the code of the Drill Down Visualization is added here.

This will be used by Client Service to manage drill-downs

aggregationPaths

All the queries will be having Aggregation names in it. In order to fetch the value out of each Aggregation Responses, the name of the aggregation in the query will be an easy bet. These aggregation paths will have the names of Aggregation in it.

_comment

In order to display information on the “i” symbol of each visualization, Visualization Information is maintained in this field.

Master Dashboard Configuration

Master Dashboard Configuration is the main configuration that defines which Dashboards that are to be painted on the screen.

It includes all the Visualizations, their groups, the charts which comes within them and even their dimensions as what should be their height and width.

Click here for an example configuration

Parameter Name

Description

name

Name of the Dashboard which has to be displayed as Page Heading

Unique Identifier of the Dashboard which should be used later for Querying each of these Visualizations

isActive

Active Indicator which can be used to quickly disable a dashboard if required.

style

Style of the Dashboard. Whether it should be a linear one or a tabbed one. This information is maintained in this parameter.

visualizations

The list of visualizations that are to be displayed in the Dashboard is listed out here.

visualizations.row

The row identifier for each Visualization are mentioned here

The name of an individual visualization is added here

visualizations.vizArray

The list of Charts within the Visualization is specified in this list.

Group of Charts is given an ID to have a placement on the Dashboard. This unique identifier is maintained in this field.

Group of Charts is given a name that can be displayed on the group on Dashboard in that row.

visualizations.vizArray.dimensions

Each of these group of charts is given a dimension based on which they are placed in a specific row in a dashboard

visualizations.vizArray.vizType

As there are multiple charts grouped into one visualization, the type of Visualization needs to be specified in order to indicate to the client application what goes inside each of these visualizations and charts inside them

vizType used for any other dashboards:- metric-collection, chart, performing-metric

metric-collection:- Used to specify the type as single or group of metric chart type

2. performing-metric:- Used perform chart type

3. chart:- Used chart type for pie, donut, table, bar, horizontal bar, line

vizType used for the Home page:- collection, module

collection: used in UI style as full width

2. module: used in UI style for specific width.

visualizations.vizArray.noUnit

visualizations.vizArray.isCollapsible

visualizations.vizArray.ref

The value types of these charts are different. Some are numbers, some are amounts, some are percentage.

In the case of amounts, there is a requirement to display in Lakhs, Crores and Units. In order to indicate the client application whether to display these units or not, we have this boolean to control that

The value type is for card/visualisation collapsible as boolean values.

This object contains url (as mandatory), logoUrl (optional), type(optional).

visualizations.vizArray.charts

The list of individual charts inside a Visualization Group is maintained in this array list

Individual Chart Number Identifier to indicate the uniqueness of Charts

Name of the Chart which can be a header label for Charts within a Visualization

visualizations.vizArray.charts.code

Code of the Chart is the indicator that has to be sent to Server Side to get the data for representing the Visualization.

visualizations.vizArray.charts.chartType

Type of Chart which has to represent the data result set that is obtained is specified here

chartType:- bar, horizontalBar, line, donut, pie, metric, table

visualizations.vizArray.charts.filters

Filters that can be applied to the Visualization and what are the fields which are filterable are mentioned here.

visualizations.vizArray.charts.headers

In some cases, there are headers which can be a title or additional information for the Chart Data which gets represented. This field is kept open to accommodate the information which can be sent along with the Chart Data in itself.

Role Dashboard Mappings Configuration

Master Dashboard Configuration which was explained earlier hold the list of Dashboards that are available. Given the instance where Role Action Mapping is not maintained in the Application Service, this configuration will act as Role - Dashboard Mapping Configuration

In this, each Role is mapped against the Dashboard which they are authorized to see

This was used earlier when the Role Action Mapping of eGov was not integrated. Later, when the Role Action Mapping started controlling the Dashboards to be seen on the client-side, this configuration is just used to enable the Dashboards for viewing.

Click here for an example configuration

Parameter Name

Description

roles

List of Roles that are available in the system

roles._comment

Role Description and comment on why does this role has an entry in this configuration and sums up the summary as to what are the things that are to be enabled.

roles.roleId

Unique Identifier of the Role for which Access is being given

roles.roleName

Name of the Role for which the access is being given

roles.isSuper

Boolean flag which defines whether the Role is a Super User or not

roles.orgId

Organization to which the Role belongs to

roles.dashboards

List of Dashboards that are enabled for the Role

Name of the individual Dashboard which has been enabled

Identifier of the individual Dashboard which has been enabled

Adding Configurations

Adding Roles and Dashboards :

To add a new role, RoleDashboardMappingsConf.json (roles node) configuration file has to be modified as below

Note: Any number of roles & dashboards can be added

Below as in Figure 9. is a sample to add a new role object, new dashboard object

To add a new dashboard, MasterDashboardConfig.json (dashboards node) has to be modified as below in Figure 10.

Note: dashboards array add a new dashboard as given below

Adding Visualizations in existing Dashboard

To add new visualisations, again MasterDashboardConfig.json (vizArray node) has to be modified as below as shown in Figure 11.

Note: vizArray is to hold multiple visualizations

Adding charts for visualizations

To add a new chart, chartApiConf.json has to be modified as shown below. A new chartid has to be added with the chart node object.

Metric chart Sample as shown in Figure 12.

Pie chart Sample as shown in Figure 13.

Line chart Sample as shown in Figure 14.

****

Table chart Sample: This chart comes in 2 kind - table and xtable.

table (as shown in Figure 15.) type allows to added aggregated fields added as available in the query keys, hence to extract the values based on the key, aggegationPaths needs to add along with their data type as in pathDataTypeMapping.

xtable(as shown in Figure 16.) type allows to add multiple computed fields with the aggregated fields dynamically added.

To add multiple computed columns, computedFields [] where actionName (IComputedField<T> interface), fields [] names as in existing in query key, newField as name to appear for computation must be defined.

https://github.com/egovernments/configs/blob/master/egov-dss-dashboards/dashboard-analytics/ChartApiConfig.json for the full configuration in detail.

Steps to create charts and visualise are:

Create/Add a chart in chartApiConf.json
Add a visualization for the existing dashboard in MasterDashboardConfig.json as defined above.
Or in order to create/add a new dashboard create the dashboard in MasterDashboardConfig.json and create a role in RoleDashboardConfig.json

Configuration Changes for DrillThrough :

Example Drill through in Ward table in Property Dashboard.

wardDrillDown is the visualization code for PT Drill Down. kind is the attribute that shows the type of visualization code. Apart from two things all the attributes are common.

Example Drill through in ComplaintList table in PGR Dashboard.

complaintDrillDown is the visualization code for PGR Drill Down.

The above complaintDrillDown visualization code called in the drill chart parameter.