Error Handling for Composite IBM DataPower Services

In general, when it comes to error handling i am a big believer in “Defense in Depth”. I prefer a multi-layered approach in which I try to account for the maximum possible conditions at each layer and eventually have a “catch all” net where I catch and process the errors that ‘slipped through the cracks’.

Let’s take a scenario where we have an orchestration service which is tied to a bunch of back-end proxy services. Each of the back-end proxies is tied to corresponding back-end application.

Below is the logical representation of a complex composite service on IBM DataPower:

Below is a description of the “Happy Path” i.e. the ideal scenario in which there is no error:

1. The incoming request is received by the ‘Orchestration Service’.
2. The orchestration service then makes a series of calls to the various back-end proxies. The request message for each call is dependent on the response messages from the previous calls.
3. The back-end proxy receives the message and in turn calls the back-end application.
4. The back-end application processes the message and replies with a response message.
5. The back-end DataPower proxy receives the response, reformats it and forwards it to the orchestration service.
6. The orchestration service receives the response and reformats it. It then either calls another back-end proxy, or forwards the reformatted message to the calling service.

Below is the description of handling error scenarios or the “unhappy path”.

Following are the various types of errors that we have to contend with:

1. Errors occurring in the back-end applications: These errors occur when the back-end application is able to successfully receive the request message from the DataPower proxy, but is unable to process it. This condition results in DataPower receiving a fault/error message from the back-end application
2. Errors occurring in the DataPower back-end proxy: These errors occur when the back-end DataPower proxy receives the request message successfully but is unable to process it. This results in the back-end DataPower proxy returning a fault/error message to the orchestration service.
3. Errors occurring in the DataPower orchestration service: These errors occur when the DataPower orchestration service receives the request message successfully but is unable to process it. This results in the DataPower orchestration service returning a fault/error message to the front-end calling service.

With that in mind, following is my preferred approach for complex composite DataPower services:

Errors occurring in the back-end applications:
The orchestration service checks if the response from the back-end proxy is a soap:fault, and it if is then it might decide to rollback any of the previous calls (like an adduser or a insert DB row) with another call(like deleteuser or delete DB row).

You can use the dp:url extension to do this:

These errors come back as soap:Fault messages with HTTP Response code ‘500 Fail’. Generate a custom error message which includes the following fields (at least):

• Error Code service variable
• Error Details service variable
• Timestamp service variable
• MsgId/UUID response payload

Now, convert the HTTP Response Code from ‘500 Fail’ to ‘200 OK’:

We convert the HTTP Response Code from 500 to200 so that the orchestration service treats the soap:fault message as a valid response instead of an error.

Errors occurring in the back-end DataPower Proxies: Such errors can be caught and processed by using a combination of the On-Error action with the Error Rule in the back-end proxy’s policy.

The error rule can be configured to generate a custom fault/error message with HTTP response Code set to “200 OK”.

Errors occurring in the Orchestration service: Again, such errors can be caught and processed by using a combination of the On-Error action with the Error Rule in the orchestration service’s policy. We send back the error message with a HTTP Response code of “500 Fail” to the front-end calling service.

Prithvi Srinivasan is a Technology Manager at Prolifics and has extensive expertise in the IBM WebSphere suite of products. He has played a key role at several strategic clients by providing technical leadership. Prithvi has an extensive background in the design and development of SOA and Integration solutions, with a proven track record of consulting and architecting solutions for several industry verticals like Banking, Finance, Retail, Insurance, HealthCare and Technology.