For example, if you have BPEL process 1 synchronously invoking BPEL process 2, you would be able to trace the flow in the consoles on both 10g and 11g. This way, you have end-to-end visibility into your synchronous flow.
However, BPEL process 1 may asynchronously flow into BPEL process 2 by way of an AQ or JMS queue. In this case, the flow is broken, and the 10g console has no way to automatically correlate the instances to allow you to easily trace the flow.
As you can see in the Flow Trace window below, BPEL process 1 (InvokeMemberABCS) produces a message into some JMS queue by way of the JMS Adapter (see 'AddCustomerToJMS'). This message is then asynchronously consumed by BPEL process 2 (MemberABCS) via an inbound JMS Adapter (see 'RetrieveMemberDataJMS'). As you can see here, we are able to see the end-to-end flow within the same window.
This is a simple, yet incredibly valuable addition that will definitely ease development and production support for your SOA implementations.
Applicable Versions:
- Oracle SOA Suite 11g (11.1.1.x)
2 comments:
Thanks for the idea of it but how about if i wanna trace this in the OSB services itself. Did OSB provided any kind of tracing function?
Hi Ahmad, I am having a wierd issue because of this ECID I guess, I am getting multiple processes in a single flow trace where they are not really related. Resulting in confusion instead of helping us.
It happens in my Error handler when I am trying to check what happened and its showing it alongside other messages which have no correlation to this process at all, On investigation I found that the 2 have the same ECID how wierd....
Post a Comment