When split-join invokes an OSB business service and that call fails, CatchAll does not help.
Instead of detailed information of what went wrong, the fault variable contains only a single element <soapFault> from the BPEL extensions namespace.
At the same time, if the error is re-raised with the Re-Raise Error block, the code calling the split-join gets the correct description of the fault. The root cause fault is hidden somewhere, and it is not visible.
<!-- where are the details, eh? :( --> <soapFault xmlns="http://www.bea.com/bpel/extensions"/>
How can we get it?
It turns out, that is pretty easy.
The problem only appears when calling business services. Calls to proxies are alright.
If you insert a do-nothing intermediary proxy between the split-join and the business service, the CatchAll’s fault variable will contain the failure details:
<ext:soapFault xmlns:ext="http://www.bea.com/bpel/extensions"> <soap-env:Fault xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <faultcode xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">soapenv:Server</faultcode> <faultstring> BEA-380002: Tried all: '1' addresses, but could not connect over HTTP to server: '127.0.0.1', port: '33333' </faultstring> <detail>...</detail> </soap-env:Fault> </ext:soapFault>>
There is no need to mention that this method is used in GenericParallel, too, and that any response from GenericParallel will contain all the details of the faults in any of the outgoing calls.
My name is Vladimir Dyuzhev, and I’m the author of GenericParallel, an OSB proxy service for making parallel calls effortlessly.
I’m building SOA enterprise systems for clients large and small for almost 20 years. Most of that time I’m working with BEA (later Oracle) Weblogic platform, including OSB and other SOA systems.
Feel free to contact me if you have a SOA project to design and implement. See my profile on LinkedIn.
I live in Toronto, Ontario, Canada. Email me at email@example.com