Showing posts with label Fan-In. Show all posts
Showing posts with label Fan-In. Show all posts

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

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.