Friday, August 26, 2011

WPS: Parallel service Invocation

A mediation flow can run multiple branches in parallel but in a single thread. Basically, it uses the request with deferred response pattern. We will use an example to understand how things exactly work. But, before we get to that, let’s look at what we need to do to enable parallel processing. You will need to do two things:
1. For the Service Invoke primitives in the aggregation block, set the Invocation Style property to Async.


2. For the Fan Out primitive, choose Check for asynchronous responses after all messages have been fired. The Fan Out has to be in iteration mode for you to be able to choose that option.





Now, let’s examine an example.
 


Here, for all Service Invoke primitives, Invocation Style has been set to Async. For the Fan Out, Check for asynchronous responses after all messages have been fired has been selected.
The flow will perform as follows. First ServiceInvoke1 will be called immediately followed by ServiceInvoke3 (actually, the exact order of their invocation can not be determined and does not really matter). System will not wait for response from ServiceInvoke1 before ServiceInvoke3 is executed.
Since there are primitives left to be executed in both branches, the flow will then go to wait for responses to come back from the two already executed operations. This wait in the middle of the paths can not be avoided since the subsequent primitives may depend upon the output of the executed operations. After ServiceInvoke1 and ServiceInvoke3 return output back, system will then execute XSL4 and ServiceInvoke4. Without waiting for response from ServiceInvoke4, system will execute XSL2 and ServiceInvoke2. System will then wait for the responses to come back from these two Service Invoke primitives.

A Note About Deadlock

In the example above, request is sent but the system does not wait for a response. You need to be careful about the transaction boundary. Let us say that a request is sent by posting a message in a JMS queue. By default, the message will be actually posted if the transaction of the mediation flow commits. If the flow waits for a response, that will never come since the transaction is still active and the request message never went out in the first place. Long story short, you will have to post the request message in a separate transaction from the main transaction of the message flow. To do that, select the service reference of the mediation flow in the assembly diagram. Then set the Asynchronous invocation qualifier to Call.



WID actually give you an error message if you setup parallel processing but do not configure the transaction boundary correctly.


WPS: Static Service GateWay In WPS 6.2


1 Introduction


This integration aims to send unstructured data(any format) to specified structured target and send it to target using service gateway pattern.

2       What is Service GateWay:



A service gateway acts as a proxy to a different services by providing a single entry point for incoming requests. All service requesters interact with single endpoint address.

       The gateway is responsible for performing common operation on every message and routing the request to the correct service provider.    


The gateway is used primarily as an intermediary between a service requestor and a service provider. To make any service provider available to service requestors, a gateway administrator creates a gateway service.
Administrators can expose gateway services on one or more gateway channels, each representing a particular data format and protocol used to access the gateway service


3 Service Gateway Patterns

       Dynamic Service Gateway (body agnostic) is a Gateway pattern that only modifies the message header information, in this the endpoint address is determined at runtime.

Static Service Gateway (body aware) is a Gateway pattern that modifies the information contained in the body and the header of a message. In a static service gateway, the endpoint address is known when the message enters the gateway. 

Static Service GateWay : WebSphere Integration Developer provides a pattern that is a fast path to generate a service gateway, along with all the required artifacts. In a static service gateway, the endpoint address of the service provider is known before the message enters the gateway. The mediation flow typically modifies the information contained in the body and header of a message.

4 Creation of Webservice :

Static Service Gateway Creation For MQ
Step 1 : Create Service Gateway new --> project --> serviceGateway
Step 2: Provide Gateway Name
Step 3 : Select Static for Static Service Gateway
Step 4: Add Target Interfaces that is service providers.


Step 5 : Select Transport Protocol here we used MQ




Step 6: It generates a service gateway Skeleton

Now, In MQ Export set end-point configuration in properties tab, like queue manger and queue name e.t.c. Similarly MQ Import also.

5 Target BO Structure

1 Customer BO


2 Item BO  


7 Inteface Structure
1 Customer Interface : IF_CustomerData


2 Item Interface : IF_ ItemDetails

 


8  Extracting Correlation ID:

byte[] correlId =
smo.getDataObject("headers").getDataObject("MQHeader").getDataObject("md").getBytes("CorrelId");
String targettype = new String(correlId);
targettype = targettype.trim().toUpperCase();

Route the data using this target type.
1 Data Handler Configuration For XMLSending unstructured data from queue and mq export takes the message as JMSTextBody.
<JMSTextBody><value>input message</value></JMSTextBody>

We are sending this value content to the data handler.


















Set the out terminal for dataHandler:
Target Bo is generated by the DataHandler.

Test Scenario
  • To test this flow we need to test it we are able to give fixed-width data and xml data. 
  • Target Type is Customer for XML data, Item for fixed width data 
  • Put test message file in source MQ and provide correlation id as “xml”. 
  • Based on correlation id it will route to xml data Handler to serialize the input as xml data and place it into the target queue. 
xmlinput:

 
  •  Put test message file in source MQ and provide correlation id as “fw”. 
Input:
 
  • Based on correlation id it will route to fixed width data Handler and it converted input data to specified target BO and place it into thetarget queue