Oracle BPM 11g Exception Handling

Business Exceptions Vs System Exceptions

BPMN offers an error handling mechanism based on Exceptions. These exceptions are handled via Catch Error Events and thrown via the Service Activities of the composite and End Events of the BPM Process.

It is important to take into account that Error Events stop the current activity, process or subprocess (depending on the scope where the catch event is placed). It means that the activities within that scope will not be resumed after compensating the error. This will be shown in later with examples.

Business Exceptions           

Business Exceptions handle unexpected business process errors within the process flow. They enable us to create less complicated processes where the main flow follows the typical use cases (known as Happy Path), and there is a separate flow to handle the process exception

In JDeveloper, when a component that can produce errors is added to the business catalog, these errors appear as business exceptions in the Errors predefined module.

System Exceptions

System Exceptions handle system errors that are consequence of a failure in the software or hardware infrastructure where the BPM Service Engine is running. Within the scope of this post, we focus on catching System Exceptions raised by the Database Adapter and the Web Service Adapter (Service Adapters belonging to the SOA Composite).

System Exception Types

The two most commonly used system faults are Binding Fault and Remote Fault. Remote Fault is used to capture service unavailability errors and Binding Fault is used for all other system errors such as wrong communication. These are the Faults returned by the infrastructure when consuming external services:


DBAdaper down


SQL Queries


(i.e. Table does not exist)

PL/SQL Package exception

BindingFault (‘raise_application_error’)

PL/SQL as a WebService (JDeveloper Wizard)

PL/SQL exception

RemoteFault (‘raise_application_error’)

Service Down


SOAP WebService



Wrong params type


Strategies for catching exceptions

In a BPM Process, exceptions (both Business and System) can be captured in different ways:

· Event Subprocess

· Boundary Events

o Attached to a Subprocess

o Attached to an Activity

Event subprocess

Following is a sample of a process with two Event Subprocess for handling RemoteFaults and BindingFaults.

When an exception is thrown by the "Service Task" and the corresponding compensation subprocess ends, the process finishes. It means that, in the example above, the task DBInfoVisualization is not executed.

The next process solves this problem:

The task DBViewInfo is executed after the ErrorCompensation subprocess.

Boundary events attached to a Subprocess

The following process shows a subprocess for compensation purposes which is executed when an exception is raised by either the Database Adapter or the Web Service Call. It is similar to the previous scenario but adding the possibility of reutilization of the compensation subprocess.

When the compensation subprocess ends the flow goes to the DBViewInfo activity. It means that if the Database Adapter throws an Exception, the Web Service Call is never executed.

Boundary events attached to an activity

The following diagram shows a compensation subprocess that is triggered when either a RemoteFault or a BindingFault is thrown by the activity.

Since Error Events stop the current activity, when catching more than one exception in the same activity or subprocess, only one of them will be handled.

The following process shows a typical composition service which makes different calls to the following services:

· Web Service (External Java SOAP Web Service)

· Database Adapter for SQL query

· Database Adapter for PL/SQL execution

· PL/SQL package published as a Web Service (JDeveloper 11g wizard)

and handles any exception thrown by them:

It is important to note that when an exception is caught, none the following services are called.

(Maybe this is not an appropriate design for a composition service from an architectural point of view, but it exemplifies this chapter and is useful for the purposes of the post)

Boundary Events are represented in the Component Palette as “Error Catch Event“.

For catching exceptions, an Error Catch Event must be dropped to the Service Activity.

By double-clicking on the created Boundary Event we can define the Exception that will be caught. We can choose from these options:

· All business exceptions

· All system exceptions

· A specific exception from the above

In order to get the schema of the Exception and be able to make a data association, it is necessary (in BPM 11gR1PS3) to select a specific exception.

Note: Due to product bug number 10177932 it is not possible to use Data Association when selecting any of the two first options (All business exceptions or All system exceptions). 

For a list of the System Exception, the “Show System Faults” must be checked:

(see chapter System Exception Types in this post for a review of System Faults that can be thrown in Service Tasks)

Extending BPM Services with Exceptions

Since it is not possible to manipulate the exception when a generic group of exceptions is caught (All business exceptions or All system exceptions) it may be useful to have the corresponding System Exception Schema on the Business Catalog Errors folder.

This is achieved by following these steps:

1. Modify the contract wsdl of a Service by adding the Fault referencing to RuntimeException schema

<?xml version = '1.0' encoding = 'UTF-8'?>








            <xsd:import namespace="" schemaLocation="xsd/RuntimeFault.xsd"/>




    <message name="RuntimeFault">

        <part name="fault" type="bpe:RuntimeFaultMessage"/>



    <portType name="PruebaSPV_JavaAsAWS">

        <operation name="XXXX">

            <input message="tns:inputXXXX"/>

            <output message="tns:outputXXXX"/>

            <fault name="RuntimeFault" message="tns:RuntimeFault"/>



    <binding name="XXXXPortBinding" type="tns:XXXX">

        <soap:binding style="document" transport=""/>

        <operation name="XXXX">

            <soap:operation soapAction=""/>


                <soap:body use="literal"/>



                <soap:body use="literal"/>


            <fault name="RuntimeFault">

                <soap:fault name="RuntimeFault" use="literal"/>






2. Check that the Service Adapter on the "composite.xml" has no errors.

3. In the process, refresh every Service Activity that uses the modified Service, by clearing and adding the Service again. Don’t forget to check the corresponding data association.

4. Force refresh of the project: restart JDeveloper 11g.

5. Check that the Exception appears in Errors folder of the Business Catalog:

6. Add the service activity to the process with JDeveloper.

Now we can have access to the Fault content.


Dear Pau Garcia,
I'm trying to use your example, in this case: "Boundary events attached to a Subprocess". But it doesn't work as you say, there can't be a subprocess without outgoing sequence flow, it doesn't auto-return to the outgoing sequence flow from the original subprocess, (the one that generated the exception). Please, would you explain me, if I'm doing something wrong?


Posted by Pablo on June 12, 2013 at 09:30 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Technical and in-depth articles and samples on BPM 11g.


« July 2016