Harish's SOA Blog: Modeled & Unmodeled faults in WESB 6.1

In any service invocation, we often come across faults.These Faults can be from client side (seeking information which is not present in server or improper inputs) or from server side (server is down, unavailability of data or system failure) A service should handle these faults & give useful fault information to its caller.

These faults comes in two flavours : Modeled & UnModeled faults.

A Modeled fault is :

Explicitly defined for the operation in the WSDL interface.
When a service returns a modeled fault, the fault is propagated in the mediation flow from either the callout fault node, or from a service invoke primitive which one depends upon from where the service was invoked.
For each fault defined on the operation there is a terminal with a message type specific to that fault.
The fault data is carried in the body of the SMO.

An Unmodeled fault is :

Not defined in the WSDL.
It is propagated back to the flow through either the callout response node or the service invoke primitive, again according to how the service was originally invoked.
Because there is no fault defined in the WSDL, there can not be a unique terminal, and therefore the fault is propagated through the fail terminal.
The fault data is populated in the context/failInfo/failureString element, which is in the context of the SMO.
The unmodeled fault will only be propagated back to the flow once the retry count (property for a service invoke or callout node) has been exhausted.

Handling of unmodeled faults :

We can very well handle these unmodeled faults in the flow the way we want, there must be flow logic wired from the fail terminal that performs our application specific requirements for fault handling (for ex : Log the event & stop the flow).
The alternative is to leave the fail terminal unwired, in which case a mediation exception is thrown and the flow is terminated.

Contents of the SMO when an unmodeled fault is returned to the flow :

When being returned from a service invoke : Original body of the original message is contained in the fault message.
When propagated through a callout response node : Original body content might not be present. (controlled by a property setting; property Name :Included the original request message)
The three context (transient, shared and correlation) that we configure for our flow. In the case of the service invoke, all three contain the same content as the original request message. However, in the case of the callout response node, only the correlation context contains the content from the original request.