October 13 2011

There are many situations when building composite SOA services where we need to invoke several backend services in parallel for performance reasons.  Your first thought may be to use a flow activity in your BPEL process and this is correct, although to have the services truly invoked in parallel there are a few more steps that must be done.  A BPEL process is executed using a single thread, even when a flow is reached.  Each branch of the flow will then be executed sequentially.  The solution to this is to enable the nonBlockingInvoke property on your partner links.  This results in a dehydration point at each invoke activity and a new thread created to perform the invoke.  You can think of this as the same as having an invoke activity followed by a receive activity when calling an asynchronous service.  This will allow each of the invoke activities to occur in parallel, starting immediately one after anothe , but will also result in a dehydration point for each which needs to be considered as well.

One important point to note that was seen while building this sample project was that when all 3 branches of the flow were calling the same partner link/service reference only 2 were happening in parallel.  Once a 2nd partner link/service reference to the same service was added then all 3 branches executed successfully in parallel.

First, you should go ahead and implement your flow with as many branches as required each with a service invocation.  You should then have a process that looks similar to the one below. 

If you deploy your process as it is now each branch will be executed sequentially, resulting in a response time equal to the sum of all of the service invocation response times plus anything else your process is doing.  You can see this response time from the test page as well as the audit trail below.

To execute these invocations in parallel, double click on each partner link on the right side of the BPEL process.  Go to Properties and add a new property.  Select nonBlockingInvoke from the list and set the value to true.

This property will cause a new thread to be created for each invocation of the partner link, which will then callback to the main thread once it has completed, resulting in true parallelism.

If you now run your service again, you will see each of the invokes start at the same time.  You response time should now be closer to the response time of the slowest service you are invoking, plus anything else your process is doing.  You can see the process now took 10.9 sec and the longest invocation was set to take 10sec.  You can also see in the audit trail that all three invocations started concurrently at 6:05:34.

About the Author

Adam Desjardin

Adam DesJardin is the Chief Technology Officer for AVIO Consulting.  Adam focuses on technical strategy, standards and delivery both within AVIO and for our customers.  Prior to joining AVIO in 2007, Adam held various consulting and architecture positions at Fuego and BEA Systems where he developed and delivered process and service driven solutions.

Join the Conversation

December 22, 2015

I tried this. But my BPEL process just hung.

Could you please help?

Efren Villamagua
June 16, 2016

Thanks for this post. I searched for parallel processing on invoke web services in BPEL and it doesn't runned for me. I did not know the property 'nonBlockingInvoke '

Anu Indira
March 1, 2016

I have the same issue same as

Rajkiran Vajreshwari 

Anonymous
May 6, 2016

facing same issue. Setting nonBlockingInvoke the bpel is stuck at the invoke activing saying pending response. Is there any bug on this ?

George
December 7, 2016

Facing same "hanging" issue when using nonBlockingInvoke property.

Enter your first name. It will only be used to display with your comment.
Enter your email. This will be used to validate you as a real user but will NOT be displayed with the comment.
By submitting this form, you accept the Mollom privacy policy.