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

Designer

Designer

Tips on Fault Handling

Tips on Fault Handling

Note the following tips:
  • The name of a declared WSDL fault and its associated data are unavailable to a
    <catchAll>
    . If you need access to this information, be sure to provide a specific
    <catch>
    with the fault name and fault variable.
  • You can rethrow the fault that matched your
    <catch>
    or
    <catchAll>
    using the
    <rethrow>
    activity. The original fault data is rethrown, including the fault name and unmodified fault data.
  • You are not limited to working with faults defined in a service's WSDL. You can define a <
    throw>
    activity to use a fault name and variable of your own creation.
  • The standard runtime BPEL faults can occur due to errors in the design of a process (for example, having two receives executing concurrently on the same partner link and operation results in a
    bpel:conflictingReceive
    ) as well as standard runtime errors. In general, it is not good design practice to catch these faults since they mostly represent errors that should be caught during simulation or testing of the process. There are some exceptions to this. For example,
    bpel:joinFailure
    is useful for identifying a situation where an activity does not execute due to its inbound links resulting to false.

0 COMMENTS

We’d like to hear from you!