Last updated on MARCH 08, 2017
Applies to:Oracle(R) BPEL Process Manager - Version: 10.1.3.1
Information in this document applies to any platform.
jms aq queue -> jms adapter -> (receive) Bpel process A -> sleep(20seconds) -> asynch invoke -> Bpel process B
and here are the usecase steps:
1. Through the JMS Adapter an instance of Process A dequeues a message from queue and an instance of "A" is created through the "receive" activity.
<receive createInstance="yes" id="BpRcv0" name="Receive_1"
At this point the process A will appear in the "Recover(Invokes) Tab" since the state of "A" is
2. Process "A" then does some work, which in the case of this application in the bug it does some transforms etc... but process "A" stays in the recovery tab until a dehydration point is reached.
*** Note if during this time someone recovers the instance then we will get a new seperate instance of "A->B" that duplicates the orginal instance. This is what the customer wants to avoid
3. Process "A" then does an asynchronous invoke of "B" which is a dehydration point and causes "A" to be removed from "Recover(Invokes) Tab", and so, we are safe since we cannot recover an inflight instance - the state changes at this point to 2.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms