Custom Error Handling

You can handle errors between the HTTP transport layer and a REST application layer.

Since the REST adapter works as a hybrid adapter between an HTTP transport layer and a REST application layer, it is necessary to map certain error conditions between the layers.

Example

An HTTP error code of 404 means that the requested URL is invalid, which would be an error from a transport layer perspective. However, from the REST application layer perspective, it could also mean that an existing resource (such as customer or order) does not exist, in which case the message should be treated as having been sent successfully.

To allow you to set up the desired behavior, the REST adapter supports Custom Error Handling.

You can use custom error handling to define that certain error conditions are ignored, and to react with custom result messages. In addition, you can create error conditions based on the content of the message data.

On the Error Handling tabs in the sender and receiver channels, you can define up to ten rules. Each rule is independent from the others. The rules are evaluated from top to bottom, and the first rule that matches determines the action to be taken.

Each rule has a condition and an action. The condition consists of a data source and a value check. The action types are Error, Ignore Error, and Custom Result.

Table 1: Action Types
Error	Message delivery stops and will be set to failed.
Ignore Error	Any errors are ignored and the message is marked as successfully sent. For synchronous messages, an empty message payload will be returned.
Custom Result	Delivery state is set to successful and a custom text is returned for synchronous calls. Placeholder variables in curly brackets are evaluated.

Each time a custom error handling rule matches, an audit log entry is written, showing the action/strategy and the originating rule.

Configuring Custom Error Handling on the Receiver Side

On the receiver side, a rule can be configured for unspecific error situations within the receiver channel or based on the data returned by an HTTP call.

Table 2: Action Types
Trigger	Description	Example
Exception	Fired for any kind of error in the adapter.	An invalid character code page or errors during conversion between XML and JSON.
Status Code	Fired for selected HTTP status codes returned by the HTTP server. You can specify multiple codes as a comma-separated list. The list can contain specific codes, glob expressions, and range specifications.	The rule list “404, 405, 300-310, 5*” matches the codes 404, 405, 300 up to 310, and all codes starting with 5.
Status Text	Fired if a fixed character string or a glob expression matches the HTTP status text.	A “not found” rule would match all status texts containing the phrase “not found”.
Header Element	Fired if a fixed character string or a glob expression matches the content of a given HTTP header.	The value of a cookie can be checked by specifying the header variable “cookie” and checking the content of the variable.
Text Content	Fired if a fixed character string or a glob expression matches the HTTP result text.
JSON Content	Fired if a fixed character string or a glob expression matches the value of a given JSON element, extracted from the HTTP result.
XML Content	Fired if a fixed character string or a glob expression matches the value of a given XML element, extracted from the HTTP result.

Configuring Custom Error Handling on the Sender Side

Table 3: Action Types
Trigger	Description
Exception	Fired for any kind of error in the adapter.
Text Content	Fired if a fixed character string or a glob expression matches the content of the returned XI message.
JSON Content	Fired if a fixed character string or a glob expression matches the value of a given JSON element, extracted from the returned XI message.
XML Content	Fired if a fixed character string or a glob expression matches the value of a given XML element, extracted from the returned XI message.