[null, {"document_url": "http://blog.raastech.com/2008/10/behavior-of-bpel-processes-in-bpel_12.html", "unformatted_src": "http://4.bp.blogspot.com/_qV5AglOGTr8/SRuwWMPmnBI/AAAAAAAAAG8/uq0LtSA5a3U/s400/bpel_failover_1.jpg", "src": "http://4.bp.blogspot.com/_qV5AglOGTr8/SRuwWMPmnBI/AAAAAAAAAG8/uq0LtSA5a3U/s400/bpel_failover_1.jpg", "formatted_filename": "bpel failover"}, null, {"document_url": "http://blog.raastech.com/2008/10/behavior-of-bpel-processes-in-bpel_12.html", "unformatted_src": "http://3.bp.blogspot.com/_qV5AglOGTr8/SRuw56h2rRI/AAAAAAAAAHU/7nfcuZ8FEhA/s400/bpel_failover_2.jpg", "src": "http://3.bp.blogspot.com/_qV5AglOGTr8/SRuw56h2rRI/AAAAAAAAAHU/7nfcuZ8FEhA/s400/bpel_failover_2.jpg", "formatted_filename": "bpel failover"}, {"document_url": "http://blog.raastech.com/2008/10/behavior-of-bpel-processes-in-bpel_12.html", "unformatted_src": "http://4.bp.blogspot.com/_qV5AglOGTr8/SRuw6JdCjfI/AAAAAAAAAHc/Ch8KQ3IETX8/s400/bpel_failover_3.jpg", "src": "http://4.bp.blogspot.com/_qV5AglOGTr8/SRuw6JdCjfI/AAAAAAAAAHc/Ch8KQ3IETX8/s400/bpel_failover_3.jpg", "formatted_filename": "bpel failover"}, null, null, null, null, null, null, null, null, null, null, null, null, null, {"document_url": "http://blog.raastech.com/2008/10/behavior-of-bpel-processes-in-bpel_12.html", "unformatted_src": "https://lh5.googleusercontent.com/-ZuB08NPrK6w/Uwu42TXTwOI/AAAAAAAAGXg/_y_pzlht-TM/w102-h137-no/harold.png", "src": "https://lh5.googleusercontent.com/-ZuB08NPrK6w/Uwu42TXTwOI/AAAAAAAAGXg/_y_pzlht-TM/w102-h137-no/harold.png", "formatted_filename": "harold"}, null, null, null, null, null, null, null, null, null, null, null]

Behavior of BPEL processes in a BPEL Process Manager cluster

This post will move permanently to here: http://blog.ipnweb.com/2008/10/behavior-of-bpel-processes-in-bpel.html

For one of my customers, I was involved in extensive high availability testing of an Oracle SOA Suite 10g (10.1.3.3) cluster in order to determine the behaviour of BPEL processes during failover of BPEL Process Manager.

Essentially, various scenarios were designed, configured, and tested. The various failover tests included:

Today, I will be briefly describing test cases 2 and 7.

Test Case 2: Asynchronous Transactions

This scenario is simple: An external client invokes an asynchronous BPEL process.

If the asynchronous BPEL process is in-flight on the first node and that node crashes (e.g., OC4J_SOA dies), the process is automatically resumed on the second container and runs successfully to completion. Since no response is expected by the client, operations resume normally. Test Case 7: Invoke Internal Asynchronous Callback Service from External Client

This scenario is somewhat complicated: An external client synchronously invokes a BPEL process which in turn invokes another asynchronous BPEL process.

In normal operations, one of the following occurs when the callback is received successfully by the first BPEL process:

Therefore, this scenario has a success rate of (100 – (100 / # of OC4J containers in cluster))% during normal operations.

The diagrams below detailed the following: gg said...

Hi Ahmed,

We have a process that is almost similar to TestCase:7, when it was deployed on a cluster, consumers were not getting response some times and they were timed out..so we decided not to deploy this process in a clustered environment and we raised an SR with Oracle for a solution..i am just wondering if you have found any solution for this..would appreciate your input.


January 3, 2009 at 11:28 AM 

The process will finish execution in all cases, but the client will either receive a response or it will time out, as you have been experiencing.

Unfortunately, the only recommendation is not to use asynchronous callback for process development in a clustered environment.

January 6, 2009 at 7:45 PM Liviu Florin said...

We faced the same issue, but managed to solve it by doing the callback to the actual node where ohs thread is still waiting.

There are few steps:

- declare variable

variable name="replyTo" messageType="ns1:WSAReplyToHeader"/

where ns1 is the namespace for Async partnerlink. It should not matter which one, as the type is the same.

- assigned values to the variable. Make sure the Address contains partnerlink and role of the requester

- use the variable when doing the invoke

invoke name="Invoke_NoFeeProvider"

- modify bpel.xml to contain

property name="optSoapShortcut"

for the partnerlink of async process.

- modify mod_oc4j.conf to enable local affinity when apache calls oc4j.

Oc4jSet StatusUri /oc4j-status
Oc4jSelectMethod roundrobin:local

March 11, 2009 at 3:31 AM 
That should definitely work, as long as OHS is routing to a single OC4J.

Thanks Liviu!

March 16, 2009 at 11:24 AM 
Thanks for this interesting and helpful post though I read it only now(during 11g). I'm interested in knowing the test results for scenario 5 & 6, could you please post them?

July 7, 2011 at 11:12 AM 
This is a great thread. We have the same issue in our clustered 10g environment. We got around it by setting the soapCallbackUrl to the local server name in each node's bpel\...\collaxa-config.xml. this ensures that the righ node will receive the callback. Obviously this limit's the HA benefits in pure Async flows.
We were told that this will not work in 11g, and if you want a Sync service to call Async services, you'll need to do it in OSB. Anyone aware of any other solutions? This is a very popular pattern in our environment and one of the key reasons we purchased SOA 10g.

August 4, 2011 at 10:39 AM sambasiva sura said...

Hi team,
I am facing Test Case 2: Asynchronous Transactions .Actually i am call one Asynchronous process into another Asynchronous process and i am not getting response from same node1.Could please tell me how to i ensure call back to same node.

March 21, 2012 at 1:42 AM 
I am using 11g environment

March 21, 2012 at 1:43 AM Ahmed Aboulnaga said...

Please note that this blog post has been permanently moved to:


I posted my response there.

March 21, 2012 at 9:55 AM