Overview

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 identify and solve problems, and make decisions.

API Details

The Swagger API for the backend is below

https://github.com/egovernments/business-services/blob/master/Docs/dss-dashboard/DSS%20Analytics%20Dashboard%20YAML%20Spec%201.0.0.yaml

Swagger API for ingest

https://github.com/egovernments/business-services/blob/master/Docs/dss-dashboard/DSS%20Ingest%20YAML%20Spec%201.0.0.yaml

The target upload file template is given below -

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

Overview

DSS has two sides to it. One is the process in which the data is pooled to ElasticSearch and the other is the way it is fetched, aggregated, computed, transformed and sent across. DSS must be configurable since the entire process involves playing around with a variety of data sets. This ensures easy configuration of data sets in new scenarios.

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

Commonly Used Terms

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.

Configuration Details

Discussed below are the ingest pipeline configuration details -

1. Topic Context Configurations

2. Validator Schema

3. JOLT Transformation Schema

4. Enrichment Domain Configuration

5. JOLT Domain Transformation Schema

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 receives the data and passes it through the pipeline, the context and the version of the data received have to be set. This configuration is used to identify which Kafka topic consumed the data and the mapping details.

Click here for the full configuration

Validator Schema

Validator schema is a configuration schema library from Everit. By passing the data against this schema, it ensures whether the data abides by the rules and requirements of the schema that 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 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 that 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 specified business type 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

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 been 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 bill details.

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

1. Chart API Configuration

2. Master Dashboard Configuration

3. Role Dashboard Mappings Configuration

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

Master Dashboard Configuration

Master dashboard configuration defines the dashboards that are to be painted on the screen.

It includes all the visualizations, their groups, the charts and even their dimensions in terms of height and width.

Click here for an example configuration

Role Dashboard Mappings Configuration

Role dashboard mapping ensures that each role is mapped against the dashboards that they are authorized to see.

Click here for an example configuration

Adding Configurations

Adding Roles and Dashboards

To add a new role, modify the RoleDashboardMappingsConf.json (roles node) configuration file as given below.

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

To add a new dashboard, modify the MasterDashboardConfig.json (dashboards node) as shown below in Figure 10.

Adding Visualizations

To add new visualisations, modify the MasterDashboardConfig.json (vizArray node) as shown in Figure 11.

Adding Charts

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 is of 2 types - table and xtable.table (as shown in Figure 15.) Type allows the addition of aggregated fields as available in the query keys. To extract the values based on the key, aggegationPaths have to be added along with their data type as in pathDataTypeMapping.

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

To add multiple computed columns, define the following params within computedFields []

• actionName - (IComputedField<T> interface),

• fields - [] names as existing in the query key,

• newField - name to appear for the computation

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 DrillThroughs:

Example - drill through in ward table in the property tax dashboard.

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

Example - Drill through in the ComplaintList table in the PGR Dashboard.

complaintDrillDown is the visualization code for PGR Drill Down.

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

Overview

This release for DSS focuses on improving user experience and the ability given to the user to get deeper insights using drill-through and comparison indicators in tables.

The release includes the following features:

• Breadcrumbs for better navigation

• Drill through options in tables and charts

• Comparison indicators in Table

Breadcrumbs For Navigation

In addition to the left navigation panel, the addition of breadcrumbs is also useful to provide a better sense of the current page insight. It is also very much helpful for mobile navigation. The user can navigate using the breadcrumbs by clicking on the required parent menu.

Technical Implementation Details

It Works based on the Current Route URL and previous Route URL

File Details -

Drill through options in tables and charts

The ability provided in DSS to configure the drill through for required options in tables as well as charts. The drill through options is useful in configuring the required hierarchy of data set. This helps users to go up to 'N' levels to get deeper insights

Technical Implementation Details:

Drill down/drill through in tables, is based on the drillDownChartId and filter.

Here chart id is used for the subsequent call to fetch the next table along with the applied/selected filters.

Drill throughs in piecharts:

It is similar to the drill-down in tables. Here drill through in piecharts are based on the drillDownChartId field in the parent piechart.

Comparison Indicators in Tables

Providing better insights about the metric performances of different dimensions, a comparison indicator is required inside data tables comparing usually with a different time range (last year/last month) and what is percentage change with time.

Technical Implementation Details:

Comparison with the previous year's data in every table data uses the same request object by changing the time range to the previous year/month/week.

The following method along with parameters is used to fetch the previous year's data.

After receiving last year's data it is compared with the current year's data. The comparison is shown as insight data. The comparison logic is present in uiTable.js -

TimeFilter

The current time component is not very intuitive and user-friendly. So a new library react-date range is used to enhance the time filter.

Event Duration Graphs

Ability to generate graphs showcasing time spent between multiple events like average turnaround time, complaint assigning time, etc.

A DSS_EVENT_DURATION_GRAPH is added in the PGR config

API Call Role Action Mapping

Overview

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 identify and solve problems, and make decisions.

Code Git Repos:

Type Of Users

1. State-Level Admin

2. Commissioner

3. Domain-Level Employee

Dashboard List

There are three types of dashboards -

1. Home page (refer figure 1)

2. Overview page (refer figure 2)

3. Module level dashboard (refer figure 3)

1. Home page

The home page contains multiple cards, each card is clickable.

There are two types of cards, i.e, the overview card and the module-level card.

The overview and the module level cards are differentiated by vizType,

1. Overview card: Clicking on the overview card navigates to the overview page. vizType for overview is a collection.

2. Module Level card: Clicking on the module level card navigates to the module level dashboard. vizType is a module (i.e Property Tax, Trade License etc).

Request Payload for dashboardConfig

auth-token: authenticate the request and it fetches from a local storage key called “Employee.token”

DashboardConfig API Response

roleName: the type of user.

Visualisations: The key contains all configurations for displaying the visualisation like rows with charts etc please refer to figure 1.3.

In Figure 1.3, vizType key will define the module UI like

Collection chart & module chart refer figure 1

2. Overview Dashboard

3. Module Level Dashboard

Visualisation List

In dashboardConfig response, the visualisation key contains all rows & charts details (refer figure 1.3). Each row contains the visual details like name, vizType, noUnit, isCollapsible, charts etc (refer figure 1.3).

1. name - name of visualisation

2. vizType - type of visualisation like COLLECTION, MODULE, METRIC-COLLECTION, PERFORMING-METRIC, CHART

   • COLLECTION - The home page, contains the collection data (refer figure 1).

   • MODULE - The home page, contains the module-level data (refer figure 1).

   • METRIC-COLLECTION - In Overview/Module Level Page, contains the collection data (refer figure 2.1).

   • PERFORMING-METRIC -In Overview/Module Level Page, contains the top/bottom performing data (refer figure 2.2).

   • CHART - In Overview/Module Level Page, contains the below visualisations (refer figure 2.3 to figure 2.7).

     • PIE CHART (refer figure 2.3)

     • LINE CHART (refer figure 2.4)

     • BAR CHART (refer figure 2.5)

     • HORIZONTAL BAR CHART (refer figure 2.6)

     • TABLE CHART (refer figure 2.7)

Visualisations

ULB Dashboard

1. Each ULB dashboard, overview dashboard and module-level pages contain different filters and are identified by roleName in configs API.

2. The Wards/Blocks filter is a dependable filter, which gets loaded on ULB selection.

3. In the ULB dashboard, the on-page ULB filter is applied across all the charts and for the performance chart, the default ULB filter is not applied.

4. Overview and all module level pages has a ULB dashboard.

GLOBAL Filters (refer to figure 2.8)

Admin role: On the Module level page, Date, DDR and ULB filter are loaded.

On the Overview level page, Date, DDR, ULB and Service filter are loaded.

Commissioner role: On the Module level page, Date, ULB and Wards/Blocks filters are loaded.

On the Overview page, Date, ULB and Service filters are loaded.

Denomination filter: The Denomination filter has three options to display the amount and number in a particular format.

1. Crore

2. Lack

3. Unit

The denomination filter is not applied to the percentage and text (refer to figure 2.10). The type of data is identified by a symbol in the plots of charts API.

Custom Date Filter

If duration < 15 days, it displays data day-wise

If duration <= 30 days, it displays data week-wise

If duration >30, it displays data month-wise

Tabs

Currently, the dashboard contains two types of tabs -

1. Revenue (refer figure: 4.1)

2. Service (refer figure: 4.1)

Tabs are identified by name in visualisations of config API.

Table Chart with drill-down

Table chart visualisations have normal material UI data table features like search, sort etc.

In table response, if filter key & drillDownChartId contain any value users can drill-down the table.

Cards

1. Each card header is localised and has an info icon with a tooltip option that displays the header and can display a description.

2. The number of cards in a row and in a page is driven by the backend. The backend provides the row number to each card where it should be displayed.

3. Card contains option icon that enables users to either download images and or share images.

4. Image download and share user id from vizArray in order to differentiate each card in a page.

Download and Share (refer to figure 2.9)

Download offers two options - to download data as an image or a PDF.

Configurations

BASE URL: End point of REST API for dashboard.

FILE Upload: End point of REST API for file upload.

FETCH FILE: End point of REST API for file fetch.

MDMS: End point of REST API for fetch MDMS Data.

SHORTEN URL: End point of REST API for Shorten URL, which is used for share via Email / What's app.

CHART COLOR CODE: Color code object for all charts.

MODULE LEVEL: for global filters, which contains services name & filter key.

SERVICES: for global filter, service filter.

Upload Localisation Keys

code: pre-defined key for back-end.

message: message contains the value for the key.

module: rainmaker-dss

locale: contains locale data

for more details eGov team to be documented

Module name: rainmaker-dss

Steps to setup DSS in Local

Step 1: Run as independent, switch to dss-dashboard folder

Step 2: Get the below details from the environment website and update the localstorage in the browser.

Employee.tenant-id Employee.user-info Employee.token Employee.module Employee.locale localization_en_IN locale

Step 3: Run Yarn install and yarn start to start working on dss in local setup.