Versions Compared

Old Version 8

changes.mady.by.user Mrinalika Akula

Saved on

compared with

New Version Current

changes.mady.by.user Mrinalika Akula

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

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