Runtime Fault Handling with the Fault Management Framework

Fault handling allows a SOA suite component to handle error situations caused by outside web services. The error situations can be both business (e.g. invalid data value) and runtime faults (service unavailable). I’m aiming to handle business fault as much as possible in the composite (catch) while handle runtime faults outside the composite.
In the remaining of this blog I will describe an implementation of the Fault Management Framework to handle runtime faults.

I have implemented the following policy:
1) RemoteFault (invocation of a service fails)

  • Start a retry cycle
    standaard retryCount:                 5
    standaard retryInterval:              300 (seconden)
    standaard exponentialBackoff:   2
    Retry will take place after 5, 10, 20, 40 en 80 minutes.
  • If it still fails, start a human intervention

2) All other unhandled (runtime) faults

  • Start a human intervention

The specification of these fault policy is located in the Fault Policy Files.
The fault policy files are loaded at startup, so when any changes are made to them a server restart is required. The two fault policy files we’re  using are stored in the MDS. To use them a reference to them is required in the composite.xml file.  For this, add the following properties:


Policy Files

The content of the policy files is show below:


<?xml version="1.0" encoding="ISO-8859-1"?>
<faultPolicyBindings version="1.0.0"
    xmlns:xsi=<a href=""></a>
    xsi:schemaLocation=<a href=" xsd/fault-bindings.xsd"> xsd/fault-bindings.xsd</a>
    <composite faultPolicy="MOA-FaultPolicy"/>


<?xml version="1.0" encoding="ISO-8859-1"?>
    xmlns:xsi=<a href=""></a>
    xsi:schemaLocation=<a href=" xsd/fault-policies.xsd"> xsd/fault-policies.xsd</a>

    <faultPolicy version="1.0.0" id="MOA-FaultPolicy"
                 xmlns:env=<a href=""></a>
                 xmlns:xs=<a href=""></a>
                 xmlns=<a href=""></a>

            <faultName xmlns:bpelx=<a href=""></a> name="bpelx:remoteFault">
                    <action ref="ora-retry"/>
                    <action ref="ora-human-intervention"/>

            <Action id="ora-retry">
                  <retryFailureAction ref="ora-human-intervention"/>
            <Action id="ora-human-intervention">


Human Intervention with the Enterprise Manager

The following screenshot show a Medewerker (Employee) process instance that invokes the unavailable AccountService.


After three retries, the instance is waiting for a human intervention.
After the first Error Message at the top of the screen the recovery flag is set. Click on the message and then on the recover now button or immediately on the recovery flag.


After selecting the message, the following screen appears.


In this screen you have the possibility to select a Recovery action, change process variables, and invoke the recover operation.

In situation when services are down, after bringing it up again, a retry is quite common (without changing any content).


After recovery the process continues normally.

Also check Greg Mally’s blog post ‘Fault Management Framework by Example’ on Aug 22, 2011 to get a good impression of the functionality of the Framework (


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s