(WMB) SOAP Vs HTTP Nodes

This post talks about the preferences of using one type of nodes over others. During the course of my experience in using these nodes, I had several confusions regarding when to use what & what is the main difference among these nodes.


We can use SOAP nodes with SOAP message domain OR HTTP transport nodes with XMLNSC message domain to implement Web Services. Several advantages exist if we use SOAP nodes :
  • Support for WS-Addressing, WS-Security and SOAP headers.
  • A common SOAP logical tree format, independent of the bitstream format.
  • Runtime checking against WSDL.
  • Automatic processing of SOAP with Attachments (SwA). (Although the HTTP nodes can process SwA messages, we must use the MIME message domain)
  • Automatic processing of Message Transmission Optimization Mechanism (MTOM).


Cases where it might be better to use HTTP nodes include:
  • Message flows that interact with Web services that use different standards, such as REST or XML-RPC. (We don't have a WSDL definition)
  • Message flow that never use WS-Addressing, WS-Security, SwA, or MTOM.
MTOM :

  • It is the W3C Message Transmission Optimization Mechanism, a method of efficiently sending binary data to and from Web services.
  • The efficiency claims of MTOM only refers to the size of the messages sent across the wire. 
  • Since SOAP uses XML, any binary data in the SOAP message will have to be encoded as text. This is usually done using Base64 encoding which increases the size of the binary data by 33%. 
  • MTOM provides a way to send the binary data in its original binary form, avoiding any increase in size due to encoding it in text. 
  • MTOM does not address the efficiency of serializing or deserializing the messages.

WebService scenario in WMB V7.0

This post elaborates a particulate scenario where Aggregation is being implemented using different web service nodes ( SOAP & HTTP Nodes)


Background :
Aggregation is the generation and fan-out of related requests that are derived from a single input message. It is also the fan-in of the corresponding replies to produce a single aggregated reply message.

Aggregation is an advanced form of message routing. With aggregation, a request message is received, and multiple new different request messages are generated. Each new message is routed to its  destination using a request-reply interaction.

Aggregation Nodes:
  • AggregateControl, AggregateRequest nodes (Used in Fan-Out to broadcast the request message to multiple destinations 
  • AggregateReply (Used in Fan-In to collect responses)
  • ‘Aggregate Name’ property of AggregateControl & AggregateReply nodes should be the same.
  • ‘Folder Name’ property of the AggregateRequest node decide how the input will be structured  in Fan-Out flow.
  • The AggregateReply node creates a folder in the combined message tree below Root, called ComIbmAggregateReplyBody. Below this folder, the node creates a number of subfolders using the names that you set in the AggregateRequest nodes. These subfolders are populated with the associated reply messages.

Broker internally maintains aggregation state in following queues:
  • SYSTEM.BROKER.AGGR.REQUEST
  • SYSTEM.BROKER.AGGR.CONTROL
  • SYSTEM.BROKER.AGGR.REPLY
  • SYSTEM.BROKER.AGGR.UNKNOWN
  • SYSTEM.BROKER.AGGR.TIMEOUT


Core Aggregation Flows :


Fan Out Flow :


Fan In Flow :

Input :
      <myms:SaleEnvelope  xmlns:myms="http://tempuri.org/MyMS">
         <myms:SaleList>
            <myms:Invoice>
               <myms:Initial>A</myms:Initial>
               <myms:Balance>B</myms:Balance>
               <myms:Currency>C</myms:Currency>
            </myms:Invoice>
         </myms:SaleList>
       <myms:SaleList>
            <myms:Invoice>
               <myms:Initial>A1</myms:Initial>
               <myms:Balance>B1</myms:Balance>
               <myms:Currency>C1</myms:Currency>
            </myms:Invoice>
         </myms:SaleList>
      </myms:SaleEnvelope>


Output :
<ABC>
 <AG2>
  <SaleEnvelope>
   <SaleList>
    <Invoice xmlns:NS1="http://tempuri.org/MyMS">
     <Initial>a</Initial>
     <Balance>60.16</Balance>
     <Currency>Dollar</Currency>
    </Invoice>
   </SaleList>
  </SaleEnvelope>
 </AG2>
 <AG1>
  <SaleEnvelope>
   <SaleList>
    <Invoice xmlns:NS1="http://tempuri.org/MyMS">
     <Initial>S</Initial>
     <Balance>07.55</Balance>
     <Currency>Rupees</Currency>
    </Invoice>
   </SaleList>
  </SaleEnvelope>
 </AG1>
</ABC>


Wrapper (Web Service) Flows :


The same flow can be called by HTTPInput Node or SOAPInput Node.


HTTPCaller Flow :



Input & Output for the above flow would be same as normal flow mentioned above.

Different ways of calling HTTPInput node (Web Service implemented using HTTP nodes) :
  • nettool (Its a tool ; Need to give the URL & input xml)
  • Another message flow which uses HTTPRequest node to call HTTPCaller flow.
  • Java : Can be called through plain Java code; following code sample is a standalone Java program to call HTTPCaller flow.
Code :
import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.FileReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;

public class HTTPCaller{
public static void main(String[] args) throws Exception {
// Default port for HTTPInput node is 7080
// Path suffix for URL :/path/to/aggrservice/
URL url = new URL("http://localhost:7080/path/to/aggrservice/");
URLConnection urlConn = url.openConnection();
FileReader fileReader = new FileReader("C://Input.xml"); // Input XML (It is same as above input xml)
urlConn.setDoOutput(true);
InputStreamReader inStream = null;
BufferedReader buff = null;
String nextLine;
String inputLine;
BufferedReader in = new BufferedReader(fileReader);
DataOutputStream printout = new DataOutputStream(urlConn.getOutputStream());
while ((inputLine = in.readLine()) != null){
printout.writeBytes(inputLine);
}
printout.flush();
printout.close();

// Get Response data.
inStream = new InputStreamReader(urlConn.getInputStream());
buff = new BufferedReader(inStream);
while (true) {
nextLine = buff.readLine();
if (nextLine != null) {
System.out.println(nextLine);
} else {
break;
}
}
in.close();
}
}

SOAPCaller Flow :



Input :
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:myms="http://tempuri.org/MyMS">
   <soapenv:Header/>
   <soapenv:Body>
      <myms:SaleEnvelope>
          <myms:SaleList>
            <myms:Invoice>
               <myms:Initial>A</myms:Initial>
               <myms:Balance>B</myms:Balance>
               <myms:Currency>C</myms:Currency>
            </myms:Invoice>
         </myms:SaleList>
         <myms:SaleList>
            <myms:Invoice>
               <myms:Initial>A1</myms:Initial>
               <myms:Balance>B1</myms:Balance>
               <myms:Currency>C1</myms:Currency>
            </myms:Invoice>
         </myms:SaleList>
      </myms:SaleEnvelope>
   </soapenv:Body>
</soapenv:Envelope>


Output :
<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <ABC>
         <AG1>
            <SaleEnvelope>
               <SaleList>
                  <NS1:Invoice xmlns:NS1="http://tempuri.org/MyMS">
                     <NS1:Initial>A</NS1:Initial>
                     <NS1:Balance>B</NS1:Balance>
                     <NS1:Currency>C</NS1:Currency>
                  </NS1:Invoice>
               </SaleList>
            </SaleEnvelope>
         </AG1>
         <AG2>
            <SaleEnvelope>
               <SaleList>
                  <NS1:Invoice xmlns:NS1="http://tempuri.org/MyMS">
                     <NS1:Initial>A1</NS1:Initial>
                     <NS1:Balance>B1</NS1:Balance>
                     <NS1:Currency>C1</NS1:Currency>
                  </NS1:Invoice>
               </SaleList>
            </SaleEnvelope>
         </AG2>
      </ABC>
   </soapenv:Body>
</soapenv:Envelope>



Different ways of calling SOAPInput node (Web Service implemented using SOAP nodes) :
// Default port for SOAPInput node is 7800
// Path suffix for URL : /MyMSSOAP_HTTP_Service ; so the URL would be http://localhost:7800/MyMSSOAP_HTTP_Service?wsdl

(WMB) TryCatch Sample

This post shows how to use Try Catch node along with Throw node.
Also I am providing few details of ExceptionList tree, this tree has correlation name as ExceptionList; It it initially empty & is only populated if an exception occurs during message flow processing.
We can access the ExceptionList tree in Compute, Database, and Filter nodes, and we can update it in a Compute node. We must use the appropriate correlation name; ExceptionList for a Database or Filter node, and InputExceptionList for a Compute node.

Below example shows the usage of Try Catch & Throw nodes & also how to manipulate the ExceptionList in compute node using the InputExceptionList correlation name.

Message Flow elaborating Try Catch & ExceptionList processing 
Note : "The Form Error Details" compute node should have following property:
Basic Tab -> Compute mode -> Exception and Message.


If input for IN (MQInput) Node is :
<Request><No>0</No></Request>
Output in Catch (MQOutput) Node is :
<ErrorDetails>
 <Text>Throwing exception from throw node.</Text>
 <Number>1001</Number>
 <FlowName.NodeName>Sample.Throw</FlowName.NodeName>
</ErrorDetails>



If input for IN (MQInput) Node is :
<Request><No>10</No></Request>
Output in Catch (MQOutput) Node is :
<ErrorDetails>
 <Number>500</Number>
 <FlowName.NodeName>Sample.Validation</FlowName.NodeName>
 <Text>Request.No is Invalid</Text>
</ErrorDetails>

(WMB) Event Monitoring

A message flow can be configured at node level to emit monitoring events. A monitoring event is represented as a XML document that conforms to the monitoring event schema. Each event always contains the following information:
  • Source of the event (eventSourceAddress)
  • Name of the event (eventName)
  • Creation time (creationTime)
  • Correlation ID for events emitted by the same transaction or unit of work (localTransactionId,parentTransactionId, and globalTransactionId)
  • Details of the message flow (messageFlowData)
Optionally, a monitoring event can also contain the following information:
  • Application data extracted from the message (applicationData)
  • Part or all of the message bit stream (bitstream)

Event types :

You can configure a message flow to emit two types of events: Transaction events and terminal events.
There are three types of transaction events: start, end, and rollback. The transaction events are emitted only from input nodes such as MQInput and HTTPInput.
Terminal events are emitted from any terminal of any node.

Event output :
The monitoring event feature leverages the publish/subscribe (pub/sub) mechanism of Message Broker. Event messages are published to the specific topics, which can be registered by subscribing applications. The form of the topic name is: $SYS/Broker/<brokerName>/Monitoring/<executionGroupName>/<flowName>
We can subscribe to these event by following ways :
Using rfhutil tool


Here 
Broker Name : MYBROK
Execution Group Name : MYEG
Flow Name : MYFLOW
Subscription Queue Name : SUB.EVENT

Using a Message Flow :
This can be done by posting a  subscription request  to SYSTEM.BROKER.CONTROL.QUEUE queue.

Following is the esql code to create subscription request :  
  
BEGIN
CALL CopyEntireMessage();
SET OutputRoot.MQRFH2.psc.Command = 'RegSub';
SET OutputRoot.MQRFH2.psc.Topic = '$SYS/Broker/MYBRK/Monitoring/MYEG/MYFLOW';
SET OutputRoot.MQRFH2.psc.QName = 'SUB.EVENT';
SET OutputRoot.MQRFH2.psc.QMgrName = 'QM';
DECLARE ptr REFERENCE TO OutputRoot.MQRFH2;
DETACH ptr;
ATTACH ptr TO OutputRoot.MQMD AS NEXTSIBLING;
RETURN TRUE;

Enabling/Disabling the event sources :
By default, all of the configured events in a message flow are enabled but we have to activate the events. We can enable or disable these events by issuing following command
mqsichangeflowmonitoring MYBRK -e MYEG -f MYFlow  -s "Event_Src_address1,"Event_Src_address2" -i enable/disable

Activating/Inactivating the events :
mqsichangeflowmonitoring MYBRK -e MYEG -f MYFlow -c active/inactive

To report what are all event sources has been activated :
mqsireportflowmonitoring MYBRK -e MYEG -f MYFlow -a

Monitoring in IIB

(WMB) MQGet Example

This post only shows how to use this node & how output tree populates from input & result trees.
As we know MQGet node can be used anywhere in a message flow to store message in intermediate state & afterwords in another thread of flow we can aggregate this temporary result to form final output (Getting message by correl/message id..)


Following example illustrates how an intermediate message can be combined to incoming message to form final message.
First Flow : IN (MQInput) , TEMP (MQOutput)


Second Flow :  IN2 (MQInput), TEMP (MQGet), OUT (MQOutput)
Here the Compute node copies the message id of the incoming message to correlation id of output message, so that we can retrieve this intermediate message based on correlation id.
SET OutputRoot.MQMD.CorrelId  =  InputRoot.MQMD.MsgId;




Three different input for first flow is  : (Put in IN QUEUE)


<Project>PD1</Project> Say MsgId is (ABCXX)
<Project>PD2</Project> Say MsgId is (ABCYY)
<Project>PD3</Project> Say MsgId is (ABCZZ)


Same data is being put in TEMP (Output) queue after copying its MsgId to CorrelId.
Input to the second flow is  : (Put in IN2 QUEUE)

<Employee>
<NAME>HARISH</NAME>
<ProjectDetails>PD</ProjectDetails>
</Employee>
Note : Passed correlId is ABCXX (MsgId of PD1)


Now we can see the property of the MQGet (TEMP) node, Get by CorrelationID is checked; it means whatever message we put in TEMP queue , we can get based on correlId.





Next is to form the output tree from input & result trees.
The content of Employee.ProjectDetails will be replace by the content of Project (present in TEMP queue from first flow)




Final output will be :
<Employee>
 <NAME>HARISH</NAME>
 <ProjectDetails>PD1</ProjectDetails>
</Employee>

(WMB) Invoking EJB from Message Broker

There are certain requirements in which we might need to call EJB from Message broker, We can achieve this by making use of Java Compute node in a message flow.


Run time platform for both the components (EJB & Message Flow) are different; (EJB deploys on WAS or WPS &  Message flow deploys on Broker). In real time when broker (Message flow) invokes EJB, all the required jars should be present in broker runtime.


Following document describes how to develop an EJB project & message flow along with all environment setup to be done to make it possible.


https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0ByotHxAO08TDNzVlMTRkOTUtZmI3ZS00ZDhmLThkMjEtOWRmNmRlNTg0MTBl&hl=en_US

(WMB) Messages

When we work with Message Broker toolkit, it is the 'Message' which flows between the nodes; These messages are nothing but the actual business data on which business logic works. This post explains how these message are processed between the nodes (The background picture of message processing)


Message Tree :
  • When a Message Flow gets any input message bit stream it gets converted into tree structure by parser/s (Logical Message Tree).
  • It contains business data, elements & structured sequence of bytes.
  • Once the manipulation is done it again converts into bit stream.
  • Logical tree is same as message but it is easier to work on.
  • The Message Flow nodes provide an interface to query, update, or create the content of the tree.
  • Logical properties along with the actual message required to convert from physical to logical format.(Serialization)
  • Physical properties along with the actual logical message required to convert from logical to physical format. (Deserialization)
To parse these logical structures, we need parser.

Parser :
  • Every parser is messages class(group) basis, Say for example we have a domain (group or set of different message types ie; fixed-length binary, delimited text, or XML),for this domain we require a parser.
  • When we create a message set, we specify which message domains the message set supports. This determines which parsers are used when we parse and write messages that are defined within that message set.So we have parser for each message domain.
Message Domain :
  • It is a property that can be set on an input node to indicate the type of message that the node expects to process, and selects the appropriate parser for the flow to use. Examples are XML and MRM.
  • The message domain identifies the parser that is used to parse and write instances of the message. The remaining parts of the message template, message set, message type, and physical format, are optional, and are used by model-driven parsers such as the MRM parser.
  • MRM -> Only one available message domain that converts any format to any format ( we need to define the format ie xml,cwf, TDS ...)

(WMB) Accessing Configurable Service using Java Compute in WMB V7.0


Configurable Services are typically runtime properties. We can use them to define properties that are related to external services on which the broker relies. Instead of defining properties on the node or message flow, we can create configurable services so that nodes and message flows can refer to them to find properties at run time. If we use this method, we can change the values of attributes for a configurable service on the broker, which then affects the behavior of a node or message flow without the need for redeployment.


This post shows how to use the CMP API in a JavaCompute node to query, set, create, and delete properties dynamically at run time in configurable services that we have defined with type UserDefined.


Java code :
Add the CMP JAR file install_dir/classes/ConfigManagerProxy.jar to the Java build path for the associated Java project.
Following imports are required for code :
  • import com.ibm.broker.javacompute.MbJavaComputeNode;
  • import com.ibm.broker.plugin.*;
  • import com.ibm.broker.config.proxy.*;


Main Code 


try{

BrokerProxy b = BrokerProxy.getLocalInstance();

//To ensure that the BrokerProxy object has been populated with data from the broker before we access the configurable service, Add the following code:
                
while(!b.hasBeenPopulatedByBroker()) {} 
                
//As we have defined the configurable service with type 'UserDefined'; Add following code:

ConfigurableService[] CS_set = b.getConfigurableServices("UserDefined"); 

System.out.println("Configurable Service Name :"+CS_set[0].getName()); 

System.out.println("Property [Prop1] : "+CS_set[0].getProperties().getProperty("Prop1"));

CS_set[0].setProperty("Prop2" , "Setting property"); //To set a property

CS_set[0].deleteProperty("Prop2"); //To delete a property

}
catch (Exception e)
{
e.printStackTrace();
}


Output :
Configurable Service Name :UD1
Property [Prop1]: Prop1_Value

Setting Configurable Service in MQ explorer

Some useful commands :

  • mqsireportproperties ECSBRK -c UserDefined -o AllReportableEntityNames -r //To report Configurable Service of type 'UserDefined '.
  • mqsicreateconfigurableservice ECSBRK -c UserDefined -o UD2 -n Prop3 -v Value3 //To create a Configurable Service.
  • mqsideleteconfigurableservice ECSBRK -c UserDefined -o UD2 //To delete
  • mqsichangeproperties ECSBRK -c UserDefined -o UD2 -n Prop4 -v Value4  // To add another property under same Configurable Service name UD2
  • mqsichangeproperties ECSBRK -c UserDefined -o UD2 -n Prop3 -v Value33 // To change the existing property value.

(WMB) Error handling

When we design any message flow, we often do not give more emphasis on error handling. Well as per my experience I found this error handling techniques & design principles more crucial than designing the happy path.
So here I am with few details on how to handle unhappy path in WMBV6.0 with information about the message flow error behavior.


Design Consideration
  • Connect the Failure terminal of any node to a sequence of nodes that processes the node's internal exception (the Failure flow).
  • Connect the Catch terminal of the input node or a TryCatch node to a sequence of nodes that processes exceptions that are generated beyond it (the Catch flow).
  • Insert one or more TryCatch nodes at specific points in the message flow to catch and process exceptions that are generated by the flow that is connected to the Try terminal.
  • Ensure that all messages that are received by an MQInput node are processed within a transaction or are not processed within a transaction.

Understanding the Flow Sequence

  • When an exception is detected within a node, the message and the exception information are propagated to the node's Failure terminal ( Diagnostic information is available in the ExceptionList). 
  • If the node does not have a Failure terminal or if it is not connected, the broker throws an exception and returns control to the closest previous node that can process the exception. This node can be a TryCatch node  (Root & LocalEnvironment are reset to the values they had before) or the MQInput node .
  • If the catch terminal of the MQInput node is connected, the message is propagated there (ExceptionList entries are available; Root & LocalEnvironment are reset to the values they had before).Otherwise if is not connected, the transactionality of the message is considered.
  • If the message is not transactional, the message is discarded. Otherwise , if it is transactional, the message is returned to the input queue, and it is read again, whereupon the backout count is checked.
  • If the backout count has not exceeded its threshold, the message is propagated to the output terminal of the MQInput node for reprocessing. Otherwise if it is exceeded & if the failure terminal of the MQInput node is connected then the message is propagated to that path. (Root is available but ExceptionList is empty)
  • If the failure terminal of the MQInput node is not connected, the message is put on an available queue, in order of preference; message is put in backout queue, if one is defined; otherwise in dead-letter queue, if one is defined. If the message cannot be put on either of these queues, it remains on the input queue in a retry loop until the target queue clears.(It also records the error situation by writing errors to the local error log)

MQ Series Introduction

  • It is an IBM’s award winning middleware for commercial messaging and queuing.
  • The MQSeries products enable programs to communicate with each other across a network of unlike components, such as processors,subsystems, operating systems and communication protocols.
  • MQSeries programs use a consistent application program interface (API) across all platforms.
  • Message queuing is a method of program-to-program communication. Programs within an application communicate by writing and retrieving application-specific data (messages) to/from queues.
  • Messaging means that programs communicate with each other by sending data in messages and not by calling each other directly.
  • Queuing means that programs communicate through queues. Programs communicating through queues need not be executed concurrently.

A message consists of two parts:

  • Data that is sent from one program to another.
  • The message descriptor or message header.

Message Types

  • Datagram: A message containing information for which no response is expected.
  • Request: A message for which a reply is requested.
  • Reply: A reply to a request message.
  • Report: A message that describes an event such as the occurrence of an error or a confirmation on arrival or delivery.


MQM
  • The heart of MQSeries is the message queue manager (MQM), MQSeries’ run-time program.
  • Its job is to manage queues and messages for applications.
  • It provides the Message Queuing Interface (MQI) for communication with applications. Application programs invoke functions of the queue manager by issuing API calls.For example, the MQPUT API call puts a message on queue to be read by another program using the MQGET API call.

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.