Table of Contents

Search

  1. Preface
  2. Welcome to Informatica Process Developer
  3. Using Guide Developer for the First Time
  4. Getting Started with Informatica Process Developer
  5. About Interfaces Service References and Local WSDL
  6. Planning Your BPEL Process
  7. Participants
  8. Implementing a BPMN Task or Event in BPEL
  9. Implementing a BPMN Gateway or Control Flow
  10. Using Variables
  11. Attachments
  12. Using Links
  13. Data Manipulation
  14. Compensation
  15. Correlation
  16. What is Correlation
  17. What is a Correlation Set
  18. Creating Message Properties and Property Aliases
  19. Adding a Correlation Set
  20. Deleting a Correlation Set
  21. Adding Correlations to an Activity
  22. Rules for Declaring and Using Correlation Sets
  23. Correlation Sets and Engine-Managed Correlation
  24. Event Handling
  25. Fault Handling
  26. Simulating and Debugging
  27. Deploying Your Processes
  28. BPEL Unit Testing
  29. Creating POJO and XQuery Custom Functions
  30. Custom Service Interactions
  31. Process Exception Management
  32. Creating Reports for Process Server and Central
  33. Business Event Processing
  34. Process Central Forms and Configuration
  35. Building a Process with a System Service
  36. Human Tasks
  37. BPEL Faults and Reports

2. Designer

2. Designer

Fault Handling Processing Rules

Fault Handling Processing Rules

Fault Handling Processing Rules
When a fault occurs in a process, the flow of execution moves from the activity that generated the fault (for example, the invoke that faulted during execution or a throw activity) to the immediately enclosing scope's fault handler. If there is no immediately enclosing scope, the execution moves to the process's fault handler.
Once at the fault handler, a single
<catch>
or
<catchAll>
is matched in order to execute. The rules for matching a fault are as follows.
  • There are several rules and a catch-matching priority scheme for executing a
    <catch>.
    For details, see
    Rules for Catching Faults in a Catch Activity
    .
  • If fault cannot be matched to a
    <catch>
    using the rules referenced above, then it executes the
    <catchAll>
    .
  • If there is no
    <catchAll>
    within the fault handlers, then the implicit fault handling logic executes. This logic acts like there is a
    <catchAll>
    present that contains a single compensate activity that executes the default compensation routine for all enclosed scopes. Once executed, the original fault is rethrown to the next enclosing scope or the process if none is available. If the handler is already at the process level, then the process terminates with the fault.
Prior to the execution of the matched
<catch>
or
<catchAll>
, all of the activities within the scope are terminated. Once a scope catches a fault, it is considered to have not completed normally and as such is not eligible for compensation for that execution. If the scope catches the fault without rethrowing the fault, then normal process execution can resume from the point of the scope on. If this happens at the process level, then the process completes normally but would not be eligible for process instance compensation.
In the following example, notice that the fault name and fault variable are not unique across catch activities.
Example
<faultHandlers> <!-- catch all faults with a matching name, but no data --> <catch faultName="x:foo"> <empty/> </catch> <!-- catch all faults with the matching variable type, whose name is not "x:foo"--> <catch faultVariable="bar" faultMessageType="tns:barType> <empty/> </catch> <!-- catch the fault specified by the name and variable type --> <catch faultName="x:foo" faultVariable="bar" faultMessageType="tns:barType> <empty/> </catch> <!-- catch all faults not caught by a specific handler --> <catchAll> <empty/> </catchAll> </faultHandlers>
The Rethrow Activity and Fault Handling
A BPEL process can rethrow an original fault caught by the nearest enclosing fault handler with a
<rethrow>
activity. A
<rethrow>
activity can be used within any fault handler. Regardless of how a fault is caught and whether a fault handler modifies the fault data, a
<rethrow>
activity always throws the original fault data and preserves its type.
Links and Fault Handling
A link that crosses a fault handler boundary must be outbound; that is, it must have its source activity within the fault handler and its target within a scope that encloses the scope associated with the fault handler.


Updated March 30, 2020