The Oracle SOA Suite provides an Audit Trail monitor screen where the message flow between the different SCA composites can be tracked. Depending on the audit level, it can provide a very detailed chronology of the different states of the message, including the first component that receives the messages, its correspondent transformation along the way, and the routing it’s final destination. Nevertheless, a SOA platform is intended to integrate not only internal composites but also external components. The question is how to maintain the audit trail consistency in such scenarios?
The Oracle A-team posted a very helpful blog demonstrating how to propagate the ECID between JCA adapter calls in order to maintain the audit trail consistency. This blog is going to demonstrate how to achieve this result with JAXWS web services.
As the reader might have already figured it out, the key to this problem relies with the ECID. The execution context id (ECID) is the mechanism the SOA Suite uses to keep track of the messages as it passes between the different components. If an SCA calls another one, it will pass through the ECID, helping the audit trail to correlate the different component instances into one flow. Also, if instead of a SCA composite a JAXWS web service, the ECID will be passed in the SOAP header, more specifically in the ReplyTo element:
So this tracking.ecid attribute has to be propagated in order to allow the SOA Suite to track the message in the Audit trail.
For example let’s use a simple scenario in which an SCA composite called FirstSCA invokes a JaxWS web service, and this web service calls another SCA Composite called SecondSCA. If this scenario is executed, the audit trail will show two independent flow even though there were on the same process.
The first step needed in order to propagate the ECID is to access the SOAP headers
HeaderList hl = (HeaderList)context.get(JAXWSProperties.INBOUND_HEADER_LIST_PROPERTY);
This HeaderList object contains all the SOAP header elements, including the replyTo. In this case, since we are using synchronous web services, the same replyTo header can be sent to the SecondSCA in the request. In an asynchrounous scenario this header should be generated with the corresponded address in order to comply with the WS-Addressing standard. The document “Programming Advanced Features of JAX-WS Web Services for Oracle WebLogic Server” shows how to create the required WS Addressing headers for JAX-WS clients.
The header can be passed using the WSBindingProvider Object
SecondBPELProcess secondBPELProcess = secondbpelprocess_client_ep.getSecondBPELProcess_pt();
In this example, secondbpelprocess_client_ep is the web service endpoint and secondBPELProcess is the web service proxy. Passing the replyToHeader to the WSBindingProvider propagates the ECID and generates the desired result