This discussion is archived
9 Replies Latest reply: Dec 11, 2012 5:29 AM by Jon-Eric RSS

Fault policy for initial (top-level) composite to catch internal faults?

Jon-Eric Newbie
Currently Being Moderated
I have a composite exposing a BPEL web service endpoint. Call it WS1. This calls various other composites when invoked (call them WS2, WS3). I have a policy on WS1 with composite-level binding. In WS2 and WS3 I CatchAll and throws a custom fault called GLOBALFAULT. My fault policy on WS1 has faultName entry for GLOBALFAULT and does indeed catch any faults that occur in WS2 or WS3. However, if a fault occurs in WS1 (maybe an assign with missing "from" data or otherwise) the fault policy does not take affect.

I have taken every precaution I can think of in WS1 to avoid faults (e.g. set Assign to ignore missing "from", insert missing "to", and so on) but would still like to know how I can attach a fault policy to the initial composite in a process. I suppose I could create a composite (call it WS0) that does nothing other than invoke WS1 which would accomplish what I want but that seems silly. The reason this is important is that I have custom Java code that runs from my fault policy and I'd like it to run for every fault encountered from the initial composite through all below.

Help!
  • 1. Re: Fault policy for initial (top-level) composite to catch internal faults?
    AshutoshSingh Explorer
    Currently Being Moderated
    Hi Jon,
    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

    <property name="oracle.composite.faultPolicyFile">oramds:/apps/ApplicationName/fault-policies.xml</property>
    <property name="oracle.composite.faultBindingFile">oramds:/apps/ApplicationName/fault-bindings.xml</property>

    Also give proper binding information in fault-binding.xml

    Thanks,
    Ashu
  • 2. Re: Fault policy for initial (top-level) composite to catch internal faults?
    Anuj Dwivedi Guru
    Currently Being Moderated
    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 -

    http://docs.oracle.com/cd/E23943_01/dev.1111/e10224/bp_faults.htm#CIHJEFCI

    For handling non-invoke faults, please use BPEL catch or catchAll activity.

    Regards,
    Anuj
  • 3. Re: Fault policy for initial (top-level) composite to catch internal faults?
    Jon-Eric Newbie
    Currently Being Moderated
    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?
  • 4. Re: Fault policy for initial (top-level) composite to catch internal faults?
    AshutoshSingh Explorer
    Currently Being Moderated
    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).
  • 5. Re: Fault policy for initial (top-level) composite to catch internal faults?
    Jon-Eric Newbie
    Currently Being Moderated
    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?"
  • 6. Re: Fault policy for initial (top-level) composite to catch internal faults?
    AshutoshSingh Explorer
    Currently Being Moderated
    Well, in that case,
    You can invoke another WS which can hold that logic which is there in policy.
    Invoke can be done from catch all or similar BPEL fault handler.

    Thanks,
    Ashu
  • 7. Re: Fault policy for initial (top-level) composite to catch internal faults?
    Jon-Eric Newbie
    Currently Being Moderated
    I'll try the approach you suggest. I still hope to find a solution to activate a fault policy based on a fault in the top-level composite. That doesn't seem like an unusual need and it seems like a "bug" or oversight in the fault policy design to not allow that to be done.
  • 8. Re: Fault policy for initial (top-level) composite to catch internal faults?
    Anuj Dwivedi Guru
    Currently Being Moderated
    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.

    Regards,
    Anuj
  • 9. Re: Fault policy for initial (top-level) composite to catch internal faults?
    Jon-Eric Newbie
    Currently Being Moderated
    What I understand you to say is that I should abandon the fault policy framework as it is "incomplete" and, instead, create my own. While that is an unfortunate situation, I agree that is probably the best solution until the fault policy framework matures a bit.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points