Fault Policies in soa 11g with email notification

Question

SOA 11.1.1.3
I want to implement faulpolicies.xml and send email notification. (for binding ,remote fault after certain retries).Can I use email activity in BPEL catch block for this , what should I add ,in my faultpolicies.xml to trigger email activity
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicy version="2.0.1" id="FaultPolicyName"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:bindingFault">
<condition>
<action ref="ora-retry"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:runtimeFault">
<condition>
<action ref="ora-retry"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>8</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="send-notification"/>
</retry>
</Action>
</Actions>
Also, can anyone please tell which is a better option - using email activity or custom java code in fault
policies.xml.
Thanks

Answer 1

Like Oraacler suggested, you can definitely rethrow the fault to BPEL to send the notification. However, your BPEL fault handlers will become pretty tedious when you have to check for error types in your catch block to retrieve the message and type the e-mail. On top of that, if you have multiple catch blocks in a single process or multiple processes spec'd to throw similar notifications, you will have to add a lot of redundant code. You can definitely externalize the notification to a different process that handles all e-mails, but even that does not take out having multiple invokes on the faulted process.
Having a fault handler Java class to handle global faults allows you to externalize and standardize exception management and also dramatically minimizes BPEL code. In your Java class you also get the API's to access a lot more information then you will in BPEL allowing you to provide detailed messages. This has been my choice to account for any error that should not happen on a regular basis (binding and remote).
The only drawback of the Java class is the development piece which can take forever since you have to restart the server after every little change. There is however a way to write a client java class for development on JDeveloper which directly connects to the weblogic-soa dehydration store to look up an instance with a fault and retrieve the fault message. You can then use that message to do your testing/development before finalizing it and moving it to the server.
Depends on what you decide, let us know if you run into any more constraints and we can definitely try to help you.
Thanks and good luck!