Notification Integration Point

This integration point provides the ability to:

  • Accept notification from external systems on the processes that were invoked from gateway.

In case of a timeout exchange, notification received results in 200 Ok response.

The integration point provides HTTP status codes as defined in the Developer Guide under the section Response Messages.

The operations are protected by the HTTP API access restriction 'notification IP'.

The endpoint is available at the following location:

http://<host>:<port>/<context-root>/notifications

Notification Operations

POST/PUT on

http://<host>:<port>/<context-root>/notifications

Both POST and PUT methods are available to accept notifications in the gateway. The message structure is described below. The following steps occur in the gateway, once a message is received:

  • The correlationId in the notification payload is resolved to match the notification with an exchange invocation. If it is not matched or is not present, an exception is thrown.

  • The exchange is checked to be in status WaitingOnExternalSystem (W), else an exception is thrown.

  • The current exchange step on the exchange is marked as Done and the notification message is logged on the step.

  • The exchange is put on the queue to be resumed from the next step.

The notification payload structure is as follows:

{
  "correlationId" : "",
  "workId" : "",
  "status" : "",
  "key1" : "value1",
  "key2" : "value2",
  "key3" : "value3",
  "links" : [{
      "rel" : "file",
      "href" : "http://host:port/contextroot/datafilesets/{datafilesetcode}/datafiles/{datafilecode}/data"
  },
  {
      "rel" : "file",
      "href" : "http://host:port/contextroot/datafilesets/{datafilesetcode}/datafiles/{datafilecode}/data"
  }

  ]
}

  • workId: Id of the work that invoked this process, so if it was activities, this would be activityId

  • correlationId: The correlation id if any present during invocation of the process for which this notification is sent out

  • status: Success or Failure in case the notification is for a process, like activity processing. If the activity status is anything other than Completed, status is Failure else, Success.

  • links: The links available in the notification

  • rel=file: Assuming it will only be dataFileSet links to be downloaded using Data File Integration Point

  • other links as applicable

  • fields: Key or value pair of data if any with each notification.

POST/PUT on

http://<host>:<port>/<context-root>/notifications/custom

It is also possible to resume an exchange using a custom payload and not the payload structure defined in the first operation. The correlationId for a custom payload should be present as the header property of the request to notification endpoint.

Both POST and PUT methods are available to accept custom notifications in the gateway. The following steps happen in the gateway, once a custom message is received:

  • The correlationId in the header is resolved to match the notification with an exchange invocation. If it is not matched or is not present, an exception is thrown.

  • The exchange is checked to be in status WaitingOnExternalSystem (W), else an exception is thrown

  • The current exchange step on the exchange is marked as Done and the custom notification message is logged on the step.

  • Optionally, if the integration step (PROCESS type) specifies a dynamic logic function to extract Notification Object from this custom payload( signature Notification Payload Extractor), the framework invokes the logic to extract the notification and store that on the exchange step. The custom notification is then logged as a log line on the exchange step for auditing. Please refer to the Dynamic Logic: Functions section for more details.

  • The exchange is put on the queue to be resumed from the next step.