Event based inbox

The event based inbox service is a service that fetches pre-aggregated data of municipal services and workflow and performs complex search operations and returns applications and workflow data in a paginated manner. The service also returns total count matching the search criteria.

 

The first step is to capture pre-aggregated events for the module which needs to be enabled in event based inbox. This index needs to hold all the fields against which search needs to be performed and any other fields which need to be shown in the UI when applications are listed.

 

Now, this service allows to search both the module objects as well as processInstance(Workflow record) based on the provided criteria for any of the municipal services. For this, it uses a module specific configuration. A sample configuration is given below -

{ "tenantId": "pb", "moduleName": "INBOX", "InboxQueryConfiguration": [ { "module": "WS", "index": "ws-inbox-test", "allowedSearchCriteria": [ { "name": "tenantId", "path": "Data.tenantId.keyword", "isMandatory": true, "operator": "EQUAL" }, { "name": "status", "path": "Data.currentProcessInstance.state.uuid.keyword", "isMandatory": false }, { "name": "mobileNumber", "path": "Data.mobileNumberHash.keyword", "isMandatory": false, "isHashingRequired": true }, { "name": "locality", "path": "Data.locality.keyword", "isMandatory": false }, { "name": "assignee", "path": "Data.workflow.assignes.keyword", "isMandatory": false }, { "name": "applicationNumber", "path": "Data.applicationNo.keyword", "isMandatory": false }, { "name": "fromDate", "path": "Data.auditDetails.createdTime", "isMandatory": false, "operator": "GTE" }, { "name": "toDate", "path": "Data.auditDetails.createdTime", "isMandatory": false, "operator": "LTE" } ], "sortBy": { "path": "Data.additionalDetails.appCreatedDate", "defaultOrder": "ASC" }, "sourceFilterPathList": ["Data.currentProcessInstance", "Data.auditDetails", "Data.additionalDetails", "Data.tenantId", "Data.proposedTaps","Data.applicationNo","Data.workflow","Data.locality"] } ] }

Inside each query configuration object, we have the following keys -

  • module - Module code for which inbox has been configured.

  • index - Index where pre-aggregated events are stored.

  • allowedSearchCriteria - This lists out various parameters on which searching is allowed for the given module

  • sortBy - Specifies the field path inside the pre-aggregated record present in the index against which the result has to be sorted. Default order can be specified to ASC or DESC .

  • sourceFilterPathList - This is a list which specifies the fields which should appear and which should not appear as part of the search result in order to avoid clutter and to improve query performance.

Within allowedSearchCriteria , each object is going to be having the following keys -

  • name - Name of the incoming search parameter in inbox request body.

  • path - Path inside the pre-aggregated record present in the index against which the incoming search parameter needs to be matched.

  • isMandatory - This specifies whether a particular parameter is mandatory to be sent in inbox search request or not.

  • operator - This specifies which operator clause needs to be applied while forming ES queries. Currently, we support equality and range comparision operators only.

 

New inbox service needs to be enabled via configuration present in MDMS. The path to the MDMS configuration is - https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/inbox-v2/InboxConfiguration.json .

Once configuration is added to this MDMS file, MDMS service for that particular environment has to be restarted.

 

Pointers for migrating to event based inbox -

If any existing module needs to be migrated onto new inbox, data needs to be reindexed, and configuration needs to be written to enable these modules on new inbox.

  • For modules where search has to be given on PII data like mobile number, a migration API needs to be written which will fetch data from database, decrypt it, hash it using enc client and store it in the index to enable search.

  • For modules where search has to given on non PII data, indexer service’s _legacyIndex API can be invoked to move data to the new index.