A common problem in SOA Suite and one that we have a variety of tools to solve, is the need to obtain a reference or some kind of tracking id of the process (or processes) that processed some activity, for use in an external system. For example, I have a composite that processes orders. I wish to know which composite instance relates to which order in my order monitoring system. To do so, I would need to obtain some sort of reference identity within the composite flow that I can pass to my order monitoring system.
We offer the ComponentID, the CompositeID and the ECID, all of which could be used to fulfill this role. Each of these has a different scope.
Each of these values could be used legitimately as a reference value from external systems. Traditionally, the "BPEL Process ID" from earlier versions, which most analogously maps to the ComponentID, was used for this reference value. For 11g, however, you should really only consider the ECID. There are various reasons why.
When auditing is turned to "OFF", CompositeID is effectively null, as there is no "tracking composite" generated when auditing is disabled. Calls to ora:getCompositeInstanceId will return null, and trying to assign from the property tracking.compositeInstanceId will again generate a null reference. This means that code that, for example, assigned from ora:getCompositeId to a process variable, will find they will fail with a "selection failure" when auditing is turned off. Clearly this is undesirable behavior, as the auditing state should be orthogonal to the process flow and there should be no feedback.
The ComponentID suffers in that it is only applicable for BPEL process instances, and is difficult to search for easily within the Enterprise Manager console.
So, in summary, if you wish to create a long term identity for external reference that will always exist and is unique, you should always use the ECID.
One quick and easy way to populate an ECID is demonstrated in my previous blog post.