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.