SOASuite11g - Master Child process co-ordination using Signal

A Master BPEL process calling multiple child BPEL processes is a common solution implemented in case of complex workflows. The new SOA 11g coordination feature using signal offers a light wait solution to coordinate between master and multiple child processes.

In 10g, if a Master process has an asynchronous call to a child process, the only option to coordinate with master process was to use co-relation and wait back for response. The downside was that Master had to wait till the entire child process is finished and returns back the response even though it may be interested in only a few tasks within the process.

The SOA 11g signal feature allows Master process to signal to the child to start a specific set of tasks inside the child process. And similarly the child can signal to the Master that set of tasks that Master is interested has been completed and Master can continue with its processing. The child process will continue with its rest of the tasks. Signals are easier to implement and light-weight than implementing correlation set based solutions. The limitation of this feature is that it can be used only between Master and multiple Child processes and not with a Master process and multiple instances of a Child process. This is because labels can not be set dynamically and each signal pair (signal/receive signal) needs to have unique label. In case you try it you will get a Coordination fault saying duplicate label used.

The important steps you will have to do other than adding the Signal activities is to enable signaling by adding

bpelx:invokeAsDetail="true" property to your invoke activity 

In case you are having multiple invokes and Signals in the process then you need to link the Labels with the invoke activity. 

bpelx:detailLabel="childProcess1"

I was having a look at the implementation. It seems Signalling is implemented using the unique conversation ID of the process and labels. For correlating the master and child processes, it creates a coordination ID based on the unique process ID (cube instance key) and labels.