Modelling osb error handling for synchronous services

Recently one of the queries I got was regarding the OSB error handling, how errors should be handled. The error handling will differ based on the communication pattern, whether the call is synchronous or asynchronous.

If the services are modeled to be synchronous it will be always useful to return a consistent error structure with a minimum of the error occurring service information, unique id w.r.t message so as to track it, unique error code, summary/details of the error. This needs to be defined properly and laid out before we start on a project. If the services are more asynchronous in nature, then it makes sense to have a common Error logging/handling/auditing framework which will receive the errors and based on any business rules can persist /notify the errors. In both approaches it is mandatory to define the Error message structure. The asynchronous can have more information whereas synchronous can be a subset of this since the caller or consumer need not be given a lot of unnecessary information related to error. The synchronous response should be more formatted to be humanly readable and no stack trace.

  In case of OSB there can be multiple proxies and you will need to control the response message flow and track it. Instead of having multiple reply points from error catch blocks it will be better to have multiple catch blocks which will Raise an Error with the error payload populated into the body. The Global catch block will do a reply with success to the caller Proxy with the body

OSB Implementation

The different stages in OSB should be segregated and defined properly. And each stage should be having Error Handler-catch block. In each catch block

Catch the error globally and Reply with success

An error should contain minimum of below listed information so that it helps in identifying/tracking the error.

ResponseStatus: "-1"

ErrorSource: Atomic service

MessageDate: "2013-08-08T15:48:13.013-07:00",

ServiceName: "Validation Service",

OperationName: ": validateRequest",

Code: "VALIDATION_ERROR-ERR103",

Summary: "Validation Failure ",

Details: "BEA-382515: oops!!! Duplicate Request Signature",

SeverityLevel: "1"

If we are having a Gateway architecture then we can evaluate the error response at the gateway, see the error code and based on that can work out appropriate error handling mechanisms.