This section contains docs that walk you through the various steps required to configure DIGIT services.

• API Do's And Dont's

• Setting Up Service Locally

• Configuring Reports

• Customizing PDF Notices And Certificates

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

This section walks you through the steps to adding a new language or setting up the default language on the DIGIT system.

• Adding New Language

• Setting Up Default Language For SMS & Emails

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

Overview

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.

Pre-requisites

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.

Key Functionalities

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

Configuration Details

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

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.

Details coming soon...

Overview

Digit system supports multiple languages. To add a new language, it should be configured in MDMS.

Pre-requisites

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.

Key Functionalities

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

Deployment Details

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

Configuration Details

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.

{
  "tenantId": "uk", //<ReplaceWithDesiredTenantId>
  "moduleName": "common-masters",
  "StateInfo": [
    {
      "languages": [
        {
          "label": "ENGLISH",  
          "value": "en_IN"   
        },
        {
          "label": "हिंदी",     // <ReplaceWithTheRequiredLanguageName>
          "value": "hi_IN"   // <ReplaceWithTheRequiredLanguageKey>
        }
      ]
    }
  ]
}

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.

"languages": [
        {
          "label": "ENGLISH",  
          "value": "en_IN"   
        },
        {
          "label": "हिंदी",     // <ReplaceWithTheRequiredLanguageName>
          "value": "hi_IN"   // <ReplaceWithTheRequiredLanguageKey>
        },
        {
          "label": "ಕನ್ನಡ", // <ReplaceWithTheRequiredLanguageName>
          "value": "kn_IN" <ReplaceWithTheRequiredLanguageKey>
        },
        {
          "label": "language3", // <ReplaceWithTheRequiredLanguageName>
          "value": "language3key" <ReplaceWithTheRequiredLanguageKey>
        }
      ]

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

{
  "code": "unique key referred ",
  "message": "Value to be shown in UI or send in SMS/Email",
  "module": "rainmaker-<modulename>",
  "locale": "<language key>"
}

Sample of localization

In Hindi language

{
  "code": "CS_LANDING_PAGE_WELCOME_TEXT",
  "message": "आपका स्वागत है ",
  "module": "rainmaker-pgr",
  "locale": "hi_IN"
}

In English language

{
  "code": "CS_LANDING_PAGE_WELCOME_TEXT",
  "message": "Welcome",
  "module": "rainmaker-pgr",
  "locale": "en_IN"
}

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.

{
  "tenantId": "uk",   //<ReplaceWithDesiredTenantId>
  "moduleName": "common-masters",
  "StateInfo": [
    {
      "defaultLanguage": "kn_IN",  //<ReplaceWithTheLanguageKey>
        "languages": [
        {
          "label": "ENGLISH",  
          "value": "en_IN"   
        },
        {
          "label": "हिंदी",     
          "value": "hi_IN"   
        },
        {
          "label": "ಕನ್ನಡ", // <ReplaceWithTheRequiredLanguageName>
          "value": "kn_IN" <ReplaceWithTheRequiredLanguageKey>
        }
      ]
    }
  ]
}

Reference Docs

Doc Links

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.

ServiceMaps:
  serviceName: Trade License
  version: 1.0.0
  mappings:
  - topic: save-tl-tradelicense
    configKey: INDEX
    indexes:
    - name: tlindex-v1
      type: licenses
      id: $.id, $.tenantId
      isBulk: true
      timeStampField: $.auditDetails.createdTime
      jsonPath: $.Licenses
      customJsonMapping:
        indexMapping: {"Data":{"tradelicense":{},"ward":{},"tenantData":{}, "history":{}}}
        fieldMapping:
        - inJsonPath: $
          outJsonPath: $.Data.tradelicense
        externalUriMapping:
        - path: http://egov-location.egov:8080/egov-location/location/v11/boundarys/_search
          queryParam: hierarchyTypeCode=REVENUE,boundaryType=locality,codes=$.tradeLicenseDetail.address.locality.code,tenantId=$.tenantId
          apiRequest: {"RequestInfo":{"apiId":"org.egov.pt","ver":"1.0","ts":1502890899493,"action":"asd","did":"4354648646","key":"xyz","msgId":"654654","requesterId":"61","authToken":"d9994555-7656-4a67-ab3a-a952a0d4dfc8","userInfo":{"id":1,"uuid":"1fec8102-0e02-4d0a-b283-cd80d5dab067","type":"EMPLOYEE","tenantId":"pb.amritsar","roles":[{"name":"Employee","code":"EMPLOYEE","tenantId":"pb.amritsar"}]}}}
          uriResponseMapping:
          - inJsonPath: $.TenantBoundary[0].boundary[0]
            outJsonPath: $.Data.ward
        - path: http://egov-workflow-v2.egov:8080/egov-workflow-v2/egov-wf/process/_search
          queryParam: businessIds=$.applicationNumber,history=true,tenantId=$.tenantId
          apiRequest: {"RequestInfo":{"apiId":"org.egov.pt","ver":"1.0","ts":1502890899493,"action":"asd","did":"4354648646","key":"xyz","msgId":"654654","requesterId":"61","authToken":"d9994555-7656-4a67-ab3a-a952a0d4dfc8","userInfo":{"id":1,"uuid":"1fec8102-0e02-4d0a-b283-cd80d5dab067","type":"EMPLOYEE","tenantId":"pb.amritsar","roles":[{"name":"Employee","code":"EMPLOYEE","tenantId":"pb.amritsar"}]}}}
          uriResponseMapping:
          - inJsonPath: $.ProcessInstances
            outJsonPath: $.Data.history
        mdmsMapping:
        - path: http://egov-mdms-service.egov:8080/egov-mdms-service/v1/_search
          moduleName: tenant
          masterName: tenants
          tenantId: pb
          filter: "[?(@.code == $tenant)]"
          filterMapping:
          - variable: $tenant
            valueJsonpath: $.tenantId
          uriResponseMapping:
          - inJsonPath: $.MdmsRes.tenant.tenants
            outJsonPath: $.Data.tenantData

The configuration file contains the following keys:-

Overview

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.

Pre-requisites

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

Key Functionalities

• 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

Deployment Details

1. Deploy the latest version of egov-workflow-v2 service

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

3. Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)

4. Add businessService persister yaml path in persister configuration

Configuration Details

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.

{
      "tenantId": "pb",
      "businessService": "PGR",
      "business": "pgr-services",
      "businessServiceSla": 432000000,
      "states": [
        {
          "sla": null,
          "state": null,
          "applicationStatus": null,
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "APPLY",
              "nextState": "PENDINGFORASSIGNMENT",
              "roles": [
                "CITIZEN",
                "COUNTER_EMPLOYEE"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "APPLIED",
          "applicationStatus": "APPLIED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": false,
          "actions": [
            {
              "action": "APPROVE",
              "nextState": "APPROVED",
              "roles": [
                "APPROVER"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "APPROVER"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "REJECTED",
          "applicationStatus": "REJECTED",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true
        },
        {
          "sla": null,
          "state": "APPROVED",
          "applicationStatus": "APPROVED",
          "isStateUpdatable": false,
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true
        }
      ]
    }

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)

Integration

Integration Scope

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.

Integration Benefits

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.

Steps to Integration

1. To integrate, host of egov-workflow-v2 should be overwritten in helm chart

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

3. The configuration can be fetched by calling _search API

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection therefore the same link is added in each row)

__

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 or Failure

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

Blacklisting or Whitelisting numbers

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

Prefixing

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.

• Always define the Yaml for your APIs as the first thing using Open API 3 Standard (https://swagger.io/specification/)

• 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 RequestInfo object in request body at the top level

• Each API should have a ResponseInfo 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 -

  • Address

  • User(Citizen or Employee or Owner)

  • Role

  • AuditDetails

  • ErrorRes (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.

Overview

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 :

1. Count of applications

2. Statewide collections

3. Application status

4. Cancelled receipts

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

Pre-requisites

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

Key Functionalities

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

Deployment Details

1. After adding the new report/ editing existing report configuration in the respective module, the report service needs to be restarted.

Configuration Details

1. Create a reports.yml file and add report configuration as per standard format.

2. Add the action and role action in the mdms.

3. Add the github raw path of the report.yml file in the report.config file

Reference Docs

Doc Links

Overview

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.

Pre-requisites

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 Dashboard Configurations

Key Functionalities

1. Adding new Roles for Dashboards

2. Adding a new Dashboard

3. Adding new Visualizations in existing Dashboard

4. Adding new charts for visualizations :

1. Adding Roles and Dashboards :

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

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.

3. Adding new Visualizations in existing Dashboard

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

4.Adding charts for visualizations

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

Reference Docs

Doc Links

Overview

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.

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

Key Functionalities

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

Deployment Details

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

Configuration Details

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

Reference Docs

Doc Links

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

Pre-requisites

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

Key Functionalities

1. Creating a DSS dashboard schema

2. DSS ingest service APIs

3. Ingest service configurations

4. Creating Kafka sync connector to push the data to Elastic search

1. Creating a DSS dashboard schema

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

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.

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

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

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

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

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

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:

Reference Docs

Doc Links

This section provides a step by step guide to setting up workflows and configuring the workflows for DIGIT entities.

• Setting Up Workflows

• Configuring Workflows For An Entity

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

Overview

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.

Pre-requisites

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

Key Functionalities

• 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

Deployment Details

1. Deploy the latest version of egov-workflow-v2 service

2. Add businessService persister yaml path in persister configuration

3. Add Role-Action mapping for BusinessService API’s

4. Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)

Configuration Details

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

Integration

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection therefore same link is added in each row)

__

Details coming soon...

Details coming soon...

Overview

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.

Root Cause

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

Impact

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.

Overview

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.

Pre-requisites

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.

Key Functionalities

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.

Deployment Details

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.

Overview

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.

Pre-requisites

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.

Key Functionalities

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

Deployment Details

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

Configuration Details

1. Roles are added in roles.json In MDMS, file roles.json, under ACCESSCONTROL-ROLES folder roles are added. Sample roles:

{
  "tenantId": "uk",
  "moduleName": "ACCESSCONTROL-ROLES",
  "roles": [
    {
      "code": "CITIZEN",
      "name": "Citizen",
      "description": "Citizen who can raise complaint"
    },
    {
      "code": "TL_CEMP",
      "name": "TL Counter Employee",
      "description": "Who has a access to Trade License Services"
    },
    {
      "code": "TL_DOC_VERIFIER",
      "name": "Trade License Document verifier",
      "description": "Trade License Document verifier"
    },
    {
      "code": "TL_APPROVER",
      "name": "TL Approver",
      "description": "Who has a access to Trade License Workflow"
    }
  ]
}

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

Localization needs to be pushed for all the roles added in roles.json

Sample Localization for roles In English:

 {
  "code": "ACCESSCONTROL_ROLES_ROLES_TL_CEMP",  // <"ACCESSCONTROL_ROLES_ROLES_" should be appended before role code>
  "message": "TL Counter Employee",             // English Value to be shown in UI
  "module": "rainmaker-common",                 // module is added with rainmaker-common
  "locale": "en_IN"                             // English language key
}

In Hindi:

{
  "code": "ACCESSCONTROL_ROLES_ROLES_TL_CEMP",  // <"ACCESSCONTROL_ROLES_ROLES_" should be appended before role code>
  "message": "टीएल काउंटर कर्मचारी",               // Hindi value to be shown in UI
  "module": "rainmaker-common",                // module is added with rainmaker-common
  "locale": "hi_IN"                            // Hindi language key
}

Reference Docs

Doc Links

Overview

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.

Pre-requisites

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.

Key Functionalities

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

Deployment Details

• After mapping Roles with APIs, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

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:

{
  "tenantId": "uk",
  "moduleName": "ACCESSCONTROL-ACTIONS-TEST",
  "actions-test": [
    {
      "id": 1685,  //<Unique identifier>
      "name": "Create TradeLicense",
      "url": "/tl-services/v1/_create", //<url of the feature>
      "parentModule": "",
      "displayName": "Create TradeLicense",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "tl-services",
      "code": "null",
      "path": ""
     },
     {
      "id": 1686,
      "name": "Update TradeLicense",
      "url": "/tl-services/v1/_update",
      "parentModule": "",
      "displayName": "Update TradeLicense",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "tl-services",
      "code": "null",
      "path": ""
    }
   ]
  }

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:

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:

{
  "tenantId": "uk",
  "moduleName": "ACCESSCONTROL-ROLEACTIONS",
  "roleactions": [
    {
      "rolecode": "TL_CEMP",
      "actionid": 1685,
      "actioncode": "",
      "tenantId": "uk"
    },
    {
      "rolecode": "CITIZEN",
      "actionid": 1685,
      "actioncode": "",
      "tenantId": "uk"
    }
  ]
}

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.

Reference Docs

Doc Links

Videos

Overview

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

Pre-requisites

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

Key Functionalities

• Adding New APIs(actions) and Mapping Roles with that APIs provides permission to perform certain task can be restricted based on the requirement.

Deployment Details

• After mapping Roles with APIs, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

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 -

{
  "tenantId": "uk",
  "moduleName": "ACCESSCONTROL-ACTIONS-TEST",
  "actions-test": [
    {
      "id": <unique and sequential to previous id>,
      "name": "rainmaker-common-propertytax",
      "url": "card",
      "displayName": "Property Tax",
      "orderNumber": 2,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "",
      "code": "",
      "path": "",
      "navigationURL": "property-tax",
      "leftIcon": "action:store",
      "rightIcon": "",
      "queryParams": ""
    },
   ]
  }

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:

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:

{
  "tenantId": "uk",
  "moduleName": "ACCESSCONTROL-ROLEACTIONS",
  "roleactions": [
    {
      "rolecode": <specific code defined in roles.json>,
      "actionid": <id of an action>,
      "actioncode": "",
      "tenantId": <state notation of tenantId>(like uk,pb etc)
    }
  ]
}

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.

Reference Docs

Doc Links

Overview

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.

Pre-requisites

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.

Key Functionalities

• 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

Deployment Details

1. Create data config and format config for a PDF according to product requirement.

2. Add data config and format config files in PDF configuration

3. Add the file path of data and format config in the environment yml file

4. Deploy the latest version of pdf-service in a particular environment.

Configuration Details

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.

The data config file contains the following aspects

Sample structure of variable definition in data config

{
  “Variable”: “variable_name”,
  “Value”:{
      “path”: “$.propertyId”             -----> jsonpath to obtain value.
  }

}

 {
  “Variable”: “variable_name”,
  “Value”:{
    “path”: “$.propertyId”             -----> jsonpath to obtain value or key to obtain value from localisation.
  },
  “type”:  “label”,                    -----> this field is used to mark this variable as label.       
  “localisation”:{
      “required”: “false”,             -----> if this field is true then  localisation is used for this variable and vice versa.
      “prefix”: “null”,                -----> prefix of the key which is declared in path field.
      “module”: “rainmaker-tl”         -----> the module from which localisation entry is fetched
  }
}

Example to show date in PDF

{
  “Variable”: “variable_name”,
  “Value”:{
    “path”: “$.date”             -----> jsonpath to obtain epoch value of date
  },
  “type”: "date"                  -----> this field is used to mark this variable as date.       
  "format": "YYYY/MM/DD "
}

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 Unix-Timestamp

Example of external API calling to MDMS service

“externalAPI”: [
    “path”: “http://egov-mdms-service:8080/egov-mdms-service/v1/_get”,
    “queryParam”: “moduleName=tenant&masterName=tenants&tenantId=pb&filter=%5B?(@.code=='{$.tenantId}')%5D”,
    “apiRequest”: null,
    “responseMapping”:[
      {
          “variable”: “address”,
          “value”: “$.MdmsRes.tenant.tenants[0].address”
      },
      {
          “variable”: “phoneNumber”,
          “value”: “$.MdmsRes.tenant.tenants[0].contactNumber”
      }
    ]
  ]

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:

"mappings": [
          {
            "direct": [
              {
                "variable": "propertyID",
                "value": {
                  "path": "$.consumerCode"
                }
              },
              {
                "variable": "tenantId",
                "value": {
                  "path": "$.tenantId"
                }
              },
              {
                "variable": "businessServiceCode",
                "value": {
                  "path": "$.businessService"
                }
              }
            ]
          },
          {
            "qrcodeConfig": [
              {
                "variable": "qrcodeimage",
                "value": "citizen/egov-common/pay?consumerCode={{propertyID}}&tenantId={{tenantId}}&businessService={{businessServiceCode}}"
              }
            ]
          }
        ]

The format config file contains the following aspects

Example of adding footer in PDF (adding page number in the footer)

{
"key": "property-bill",
"config": {
"defaultStyle": {....},
"content": [....],
"style": {....},
"footer": "(function(currentPage, pageCount) { return currentPage.toString() + ' of ' + pageCount; })"
}
}

The position of page number in the footer is configurable. For more detail refer this document Header and Footer

Example of adding Qr Code

Format Config for Qr Code

{
  "image": "{{qrcodeimage}}", ----> use declared variable in qrcodeConfig from dataconfig
  "width": 64,
  "height": 64
}

Integration

For Integration with UI, please refer to the links in Reference Docs

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)

__

Overview

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

Pre-requisites

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.

Key Functionalities

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

Configuration Details

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

Reference Docs

Doc Links

Overview

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

Pre-requisites

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.

Key Functionalities

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.

Deployment Details

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

Configuration Details

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

Reference Docs

Doc Links

Overview

The objective of PDF generation service is to bulk generate pdf as per requirement.

Pre-requisites

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

Key Functionalities

• Provide functionality to download and print PDF’s

• Provide functionality to download and print bulk PDF’s

Deployment Details

1. Create data config and format config for a PDF according to product requirement.

2. Add data config and format config files in PDF configuration

3. Add the file path of data and format config in the environment yml file

4. Deploy the latest version of pdf-service in a particular environment.

Configuration Details

For Configuration details please refer to the Customizing PDF Receipts & Certificates document in Reference Docs

Integration

Integration Scope

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.

Integration Benefits

• 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

Steps to Integration

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

let tlCertificateDownloadObject = {
    label: { labelName: "TL Certificate", labelKey: "TL_CERTIFICATE" },
    link: () => {
      const { Licenses } = state.screenConfiguration.preparedFinalObject;
      downloadCertificateForm(Licenses);
    },
    leftIcon: "book"
  };
  let tlCertificatePrintObject = {
    label: { labelName: "TL Certificate", labelKey: "TL_CERTIFICATE" },
    link: () => {
      generateReceipt(state, dispatch, "certificate_print");
    },
    leftIcon: "book"
  };

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

export const downloadCertificateForm = (Licenses) => {
  const queryStr = [
    { key: "key", value: "tlcertificate" },
    { key: "tenantId", value: "pb" }
  ]
  const DOWNLOADRECEIPT = {
    GET: {
      URL: "/pdf-service/v1/_create",
      ACTION: "_get",
    },
  };
  try {
    httpRequest("post", DOWNLOADRECEIPT.GET.URL, DOWNLOADRECEIPT.GET.ACTION, queryStr, { Licenses }, { 'Accept': 'application/json' }, { responseType: 'arraybuffer' })
      .then(res => {
        res.filestoreIds[0]
        if (res && res.filestoreIds && res.filestoreIds.length > 0) {
          res.filestoreIds.map(fileStoreId => {
            downloadReceiptFromFilestoreID(fileStoreId)
          })
        } else {
          console.log("Error In Acknowledgement form Download");
        }
      });
  } catch (exception) {
    alert('Some Error Occured while downloading Acknowledgement form!');
  }
}

Example of function generateReceipt

const generateReceipt = async (state, dispatch, type) => {
//  console.log("Transformed Data--",transformedData);
  pdfMakeCustom.vfs = pdfFonts.vfs;
  pdfMakeCustom.fonts = {
    Camby:{
            normal: 'Cambay-Regular.ttf',
            bold: 'Cambay-Regular.ttf',
            italics: 'Cambay-Regular.ttf',
            bolditalics: 'Cambay-Regular.ttf'
    },

  };
  let data1 = _.get(
    state.screenConfiguration.preparedFinalObject,
    "applicationDataForReceipt",
    {}
  );
  let data2 = _.get(
    state.screenConfiguration.preparedFinalObject,
    "receiptDataForReceipt",
    {}
  );
  let data3 = _.get(
    state.screenConfiguration.preparedFinalObject,
    "mdmsDataForReceipt",
    {}
  );
  let data4 = _.get(
    state.screenConfiguration.preparedFinalObject,
    "userDataForReceipt",
    {}
  );
  let data5 = _.get(
    state.screenConfiguration.preparedFinalObject.Licenses[0].tradeLicenseDetail,
    "address",
    {}
  );

  let ulbLogo = _.get(
    state.screenConfiguration.preparedFinalObject,
    "base64UlbLogo",
    ""
  );
  if (_.isEmpty(data1)) {
    console.log("Error in application data");
    return;
  } else if (_.isEmpty(data2)) {
    console.log("Error in receipt data");
    return;
  } else if (_.isEmpty(data3)) {
    console.log("Error in mdms data");
    return;
  } else if (_.isEmpty(data4)) {
    console.log("Error in auditor user data");
    return;
  } else if (_.isEmpty(ulbLogo)) {
    console.log("Error in image data");
    return;
  }
  let transformedData = {
    ...data1,
    ...data2,
    ...data3,
    ...data4,
    actualAddress:data5
  };
  switch (type) {
    case "certificate_download":

      let certificate_data = getCertificateData(transformedData, ulbLogo);
      certificate_data &&
     //  pdfMakeCustom.createPdf(certificate_data).download("tl_certificate.pdf");
      pdfMakeCustom.createPdf(certificate_data).open();
      break;
    case "certificate_print":
      certificate_data = getCertificateData(transformedData, ulbLogo);
      certificate_data && pdfMakeCustom.createPdf(certificate_data).print();
      break;
    case "receipt_download":
      let receipt_data = getReceiptData(transformedData, ulbLogo);

      receipt_data &&
     //   pdfMakeCustom.createPdf(receipt_data).download("tl_receipt.pdf");
        pdfMakeCustom.createPdf(receipt_data).open();
      break;
    case "receipt_print":
      receipt_data = getReceiptData(transformedData, ulbLogo);
      receipt_data && pdfMakeCustom.createPdf(receipt_data).print();
      break;
    default:
      break;
  }
};

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection therefore the same link is added in each row)

__