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.   

A typical example of modeled & Unmodeled Faults

For more info : http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.wpi_v6/wpswid/6.2/MediationFlows/WBPMv62_UnmodeledFaults/player.html
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.wpi_v6/wpswid/6.0.2/MediationLabs/WPIv602_ESB_UnModeledFaultsLab.pdf

Aggregation in WESB6.1 Introduction

WESB V6.1 introduces aggregation into mediation flow logic. First lets define what aggregation is; In simple terms, an inbound request may map into several individual outbound requests. The responses from these requests may be aggregated into a single response for the original request.

A common example is Airline service, where user searches for a flight from one city to another,now there could be many flights between given cities, Here the aggregation functionality calls different service providers (say Kingfisher,Indigo...) with the same set of inputs (say Date, from , to ...) & aggregates the outputs into one final output & then sends back to user.

So from user it would be only one call but the service provider (say MakeMyTrip for end user) calls different service providers.

Here is the diagrammatic representation of the mentioned scenario :

Fan-In, Fan-Out, Service-Invoke & MessageElementSetter Usage

For more info : http://www.ibm.com/developerworks/webservices/library/ws-websphereesb1/

Working PI

More info on FanIn/Out terminals:

FanOut Out terminals

out: Propagates the original message. When in iterate mode the out terminal is fired once for each occurrence of the repeating element specified, using an XPath. In iterate mode the value of the current element is placed in the FanOutContext.

noOccurrences: Propagates the original message. The noOccurrences terminal is only used in iterate mode, and is used if the input message does not contain any occurrences in the repeating element.


FanIn In terminals

in: Receives input messages until a decision point is reached. When a decision point is reached the out terminal is fired.

stop: Causes the incomplete output terminal to be fired, and this stops the associated Fan Out primitive from sending any more messages.

FanIn Out terminals

out: Propagates the updated message.

incomplete: Stops the associated Fan Out primitive from sending any more messages. Fired if the Stop terminal receives an input message; also fired if a timeout occurs.