I’ve just finished helping out one of my partners with an interesting problem which resulted in the usage of a new piece of functionality called “faultableResponseHeaderHandler” partner link support in BPEL 10.1.3.4 MLR9.
With this release we’ve extended the responseHeader Handler in our WSIF implementation which allows us the ability to inspect a returning payload, and if required raise a BPEL Fault..
Why do this? Well in our case the system was experiencing random errors from a remote service which if retried would work correctly but as the remote service responded with a business error and not a fault the standard fault management framework couldn’t help.
In a perfect world the BPEL Developer would have detected this error by inspecting the payload in BPEL and then issued a retry, however using this new piece of functionality we were able to implement the raising of an error, which then triggers off the standard BPEL Fault Management Framework (documented page 29 of this doc) without changing the main bpel code, which in turn keeps the legibility of the BPEL code high.
So how do you use this new piece of functionality
1. Install Oracle SOASuite 10.1.3.4 and MLR9 (obvious really)
2. Create a class which implements the interface “com.collaxa.cube.ws.FaultableHeaderHandler”
This class should implement the following method
public void invoke(CXPartnerLink cxPartnerLink, String string, Map map, List list, Map map1) throws BPELFault
{ ….. }
The Map contains the payload elements, each one corresponding to a part of the input/output message as defined in your WSDL. The next step is to get the dom object and query it.. For this you have many options, you could use a DOM API , an XPATH query or something else.. I’ve used xpath as I think it would be easier..
3. If you decide not to raise a fault, then simply return, if however you decide to raise a fault then simply create a new java exception of type “com.oracle.bpel.client.BPELFault”, fill in the parameters accordingly to the javadocs and throw it.
4. Deploy the resulting class into the <OracleHome>/bpel/system/classes directory and restart your SOASuite server
5. At this point you need to edit the partnerLink binding in the bpel.xml file to include a new parameter called “faultableResponseHeaderHandler” and give it the fully qualified name of class implementing your hander.
e.g.
<partnerLinkBinding name="MyService">
<property name="wsdlLocation">MyServiceWSIF.wsdl</property>
<property name="faultableResponseHeaderHandler">com.sample.angelosFaultableErrorHander</property>
....
</partnerLinkBinding>
and then deploy it into your BPEL domain.
At this point you should be able to execute your bpel code, and based on the custom logic in your faultableHeaderHandler code, you can throw a BPEL Fault instead of returning a business fault within the response.. At this point I recommend using the Fault Management Framework to manage the fault, e.g. example retry 5 times.
For more information on the Fault Management Framework see here
Finally, big thanks to Clemens and my Italian friends for helping out here.
Enjoy!
Resources & Hints
- Good tutorial on XPATH available here http://www.ibm.com/developerworks/library/x-javaxpathapi.html
- Deploy the classes into the <OracleHome>/bpel/system/classes directory
- If you use System.out.println() for debugging your code you’ll see the output go into the BPEL containers log in <OracleHome>opmn/log
- I’ll be posting a JDeveloper Workspace with a test project soon :-)
- com.collaxa.cube.ws.FaultableHeaderHandler interface can be found in orabpel.jar which is in <OracleHome>/bpel/lib
]]>
