Parallel Path Execution in WebSphere ESB 7

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 v7 actually give you an error message if you setup parallel processing but do not configure the transaction boundary correctly.

  1. #1 by raj on September 23, 2011 - 2:19 am

    Thanks for the advice, it was really useful for my implementation

  2. #2 by RY on January 6, 2012 - 5:35 pm

    “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).”

    Quick question – Does the calls ServiceInvoke1 & ServiceInvoke3 happen in parallel or sequential? If it is sequential, then the only value addition is for aggregation as we don’t have parallelism. Thanks in advance.

  3. #3 by jomsky on July 2, 2012 - 7:03 am

    Do have any suggestions on how to implement parallel calls to different services without using fan in/out primitive? thank you.

  4. #4 by Ramesh on November 21, 2013 - 11:12 am

    when to use fire output terminal with original input messgae : Once

    Can I use Fan out and Fan the above flow .If assume.
    I do not have below flow in the above Scenario
    XSL3 ->ServiceInvoke3 ->XS4 ->ServiceInvoke4

    Still CAN I USE FAN IN & FAN OUT.?
    If i do so.. Will it throw any exception or it will run as useual.
    Since i got CR change .. this kind of requirement.Plese let me know ASAP.tHANKS

  5. #5 by Stuart Smith on November 26, 2013 - 1:25 pm

    From what I understand you are asking if it is possible to create a flow that basically only has the top branch of the diagram and not the bottom (XSL1 -> ServiceInvoke1 -> XSL2 -> ServiceInvoke2) but still keep the ‘FanOut’ and ‘FanIn’ primitives as shown.

    I believe you could do this without throwing an exception, the problem is that you are doing more work than is required. The only role of ‘FanOut’ and ‘FanIn’ is to split into parallel paths so if you don’t have parallel paths you can just link the chain of primitives you want directly in the flow.

    Service Invocation primitives can be set to invoke asynchronously without needing ‘FanOut’ or ‘FanIn’ involved.

  6. #6 by Kiran on January 13, 2014 - 2:57 am

    Hi, Thanks for your post on FanIn and FanOut primitives. My question is, how FanIn works, when any of the flow gives an exception(for example, when serviceInvoke4)

  7. #7 by Stuart Smith on February 17, 2014 - 2:08 pm

    An exception would trigger the error terminal on the mediation primitive that causes the error. If you have this wired up to other primitives those would execute and could handle the error in some way.

    You can configure the “incomplete” terminal of the FanIn primitive so that it fires on a timeout. This could cause some logic to execute when one of the branches does not return a normal response.

(will not be published)