Oracle Fusion Middleware 11g (ofm11g) on Centos 5

Because of a little illness Lucas was a bit faster with the publish of his article but i decided to still post it on my blog. In the new Fusion 11g, Oracle added a new extension to the bpel language for the coordination of master- and detail processes. With this add on it is possible to relate a master process with his detail processes and give signals to each other when to start and when parts are finished. Let’s start with building something We created a new composite application and added 3 bpel processes to it. The first process is the master process and this one will invoke 2 detail processes. The idea is to let both detail process only get started when they receive a ‘signal’ from the master processes. If they receive it, they’ll execute their own logic and when either finished or at some point they want to communicate back to the master process, they give a ‘signal’ back. In the master process, after the the receive add the first signal 1 <bpelx:signal name="doDetail1" label="doDetail1" to="details"/> This will give the first detail process a signal so it will be able to receive Now we need to invoke the first detail process 1 <invoke name="invokeDetail" 2         inputVariable="invokeDetail_process_InputVariable" 3         partnerLink="MyDetail.mydetail_client" portType="ns1:MyDetail" 4         operation="process" 5         bpelx:detailLabel="detailProcessComplete1" 6         bpelx:invokeAsDetail="true"> Two things in here are needed. The first is the bpelx:invokeAsDetail=”true” and the second is the bpelx:detailLabel=”detailProcessComplete1″ The last property is used in cases in which we have multiple detail processes and the signals need to get correlated back with the master process. Now lets see what is needed in the first detail process to receive the signal and eventually send one back to the master process. The first activity after the receive is the receive signal 1 <bpelx:receiveSignal name="WaitOnSignalFromMaster" 2                      label="doDetail1" from="master"/> This will receive the signal from its master process and after that will carry on. Without the signal the detail process won’t get started. So you will only be able to trigger this detail/sub process from it’s master process. After receiving the signal the detail process can execute some logic and eventually send back the signal to the master process 1 <bpelx:signal name="ReplyBackToMaster" 2               label="detailProcessComplete1" to="master"/> In the master process we use the receiveSignal activity to receive it back from the detail process and go on with the process. 1 <bpelx:receiveSignal name="waitForDetailProcess1" 2                      label="detailProcessComplete1" from="details"/> The same code is needed to invoke the second detail process. It’s up to you to decide wether or not the second detail process can run parallel to the first one. If this is not the case we need to wait on the receiveSignal from the first detail process before we can start the second one. If both processes can execute their logic and eventually send the signal back we can also receive both signals on the end of the master process. If both signals are receive we can do the callback because the whole process (master and all his details have been completed). And in this case we can invoke the detail processes like oneway processes, but still inform the master process about the state of all these oneway (long running?) processes. At the end aggregate all the signals and do the callback or some other activity which is needed as soon all the detail processes reported back. Testcase1 What will happen if we remove one of the receiveSignals from the Master process. the master process will wait on the receivesignal activity until it receveid it. Testcase2 What will happen when we do not send the signal from the master process to the detail process but leave the receiveSignal in the detail process. The master process will wait on the receiveSignal from detail process1. Since the invoke of the both detail processes are oneway and we do the ‘check’ on the receiveSignals at the end, detail process1 will just complete and send the signal back to the master process. After this the master process will keep on waiting on the signal from detail process1. Testcase3, when all just works Eventually the flow of the master process can look like this. In here i placed the receiveSignals to the end of the process. You can also place them after the invokes of the detail processes, so you’re sure they will wait on each other.