This content has been marked as final. Show 9 replies
I have implemented similar scenario and it is working fine for me.
My fault policies are in MDs store. and all applications are referring the same policy.
Binding is defined at composite level for all of them. Also Custom java handler I have implemented.
In composite.xml where you want to apply policy make sure you have defined it with below given two parameters just after the <Service>... </Service>tags
Also give proper binding information in fault-binding.xml
However, if a fault occurs in WS1 (maybe an assign with missing "from" data or otherwise) the fault policy does not take affect.It is expected. Fault policy framework works only for faults occurring in invoke activity -
If a fault occurs during runtime in an invoke activity in a process, the framework catches the fault and performs a user-specified action defined in a fault policy file associated with the activity.Please refer section "12.4 Using the Fault Management Framework" at -
For handling non-invoke faults, please use BPEL catch or catchAll activity.
Thank you for confirming my understanding of the fault policy only affecting invoked services. At least I know that I'm not doing something wrong in not being able to trap faults in my first composite (what I'm calling here WS1).
I am using BPEL catch and catchAll to trap the errors. However, my goal with the fault policy is to have the option to recover with adjustments to the payload if necessary. I set my fault policy to use ora-human-intervention and can then correct faulty payloads if needed. Can I do something similar catch faults in my top-level composite using BPEL catch that allows me to adjust and retry the payload?
In Ws1, if your goal is to perform some human intervention through fault-policy and then change the payload in order to remove the problem, instead of handling it in catch or catchall block of BPEL, you can write binding fault handler(for your mentioned Assign activity faults) in fault-policy and there you can call your human intervention.
Since fault-policy framework takes precedence over BPEL fault management framework. Control will go to fault-policies first. If it is rethrown from fault -policy then it will go to BPEL fault handling blocks(catch or catchall).
Ashutosh, I appreciate your advice. However, if I understand your comments, your suggestion is what I have already implemented. Please reread my first post and correct me if I am mistaken.
I am using fault policy binding but the trouble is I cannot route faults that occur in the first composite (which contains the BPEL end point that initiates the entire process) to human intervention. As Anuj noted, fault policies only affect invoked activities which explains the behavior I'm seeing (the first composite isn't invoked by another but is accessed directly via web service end point). That said, my request to catch and handle faults in the first composite doesn't seem unreasonable (does it?).
The short version of my question is "how do I set faults to require human intervention if the faults occur in my first composite?" Or, "in a project containing only one composite how do I set faults to require human intervention when they occur?"
I am using BPEL catch and catchAll to trap the errors.That's the correct way to handle non-invoke exceptions.
However, my goal with the fault policy is to have the option to recover with adjustments to the payload if necessary. I set my fault policy to use ora-human-intervention and can then correct faulty payloads if needed. Can I do something similar catch faults in my top-level composite using BPEL catch that allows me to adjust and retry the payload?Nope. Catch does not allow this. Ideally you should create an Exception Handling framework for this which should allow you to modify the payload and re-initiate the main BPEL. From the catch block of main BPEL you may invoke your Exception Handling framework. This will be more flexible, standard custom solution.