When we integrate multiple applications using ESB, it is common requirement that we might need to call multiple services from a particular operation in our ESB application. And often, the calls are independent of other calls and in these cases it is expected that ESB layer call providers in an asynchronous manner to cut down the processing time. Although WebSphere Integration Developer came with mediation primitives for aggregating multiple responses, there was no (easy?) way that one could make asynchronous calls (parallel processing) and aggregate responses using Fan-Out/Fan-In and Service Invoke mediation primitives in WID 6.1.2 or prior versions (However, parallel processing and aggregation could be achieved using java code - using invokeAsync API - in Custom Mediation primitives). In these versions, one could only make multiple sync calls and aggregate responses using Fan-Out/Fan-In mediation primitives and Fan-Out/Fan-In provided a mechanism for looping.
Good news is that WID 6.2 has come up with features supporting parallel processing. Good thing about this is that if you are already using Fan-Out/Fan-In to make multiple sync calls using Service Invokes, it is very easy to change them to make async calls. Let’s see how to make service invokes run in asynchronous mode and aggregate responses of asynchronous calls within Fan-Out/Fan-In mediation primitives.
The following image shows my mediation flow implementation, where I have two Service Invoke mediation primitives enclosed within a set of Fan-Out/Fan-In primitives.
This is simple enough – out terminal of Fan-Out is connected to two Service Invokes – one calling an operation on ServiceA and other calling ServiceB. Fan-In aggregates response from both Service Invoke primitives. Let’s see the settings for Service Invoke mediation primitive to make asynchronous calls.
There is a new property added to Service Invoke named “Invocation Style”. You just need to select ‘Async’ from the drop down list to make Service Invoke make asynchronous call to the target provider. Also note that you need to set appropriate value to Async Timeout text box highlighted above. The response will be lost if this value set to a lower value that time taken by the service invoke to return response!
Let’s see settings for Fan-Out and Fan-In mediation primitives.
I have set Fan-Out out terminal to 'Fire once'. However, since I have wired the output terminal to two Service Invoke primitives, both providers are called and there are two responses to be aggregated. So in the properties window of Fan-In mediation primitive, I set a value 2 in “Fire output terminal when” text box. And this is the only option available when “Fire once” is selected in associated Fan-Out.
Let’s see another scenario, when you have an array of inputs, for example an array of ‘User’s to be created. In this case you might be calling same service multiple times – once for each element in array. In a similar case, you might be iterating through a set of inputs and calling different services based on a filter. In these cases the settings of Service Invoke primitives remain same. However, you need to set different properties for Fan-Out and Fan-In.
In Fan-Out primitive, I have specified a XPATH expression to iterate through the array of users. Out terminal will be fired for each User element in the input array. There are two radio buttons below this - these two are new properties of Fan-Out mediation primitive in WID 6.2. Please note that I have selected the radio button “Check for asynchronous responses after all messages have been fired”. This decides when to start collecting responses. And in properties of Fan-In, I have selected radio button “Fire output terminal when the associated Fan-Out primitive has iterated through all messages.” Alternatively you can set XPath expression to decide this or or set exact number of responses, if you know. In my case, out terminal is fired for each iteration as Fan-Out iterates through all messages, and corresponding responses are received.
Just a note - it seems that Fan-Out/Fan-In primitives in WID6.2 do not properly aggregate the responses from multiple synchronous calls, even though aggregation happens correctly for async calls. This was a working feature in WID 6.1.2, broken in WID 6.2 for some reason. There is a PMR for this and official fix should be available soon.
Good news is that WID 6.2 has come up with features supporting parallel processing. Good thing about this is that if you are already using Fan-Out/Fan-In to make multiple sync calls using Service Invokes, it is very easy to change them to make async calls. Let’s see how to make service invokes run in asynchronous mode and aggregate responses of asynchronous calls within Fan-Out/Fan-In mediation primitives.
The following image shows my mediation flow implementation, where I have two Service Invoke mediation primitives enclosed within a set of Fan-Out/Fan-In primitives.
This is simple enough – out terminal of Fan-Out is connected to two Service Invokes – one calling an operation on ServiceA and other calling ServiceB. Fan-In aggregates response from both Service Invoke primitives. Let’s see the settings for Service Invoke mediation primitive to make asynchronous calls.
There is a new property added to Service Invoke named “Invocation Style”. You just need to select ‘Async’ from the drop down list to make Service Invoke make asynchronous call to the target provider. Also note that you need to set appropriate value to Async Timeout text box highlighted above. The response will be lost if this value set to a lower value that time taken by the service invoke to return response!
Let’s see settings for Fan-Out and Fan-In mediation primitives.
I have set Fan-Out out terminal to 'Fire once'. However, since I have wired the output terminal to two Service Invoke primitives, both providers are called and there are two responses to be aggregated. So in the properties window of Fan-In mediation primitive, I set a value 2 in “Fire output terminal when” text box. And this is the only option available when “Fire once” is selected in associated Fan-Out.
Let’s see another scenario, when you have an array of inputs, for example an array of ‘User’s to be created. In this case you might be calling same service multiple times – once for each element in array. In a similar case, you might be iterating through a set of inputs and calling different services based on a filter. In these cases the settings of Service Invoke primitives remain same. However, you need to set different properties for Fan-Out and Fan-In.
In Fan-Out primitive, I have specified a XPATH expression to iterate through the array of users. Out terminal will be fired for each User element in the input array. There are two radio buttons below this - these two are new properties of Fan-Out mediation primitive in WID 6.2. Please note that I have selected the radio button “Check for asynchronous responses after all messages have been fired”. This decides when to start collecting responses. And in properties of Fan-In, I have selected radio button “Fire output terminal when the associated Fan-Out primitive has iterated through all messages.” Alternatively you can set XPath expression to decide this or or set exact number of responses, if you know. In my case, out terminal is fired for each iteration as Fan-Out iterates through all messages, and corresponding responses are received.
Just a note - it seems that Fan-Out/Fan-In primitives in WID6.2 do not properly aggregate the responses from multiple synchronous calls, even though aggregation happens correctly for async calls. This was a working feature in WID 6.1.2, broken in WID 6.2 for some reason. There is a PMR for this and official fix should be available soon.
Posts
