A different interaction pattern

Question

Hi all,
I want to use a different interaction pattern in my flow. I want a synchronous flow which will synchronously return an immediate response (actually the instance id of itself) to the client but it will continue processing, possibly for a long time.
Is it all right to implement this flow with a normal synchronous flow? What other options do I have?
Thanks in advance..
Serkan

Answer 1

It's more about how and what calls are made. A proper asynchronous process only ever makes asynchronous calls to asynchronous processes. If a process makes a call to another process, and then waits for a callback 'invoke', instead of a 'reply', then the calling process is asynchronous.
To see why this is so, you need to know how BPEL PM manages processes. There's information in the manuals and I encourage you to search them out (try here: http://download-west.oracle.com/otndocs/products/bpel/bpeldev.pdf). In brief, if a process blocks, then it is asynchronous. A process blocks when it waits on an asynchronous callback (<receive> activity and <pick> activity), when it waits for a timer (<wait> activity), and probably something else as well.
As has been discussed, if a synchronous process calls another process, and that process is not a true synchronous process and waits too long before replying, then the caller will timeout waiting.
To answer another question, from my own experiments, a process is ended when it ends. It doesn't matter when it sends a <reply> or an <invoke> callback. I in fact have some processes which send two <invoke> callbacks, in a flow similar to yours.
In your desired flow, if you can guarantee that your process will respond with its instance id immediately, then you can return the instance id with a <reply> and have the caller receive as a synchronous call, but follow that by the caller waiting asynchronously for a final callback.
For example, the caller would be something like:
<invoke name="sub_process" inputVariable=".." outputVaribale="instanceID" .../>
// sub_process replies immediately with its instanceID. then waits a long time before replying a second time
<receive name="sub_process" variable="..."/>
the sub_process would be something like:
<receive>
<reply variable="instanceID"/>
// do other stuff
<invoke name="client"/>
If, however, you can't guarantee the instanceID being returned immediately. Replace the synch reply with an asynch callback, and then you'll have two asynch callbacks, and two <receive> activities in the caller.