MDMS Rewritten

Overview

Master Data Management Service is a core service made available on the DIGIT platform. It encapsulates the functionality surrounding Master Data Management. The service creates, updates and fetches Master Data pertaining to different modules. This eliminates the overhead of embedding the storage and retrieval logic of Master Data into other modules. The functionality is exposed via REST API.

Pre-requisites

Prior Knowledge of Java/J2EE, Spring Boot, and advanced knowledge of operating JSON data would be an added advantage to understanding the service.

Functionality

The MDM service reads the data from a set of JSON files from a pre-specified location. It can either be an online location (readable JSON files from online) or offline (JSON files stored in local memory). The JSON files should conform to a prescribed format. The data is stored in a map and tenantID of the file serves as the key.

Once the data is stored in the map the same can be retrieved by making an API request to the MDM service. Filters can be applied in the request to retrieve data based on the existing fields of JSON.

Setup and Usage

The spring boot application needs lombok extension added to your IDE to load it. Once the application is up and running API requests can be posted to the URL.

Configuration & Structure

The config JSON files to be written should follow the listed rules

• The config files should have JSON extension.

• The file should mention the tenantId, module name, and master name first before defining the data.

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

The Master Name in the above sample will be substituted by the actual name of the master data. The array succeeding it will contain the actual data.

Example config JSON for “Billing Service”

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

API Reference Documentation

APIs are available to create, update and fetch master data pertaining to different modules. Refer to the segment below for quick details.

BasePath:/mdms/v1/[API endpoint] Method

POST /_create

Creates or Updates Master Data on GitHub as JSON files

MDMSCreateRequest Request Info + MasterDetail — Details of the master data to be created or updated on GitHub.

MasterDetail

Input Field	Description	Mandatory	Data Type
tenantId	Unique id for a tenant.	Yes	String
filePath	file-path on git where master data is to be created or updated	Yes	String
masterName	Master Data name to be created or updated	Yes	String
masterData	content to be written on to the Config file	Yes	Object

MdmsCreateResponse Response Info

Method

POST /_search

This method fetches a list of masters for a specified module and tenantId.

MDMSCriteriaReq (mdms request) - Request Info + MdmsCriteria — Details of module and master which need to be searched using MDMS.

MdmsCriteria

Input Field	Description	Mandatory	Data Type
tenantId	Unique id for a tenant	Yes	String
moduleDetails	module for which master data is required	Yes	Array

MdmsResponse Response Info + Mdms

MDMS

Input Field	Description	Mandatory	Data Type
mdms	Array of modules	Yes	Array

Common Request/Response/Error Structures:

RequestInfo should be used to carry meta information about the requests to the server as described in the fields below. All DIGIT APIs will use requestinfo as a part of the request body to carry this meta information. Some of this information will be returned back from the server as part of the ResponseInfo in the response body to ensure correlation.

Input Field	Description	Mandatory	Data Type
apiId	unique API ID	Yes	String
ver	API version - for HTTP based request this will be same as used in path	Yes	String
ts	time in epoch format: int64	Yes	Long
action	API action to be performed like _create, _update, _search (denoting POST, PUT, GET) or _oauth etc	Yes	String
DID	Device ID from which the API is called	No	String
Key	API key (API key provided to the caller in case of server to server communication)	No	String
msgId	Unique request message id from the caller	Yes	String
requestorId	UserId of the user calling	No	String
authToken	//session/jwt/saml token/oauth token - the usual value that would go into HTTP bearer token	Yes	String

ResponseInfo should be used to carry metadata information about the response from the server. apiId, ver, and msgId in ResponseInfo should always correspond to the same values in the respective request's RequestInfo.

Output Field	Description	Mandatory	Data Type
apiId	unique API ID	Yes	String
ver	API version	Yes	String
ts	response time in epoch format: int64	Yes	Long
resMsgId	unique response message-id (UUID) - will usually be the correlation id from the server	No	String
msgId	message-id of the request	No	String
status	status of request processing - Enum: SUCCESSFUL (HTTP 201) or FAILED (HTTP 400)	Yes	String

ErrorRes

All DIGIT APIs will return ErrorRes in case of failure which will carry ResponseInfo as metadata and Error object as an actual representation of the error. When the request processing status in the ResponseInfo is ‘FAILED’ the HTTP status code 400 is returned.

Output Field	Description	Mandatory	Data Type
code	Error Code will be a module-specific error label/code to identify the error. All modules should also publish the Error codes with their specific localized values in localization service to ensure clients can print locale-specific error messages. An example of an error code would be UserNotFound to indicate User Not Found by User/Authentication service. All services must declare their possible Error Codes with a brief description in the error response section of their API path.	Yes	String
message	English locale message of the error code. Clients should make a separate call to get the other locale description if configured with the service. Clients may choose to cache these locale-specific messages to enhance performance with a reasonable TTL (May be defined by the localization service based on tenant + module combination).	Yes	String
description	Optional long description of the error to help clients take remedial action. This will not be available as part of the localization service.	No	String
params	Some error messages may carry replaceable fields (say $1, $2) to provide more context to the message. E.g. Format related errors may want to indicate the actual field for which the format is invalid. Client's should use the values in the param array to replace those fields.	No	Array