Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Master Data Management Service is a core service that is 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 logic of storage and retrieval of Master Data into other modules. The functionality is exposed via REST API

Prerequisites

Prior Knowledge of Java/J2EE, Spring Boot, advanced knowledge on how to operate JSON data would be an added advantage to understand 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 a 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 in your IDE to load it. Once the application is up and running API requests can be posted to the URL.

Configuration and 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 the 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. Here are some quick details for reference

 Click here to expand...

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 that is 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 - Request Info + MdmsCriteria — Details of module and master which need to be searched using MDMS.

Input Field

Description

Mandatory

Data Type

tenantId

Unique id for a tenant

Yes

String

moduleDetails

module for which master data is required

Yes

Array

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.

Input 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 - to be enhanced in future to include IN PROGRESS 

Enum: SUCCESSFUL or FAILED

Yes

String

  • No labels