Inbox v2 & Elastic Search

Overview

This page outlines the steps required to configure the inbox to enable viewing complaints and indexing the complaint data using ElasticSearch.

Service	Purpose
Inbox V2	UI to display user tasks (e.g., complaints, applications)
Indexer	Sends complaints data to ElasticSearch
ElasticSearch	Stores indexed data and supports fast search queries

---

The following core components are required for the configuration:

Component	Purpose
Indexer Config	Maps Kafka data into ElasticSearch (decides what to store)
MDMS Config	Defines how Inbox service queries ElasticSearch
Reindexing	Used when existing data is missing or out of sync

---

Configure Indexer & Inbox v2

A Kafka message is generated whenever a complaint is raised. The Indexer service reads it and stores data in ElasticSearch, based on this configuration.

Configuration parameter details:

Field	Description
topic	Kafka topic: save-pgr-request
index	ElasticSearch index: pgr-services; customJsonMapping:
fieldMapping	Maps input JSON to index structure inJsonPath; outJsonPath

Follow the steps below to send the Citizen Complaints module data to Elastic Search.

1

Create file pgr-services.yml

Create a file pgr-services.yml inside the given path at the config repo on GitHub

• Create file: egov-indexer/pgr-inbox-indexer.yml

• Paste the indexer config into this file: Sample Config File for Reference

• Restart the Indexer service so it picks up the new configuration.

2

MDMS Configuration for Inbox V2

The MDMS configuration defines how the Inbox V2 module fetches data from ElasticSearch to show complaint details in the UI.

Refer to the Master Data configuration doc for details. This step is not required if the master data configuration is done.

Below are the steps to configure MDMS for Inbox V2 -

A. Import Postman Collection

• Open the provided Postman collection.

• Copy the above Postman collection.

• Click on the Import icon in Postman.

• Paste the URL and import the collection.

• After import, you’ll find the collection on the left panel of Postman.

• Before proceeding to the next step, make sure the prerequisites baseUrl and authtoken are updated.

B. Set Up Postman Environment Variables

• Make sure your Postman environment has these updated values:

  • baseUrl (e.g., https://dev.digit.org) (This is the domain URL where your application is running . Need to copy that domain URL here)

  • User Details (Mdsm admin user) (Which was created during the installation . Need to copy username, password, and tenantid of the mdmsAdmin user)

  • tenantId (e.g., pb, uk) (In the request body, need to verify or update the tenantId where going to set up the master data )

• Add the required variables in the Postman Collection before running the MDMS script. Refer to the table below for details.

Variable Name	Description
Url	The domain URL where your DIGIT application is hosted. Example: https://pgr-demo.digit.org 📌 Add this in the "URL" variable field.
username	The admin username for MDMS (e.g., mdms admin). Required for authentication. 📌 Add this in the "username" variable field.
password	The admin password for the above username. 📌 Add this in the "password" variable field.
tenant	The state-level tenant ID (e.g., pg). 📌 Add this in the "tenant" variable field.
userTenant	The ULB-level tenant ID where the user has been created (e.g., pg). 📌 Add this in the "userTenant" variable field.

C. Pre-run Checklist

Final Checklist Before Running:

• Variables are filled correctly as per the environment.

• Admin user created and credentials are working.

• The collection is imported and opened in Postman.

• No missing or invalid values.

D. Run the Collection

• Open Postman and locate the collection named "MDMS v2 inbox Creation".

• Click the three dots (⋮) next to the collection name (on the right side).

• On the right side of the new screen, you’ll see an orange button labelled "Run MDMS v2 inbox Creation" — click this.

• The collection will now start running. You will see each API request and its response as they execute.

E. Check Results

• ✅ If all requests succeed (green checkmarks), your MDMS setup for Inbox V2 is complete.

• ❌ If any request fails (red cross), re-run the collection to retry the failed steps.

Important Note: Master data should only be created after the initial schema creation API call has been successfully executed

3

Reindexing (Optional - Only if Needed)

Re-process older complaint data if it's missing from ElasticSearch due to errors or changes. If complaints are not appearing in the Inbox or ElasticSearch (due to Kafka failure, config change, or migration), reindexing helps restore that data.

Make sure the following pre-requisites are met before you begin with reindexing:

• Access to kubectl

• Access to playground pod

• Existing legacy indexer config available

Steps for reindexing

1. Import Reindexing Postman Collection:

   1. Contains:

      • pgr-services-legacy

      • pgr-services-legacy-kafkaconnector

   2. Run from Playground Pod

2. Create Kafka Connector:

POST http://kafka-connect.kafka-cluster:8083/connectors

1. Trigger Legacy Indexing Push historical data /pgr-plainsearch into Kafka.

2. Monitor Logs Check the indexer pod logs to ensure reindexing is processing.

3. Delete Kafka Connector

bashCopyEditcurl --location --request DELETE \
'http://kafka-connect.kafka-cluster:8083/connectors/pgr-services-enriched-es-sink'

Copy the enriched index back to the main index:

jsonCopyEditPOST _reindex
{
  "source": {
    "index": "pgr-services-enriched"
  },
  "dest": {
    "index": "pgr-services"
  }
}

---

Summary

Step	What you do	Purpose
1️⃣	Add Indexer config	Send PGR complaint data to ElasticSearch
2️⃣	Add Inbox MDMS config	Enable Inbox V2 to search and sort complaints
3️⃣	(Optional) Reindex	Fix data mismatch or reprocess missed entries

Tips

• Always restart the indexer and MDMS after changes.

• Verify Elastic index (pgr-services) has updated data.

• You can test your inbox filter via Postman using the /inbox/v2/_search API.