OSB Reporting with Co-releation

OSB reporting seems to have performance impact as mentioned by Ahmed. However, there are not not many options when it comes to report/tracing in OSB. Alerts and logs both are file based, a bit hard to search relevant info. We wanted to report start/exit and exception activity in OSB, and to check any way to co-relate all reporting actions which are related to same instance flow.

If we have co-relation id in all request messages payload, we can probably log that, but even body variable gets overwritten with fault or response, and it becomes very hard to co-relate different reporting entry which belongs to same instance.

Here the approach which worked out for us:
Basically we used OSB's messageId as correlation id for all reporting activity.

fn-bea:inlinedXML(fn:concat('<corelationid>',$messageID,'</corelationid>'))

Now we can use corelationid in any activity we want.

At the run time, we can see correlation, and from any event we can find corelationid and then search the entire trace with any corelationid.

Composite Fault vs Soap Fault

Nothing new, but just something for my own reference as it is bit confusing how composite faults gets mapped to actual soap fault. For the majority of the Runtime Faults, SOA 11g provides following structure:



With three main attributes, summary, detail and code. If you throw fault and test it from Soap UI or any WS client, you get following result. Between composites or through fault policy, you get full access to composite fault, but it looks quite different from WS client.



Below shows how SOA engine is converting Composite Fault to SOAP fault. Basically composite.summary goes to faultstring. detail goes to exception with sub elements. Fault code in composite is simply ignored.




Fault code is in soap fault is set as env:Server. Probably http://www.w3schools.com/soap/soap_fault.asp explains this.

To understand on how it works on custom fault, I created custom fault in XSD, and exposed in WSDL in synchronous process.  Upon testing from soap ui, we can see entire Fault gets mapped to child of Soap Fault [detail]. Fault code gets populated as name of the process. Faultstring and Faultfactor shows empty.



I guess it would be better to have full control over the entire fault message.