Dynamic Payload

One of the most important API provided by the run time is to execute a CBA Package.

The nature of this API request and response is model driven and dynamic.

Here is how the a generic request and response look like.

request

response

{
  "commonHeader": {
    "originatorId": "",
    "requestId": "",
    "subRequestId": ""
  },
  "actionIdentifiers": {
    "blueprintName": "",
    "blueprintVersion": "",
    "actionName": "",
    "mode": ""
  },
  "payload": {
    "$actionName-request": {
      "$actionName-properties": {
      }
    }
  }
}

{
  "commonHeader": {
    "originatorId": "",
    "requestId": "",
    "subRequestId": ""
  },
  "actionIdentifiers": {
    "blueprintName": "",
    "blueprintVersion": "",
    "actionName": "",
    "mode": ""
  },
  "payload": {
    "$actionName-response": {
    }
  }
}

The actionName, under the actionIdentifiers refers to the name of a Workflow (see Workflow)

The content of the payload is what is fully dynamic / model driven.

The first top level element will always be either $actionName-request for a request or $actionName-response for a response.

Then the content within this element is fully based on the workflow inputs and outputs.

During the Enrichment CDS will aggregate all the resources defined to be resolved as input (see Node type -> Source -> Input), within mapping definition files (see Artifact Type -> Mapping), as data-type, that will then be use as type of an input called $actionName-properties.