Skip Headers
Oracle® Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management
11g Release 1 (11.1.1.6.3)

Part Number E15176-11
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

21 Handling Errors

This chapter describes how to handle errors that occur when running a business process. Oracle BPM provides you with an exception component that enables you to model errors and multiple BPMN structures that you can use to handle those errors while running the process.

This chapter includes the following sections:

21.1 Introduction to Error Handling

There might be situations when an unexpected problem occurs causing your process to fail. There are two types of errors: system errors and process errors.

System errors are the consequence of a failure in the software or hardware infrastructure where the BPMN Service Engine is running. A system error can have many causes. The following are examples of problems that can cause a system error:

To recover from system errors within the process flow you can use system exceptions.

If you do not handle a system exception in your process, you can recover from them using the fault recovery system provided by Oracle Enterprise Manager. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite for more information about the Oracle Enterprise Manager fault recovery system.

Process errors are problems that interfere with the regular development of your process. For example, in a purchase order process, if there is no stock for the requested item then you cannot continue with the regular process flow. You can handle these unexpected situations within the process flow. One way to handle the situation in this example by letting the customer cancel the order or save it for later.

The following are typical examples of unexpected situations within a process:

When an exception occurs in a process, it affects the state of the SOA composite that contains that BPMN process. For more information on how exceptions affect the state of the SOA composite, see Section 18.1.4, "How Do BPMN Errors Affect the SOA Composite Status".

21.1.1 Handling Errors Using Exceptions

Oracle BPM uses business exceptions to represent unexpected situations that can occur while running a business process.

You can design how to handle an exception as part of the business process, but it is something that occurs outside of the usual flow of a process. The use of business exceptions enables you to create less complicated processes where the main flow follows the typical use cases, and there is a separate flow to handle the process exception.

21.2 Using Business Exceptions

Business exceptions are considered a normal part of the process design, rather than an error.

When you add a component to the business catalog, if the services in the component specify that they can produce errors, then these errors appear as business exceptions in the business catalog in the Errors predefined module.

An exception can arise when you invoke a service. You can handle these exceptions using a boundary error catch event or an event subprocess.

You can also define business exceptions in the business catalog. Then, you can use those business exceptions in an error end event that is triggered under a certain condition. The error end event generates the exception, and the parent process can handle the exception.

21.3 Using System Exceptions

System exceptions represent low level errors that may occur while running a process. In some cases you may require to handle this low level errors within your process.

To handle a system exception within the process flow you must catch the exception and configure the error catch event to use system exceptions.

System exceptions may occur while running a service or another BPMN process. You also design your process to throw certain system exceptions. The only exception that you can use in a throw or end event is Rollback. All the other supported system exceptions are only available for start of catch error events.

System exceptions contain an errorInfo attribute of type Any. You can assign any value to this attribute. Because its type is Any this value can belong to any type. Generally you use this attribute to store the cause of the exception or important information for troubleshooting the application.

You can only view the list of available system exceptions from the Implementation Properties of an error event.

Table 21-1 describes the supported system exceptions. It also specifies the module where the system exception resides and the error events that can use the specified system exception.

Table 21-1 System Exceptions

System Exception Module Description Error Event

AssertFailure

Bpel

Indicates that the specified assertion failed.

Catch, Start

BindingFault

Bpel

Indicates that the preparation of the operation invoked in a flow object failed. For example, the WSD loading failed. You cannot retry the invocation after a BindingFault, recovering from this error generally requires human intervention.

Catch, Start

InvalidVariables

Bpel

Indicated that the variables used are not valid.

Catch, Start

RemoteFault

Bpel

Indicates that there was a problem invoking a service in a flow object. For example, the remote service returned a SOAP fault.

Catch, Start

Timeout

Soap

Indicates that the service exceeded the response time out period.

Catch, Start

ConflictingReceive

Soap

Indicates that there are multiple receive activities to respond to the invoked operation.

Catch, Start

ConflictingRequest

Soap

Indicates that there are multiple requests on the same partner link for the invoked operation.

Catch, Start

CorrelationViolation

Soap

Indicates that the message does not provide the required correlation information.

Catch, Start

ForcedTermination

Soap

Indicates the service terminated because a SOAP fault occurred.

Catch, End

InvalidReply

Soap

Indicates that the reply does not contain the correlation information required by the corresponding receive.

Catch, Start

MismatchedAssignmentFailure

Soap

Indicates the assigned types are incompatible.

Catch, Start

RepeatedCompensation

Soap

Specifies that a compensation handler is invoked multiple times.

Catch, Start

SelectionFailure

Soap

Indicates there was an error running a selection operation.

Catch, Start

UninitializedVariable

Soap

Indicates that the variable you are accessing is not initialized.

Catch, Start

Rollback

Soap

Enables the receiver of the exception to rollback the current JTA transaction from within the process flow.

Throw, End


21.4 Typical Flow of an Exception

The flow of a system or a business exception depends on where the exception occurred.

Exceptions can occur while running the following:

21.4.1 Typical Flow of an Exception Thrown in a Task

The following describes what happens when the BPMN Service Engine runs a task that causes an exception.

  1. The BPMN Service Engine runs a task that starts a service that can throw an exception.

  2. The task fails with a SOAP error that the BPMN Service Engine converts into an exception.

  3. If the task has a boundary catch error event attached, then the instance follows the flow defined by the boundary catch error event to handle the exception. The exception handling flow may resume the main process flow. If it does not resume the main process flow, then the process ends in the boundary catch error event.

    If the task does not have a boundary catch error event associated with it, then the exception propagates to the process level.

  4. At the process level, the following options are possible:

    • If the process does not contain an event subprocess that can catch the exception and you did not define a fault policy, then the BPM Service Engine logs this error to the Oracle Enterprise Manager fault recovery system. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite for more information about the Oracle Enterprise Manager fault recovery system.

    • If the process contains an event subprocess with a start event of type error configured to catch that exception, then the instance continues through the exception handling flow. When the instance completes the exception handling flow, the process ends.

21.4.2 Typical Flow of an Exception in a Subprocess

The following sequence describes what happens when the BPMN Service Engine runs a subprocess that causes an exception.

  1. The BPM Service Engine runs a subprocess that contains a task that invokes a service that can throw an exception, or an end error event.

  2. One of these events happens:

    • The task throws an exception.

    • The subprocess ends with an error event.

  3. If the exception occurs in a task and the task has a boundary catch error event or the subprocess contains an event subprocess that can handle the exception, then the exception is not propagated to the parent process.

    If the subprocess ends with an error event, or the exception occurs in a task and is not handled, then the exception propagates to the parent process.

  4. The parent process can handle the exception if:

    • the subprocess has a boundary catch event attached.

    • it contains an event subprocess configured to catch the exception.

    If the parent process cannot handle the exception, then it propagates it to its parent process. If there is no parent process, then the exception is logged to the Enterprise Manager fault recovery system. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite, for more information about the Enterprise Manager fault recovery system.

21.4.3 Typical Flow of an Exception in a Reusable Process

The following sequence describes what happens when the BPMN Service Engine runs a call activity that invokes a reusable subprocess that causes an exception.

  1. The BPM Service Engine runs a reusable process that contains a task that invokes a service that can throw an exception, or an end error event.

  2. One of these events happens:

    • The task throws an exception.

    • The reusable process ends with an error event.

  3. If the exception occurs in a task and the task has a boundary catch error event or the reusable process contains an event subprocess that can handle the exception, then the exception is not propagated to the parent process.

    If the subprocess ends with an error event, or the exception occurs in a task and is not handled, then the exception propagates to the parent process.

  4. The parent process can handle the exception if:

    • the call activity has a boundary catch event attached.

    • it contains an event subprocess configured to catch the exception.

    If the parent process cannot handle the exception, then it propagates it to its parent process. If there is no parent process, then the exception is logged to the Enterprise Manager fault recovery system. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite, for more information about the Enterprise Manager fault recovery system.

21.5 Handling Exceptions in a Business Process

You can handle the exceptions that occur in an activity using the following:

Boundary error catch events enable you to resume the main process flow after handling the exception.

If you want to reuse the exception handling flow for multiple tasks in your process, then event subprocesses are more efficient than boundary catch events. Event subprocesses enable you to define a cleaner process with less effort because the catch error event is located within the event subprocess. To reuse an exception handling flow using boundary catch events, you must define a boundary catch event for each of the tasks, and then connect those boundary events to the exception handling flow.

Figure 21-1 shows a process that handles an error using a boundary error catch event.

Figure 21-1 Boundary Error Catch Event

Description of Figure 21-1 follows
Description of "Figure 21-1 Boundary Error Catch Event"

Event subprocesses also enable you to define data objects that you can access only from within the event subprocess, in the same way that subprocesses enable you to define their own data objects.

Figure 21-2 shows a process that handles an error using a an event subprocess.

Figure 21-2 Event Subprocess with a Start Error Event

Description of Figure 21-2 follows
Description of "Figure 21-2 Event Subprocess with a Start Error Event"

21.5.1 How to Handle an Exception Using a Boundary Error Catch Event

If you know that running a flow object can cause an exception, then you can design your process to handle the exception using a boundary error catch event.

To handle an exception using a boundary error catch event:

  1. Create an exception handling flow.

    After handling the exception, this flow can resume the main process or end the process.

  2. From the Component Palette, from the Catch Events section select Error Event.

  3. Drop the error event over the task that throws the exception.

    You can place the event in any part of the border of the task.

    When you drop the error event, a sequence flow appears that you can connect to the exception handling flow.

  4. Connect the sequence flow to the exception handling flow.

  5. Right-click the boundary catch error event.

  6. Select Properties.

  7. Click the Implementation tab.

  8. Configure the implementation properties to catch a business or system exception.

    For information on how to configure the implementation properties to catch business exceptions, see Section 21.5.5, "How to Configure an Error Event to Catch Business Exceptions".

    For information on how to configure the implementation properties to catch system exceptions, see Section 21.5.6, "How to Configure a Catch Event to Catch System Exceptions".

21.5.2 What Happens When You Handle an Exception Using a Boundary Catch Event

If the BPMN Service Engine encounters an error while running a task that has a boundary error catch event attached, then it follows the flow defined by the boundary error catch event. The exception handling flow defined by the boundary error catch event can re-join the main process flow or end the process.

21.5.3 How to Handle an Exception Using an Event Subprocess

You can use an event subprocess to handle an exception that can occur while running any of the flow objects in your BPMN process.

To handle an exception using an event subprocess:

  1. From the Component Palette, from the Activities section, select Event Subprocess.

  2. Drop the event subprocess in the process.

  3. Right-click the start event of the event subprocess.

  4. Select Properties.

  5. Click the Implementation tab.

  6. From the Implementation Type list, select Error.

  7. Configure the implementation properties to catch a business or system exception.

    For information on how to configure the implementation properties to catch business exceptions, see Section 21.5.5, "How to Configure an Error Event to Catch Business Exceptions".

    For information on how to configure the implementation properties to catch system exceptions, see Section 21.5.6, "How to Configure a Catch Event to Catch System Exceptions".

21.5.4 What Happens When You Handle an Exception Using an Event Subprocess

If the exception handled in the event subprocess occurs while running any of the tasks in the process, then the BPMN Service Engine continues running the exception handling flow defined in the event subprocess.

21.5.5 How to Configure an Error Event to Catch Business Exceptions

You can configure an error event to catch business exceptions. To configure an error event to catch business exceptions you must edit the error event implementation properties.

To configure the implementation properties of an error event to catch business exceptions:

  1. If you want to handle all the business exceptions that can occur while running this process, then select Catch All Business Exceptions.

    If you want to catch a specific business exception:

    1. Click the Browse button next to the Exception field.

      The Type dialog box appears.

    2. Enter the name of the exception or select it from the tree.

    3. Click OK.

      The Type dialog box closes and the selected exception appears in the Exception field.

21.5.6 How to Configure a Catch Event to Catch System Exceptions

You can configure an error event to catch system exceptions. To configure an error event to catch system exceptions you must edit the error event implementation properties.

To configure the implementation properties of an error event to catch system exceptions:

  1. If you want to handle all the system exceptions that can occur while running this process, then select Catch All System Exceptions.

    If you want to catch a specific business exception:

    1. Click the Browse button next to the Exception field.

      The Type dialog box appears.

    2. Select Show System Faults.

      The tree shows the available system faults. For a list of the supported exception for the different error events, see Table 21-1.

    3. Enter the name of the exception or select it from the tree.

    4. Click OK.

      The Type dialog box closes and the selected exception appears in the Exception field.

21.6 Throwing Exceptions in Subprocesses or Reusable Processes

You can only throw business exceptions using an error end event, thus only parent processes can catch these exceptions.

You can configure your process to throw custom high level exceptions instead of throwing the low-level exceptions that occur while running the task. To throw a high level exception, connect the boundary events in your activities to the end event that throws the error, or finish the subprocess event with an error end event.

21.6.1 How to Throw an Exception

You can use an error end event to configure your BPMN process to throw a business exception.

To throw an exception:

  1. If you want to throw a custom exception, create a business exception.

    You can also throw existing business exceptions or system exceptions.

    See Section 21.6.3, "How to Create a Business Exception" for more information on how to create a business exception.

  2. Identify the point in your process where you want to throw the exception.

  3. Branch the flow of the process using one of these options:

    • Add a gateway to create a branch in the flow of the process.

    • Add a boundary event.

  4. From the Component Palette, drag Error End Event and drop it in the process.

  5. Add a sequence flow to link the gateway or boundary event, and the error end event.

  6. Right-click the error end event.

  7. Select Properties.

  8. Click the Implementation tab.

  9. Click the Browse button next to the Exception field.

    The Type dialog box appears.

  10. If you want to throw a system exception, Select Show System Faults.

    The tree shows the available system faults. For a list of the supported exception for the different error events, see Table 21-1.

  11. Enter the name of the exception or select it from the tree

  12. Click OK.

    The Type dialog box closes and the selected exception appears in the Exception field.

  13. Click OK.

21.6.2 What Happens When You Throw an Exception

The BPMN Service Engine interrupts the process and throws the exception to the parent process. If the subprocess has an error catch boundary event attached or the parent process has an event subprocess that can handle the error event, then the parent process can handle the exception. Otherwise the parent process throws the exception to its parent process. If it does not have a parent process, then the BPMN Service Engine logs the exception to the Oracle Enterprise Manager fault handling system.

21.6.3 How to Create a Business Exception

You can create a business exception and use it to implement the error events in your BPMN process.

To create a business exception:

  1. Right-click a module in the Business Catalog.

    If the business catalog does not contain a module, then you must create one.

  2. Select New.

  3. Select Exception.

  4. Enter a name to identify the exception.

  5. Click OK.

    The Business Exception Editor opens.

  6. Optionally, you can change the errorInfo attribute.

    See Section 21.6.5, "How to Configure the ErrorInfo Attribute in a Business Exception" for information on how to modify the ErrorInfo attribute.

21.6.4 What Happens When You Create a Business Exception

The exception appears in the business catalog in the module you selected. You can configure an error end event in your process to throw this exception, or you can configure a boundary error catch event to handle this exception.

21.6.5 How to Configure the ErrorInfo Attribute in a Business Exception

Business exceptions contain an errorInfo attribute that you can use to store relevant information about the situation that caused the exception. You can use the information in this field to help users, process developers, and administrators understand the cause of the error.

To configure the ErrorInfo attribute in a business exception:

  1. Open the Business Exception Editor.

  2. In the Attributes section, expand the errorInfo attribute.

  3. Make changes to the errorInfo attribute properties.

    You can modify the following properties:

    • Description

    • Documentation

    • Type

  4. Click Save or close the Business Exception Editor, and save the changes.

21.7 Handling Exceptions in Subprocesses

You can handle exceptions that occur in a subprocess in the same way you handle the exceptions in any other BPMN activity.

21.8 Handling Errors in a Peer Process Using Message Events

When a process communicates with another peer process, running any of the flow objects in the peer process may result in an error. For synchronic operations, the correct form of propagating these errors to the invoking peer process is using message events configured as errors.

A message event configured as an error communicates to the invoking peer process that an error occurred while running the process. However the audit trail indicates that the process ran successfully because this is an expected error.

You must define how the invoking peer process handles the exception using one of these options:

If you do not handle the error in the invoking peer process, the error propagates and the process running does not complete successfully.

Note:

You must always define a path for the instance to follow if there are no error. If you do not define a path for the case where there are no errors the project does not build successfully.

Difference Between Using Error Events and Error Message Events

Using error end or throw events to handle errors during interprocess communication is not a good practice. You must only use error events for internal errors that might be handled within the process or propagated to the next level. These errors are not meaningful outside of this process.

The exceptions occurred while running a peer process do not propagate to the invoking peer process. Eventually the invoking peer process receives a time out notification because the peer process stopped responding.

21.8.1 How to Handle Errors in a Peer Process Using Message Events

If you know running an operation in a process that is used for inter-process communication may result in an error, it is advisable to add a message end or throw event to propagate the error to the invoking peer process.

The message error implementation requires you to select a business exception. If your project does not define business exceptions, then you must create a business exception. For more information about business exceptions, see Section 21.2, "Using Business Exceptions".

To handle errors in a peer process using message events:

  1. Edit the peer BPMN process.

  2. Add a message end or throw event.

  3. Add a sequence flow from the flow object that can produce an error to the message end event.

  4. Right-click the message end event.

  5. Select Properties.

  6. Click the Implementation tab.

  7. From the Implementation list, select Exception.

  8. Click the Browse button next to the Exception field, to browse the available business exceptions and select one.

  9. Click OK.

21.8.2 What Happens When You Handle Errors in a Peer Process Using Message Events

If there is an error in the invoked peer process, the error is communicated to the process that invoked it. The invoking peer process must handle the error using error events or the error is propagated to the next level.

After running the invoked peer process, its status appears as successfully ran because the error message event is part of the expected flow of the process.

21.9 Handling Fault Policies in a BPM Process

You can handle fault policy errors within a BPM process, treating them as a business exception.

21.9.1 How to Handle a Fault Policy in a BPM process

To handle a fault policy in a BPM process:

  1. Create an exception based on the wsdl file that contains the fault policy.

  2. Add an error boundary catch event to the service task that can produce a fault policy error.

    For more information on how to add a boundary event, see ...

  3. Configure the error boundary catch event to catch the exception that represents the fault policy:

    1. Right-click the error boundary catch event.

    2. Select Properties.

    3. Click the Browse button next to the Exception field.

    4. Select the exception that represents the fault policy.

    5. Click OK.

  4. Click OK.

21.9.2 What Happens When You Handle a Fault Policy Error Using Exceptions

If you defined an exception to handle a fault policy error, then the BPMN Service Engine handles the fault policy error in the way you defined. When the fault policy error occurs in an activity then the instance follows the exception handling flow defined by the boundary error catch event.