NUTRINTG Trace Service
- Sebastian Baltruszewicz
- 1 Purpose
- 1.1 How it works
- 2 API
- 2.1 Environments
- 2.2 Endpoints
- 2.3 Utils
Purpose
Middleware communication is done asynchronously. Due to it’s principles, we are unable to inform 3rd party utilizing it, in the moment of request, what exact answer from requested integration point (CDS/CDP) is.
Trace service, is answer for that.
How it works
To each request we assign special identifier called “traceId”, which can be used to retrieve status and if process is finished, extract response from endpoints. This identifier is passed down through each service, generating various events (sort of “checkpoint” system).
{
"clientId":"53127aa4-31a9-4383-ae0b-aebd80a9d126",
"sourceAccountNumber":"MJNPOL_53127aa4-31a9-4383-ae0b-aebd80a9d126",
"traceId":"1213e85f-a303-4511-bd17-06bffb41004e"
}API
Environments
Environment | Address |
|---|---|
TEST | |
STAGE | |
PROD |
Endpoints
endpoint | description |
|---|---|
/getAllByTraceId/:traceId | Returns all trace events from all services it passes. |
/getJobStatusByTraceId/:traceId | Returns job status (in progress, finished with success/failure) |
getResponseByTraceId/:traceId | Returns trace event containing end storage system (currently only CDP) response for given request |
There are also corresponding endpoints utilizing correlationId (getAllByCorrelationId etc).
Because correlationId is used mainly for debug purposes this side of API would be rarely if ever used outside DEV team and debugging (and those endpoints work in very same way, added for convenience).
Utils
Below is attached currently used API and postman collection tied to it.
