- BPEL Tutorial
- BPEL - Home
- BPEL - Introduction
- BPEL - Activities
- Partner Link in BPEL Process
- Creating a Partner Link
- BPEL - Adapters
- Process Monitors
- One-Way Messages
- Synchronous Interactions
- Asynchronous Interactions
- Asynchronous Interactions with a Timeout
- Asynchronous Interactions with a Notification Timer
- One Request, Multiple Responses
- One Request, One of Two Possible Responses
- One Request, a Mandatory Response, & an Optional Response
- Partial Processing
- Multiple Application Interactions
- Invoking a Synchronous Web Service
- Invoking an Asynchronous Web Service
- Using Parallel Flow
- Using Conditional Branching
- Using Fault Handling
- Resubmitting a Faulted Process
- Incorporating Java & Java EE Code
- Manipulating XML Data
- Using Correlation Sets & Message Aggregation
- Using Events & Timeouts in BPEL Processes
- Using the Notification Service
- Using Oracle BPEL Process Manager Sensors
- Difference between BPEL 1.1 & BPEL 2.0
- BPEL Useful Resources
- BPEL - Quick Guide
- BPEL - Useful Resources
- BPEL - Discussion
BPEL - Using Fault Handling
To understand how to use fault handling, we need to learn the basic architecture of a Service Composite in Oracle SOA Suite.
Service components − BPEL Processes, Business Rule, Human Task, Mediator. These are used to construct a SOA composite application.
Binding components − Establish connection between a SOA composite and external world.
Services − Provides an entry point to SOA composite application.
Binding − Defines the protocols that communicate with the service like SOAP/HTTP, JCA adapter, etc.
WSDL − Defines the service definition of a web service.
References − Enables a SOA composite application to send messages to external services
Wires − Enables connection between service components.
Types of Faults
Let us now see the different types of faults.
Business faults
Occurs when application executes THROW activity or an INVOKE receives fault as response. Fault name is specified by the BPEL process service component. The fault handler using Fault name and Fault variable catches this fault.
Runtime faults
This is thrown by the system. These faults are associated with RunTimeFaultMessage and are included in
http://schemas.oracle.com/bpel/extensionnamespace.
Ways of Fault Handling
In this section, we will learn about the different ways of fault handling.
Throw Activity
Throw activity explicitly throws the fault. The catch block catches this fault and the corresponding actions get executed thereby.
Using throw activity, you can throw business faults & within the created scope, you can catch this fault and redirect to the caller (consumer) to take action.
Instead of the above approach, you throw the same fault caught in catch activity of the created scope. In the main scope, you can catch this fault using the catchall activity.
Error Handler Framework (EHF)
The 2 main files used in EHF are −
- Fault-Policy.xml
- Fault-Bindings.xml
Whenever the BPEL process throws an error, the EHF will check whether the error exists in Fault-Bindings.xml files. If so, the action in the Fault-Policy.xml file will be taken. If the action is not found, the fault will the thrown and it will be handled in the catch block.
Fault management framework (Fault-Policy.xml and Fault-Bindings.xml) is kept inside a SOA Composite.
Fault-handlers like catch and catchall are inside a BPEL to catch all faults, but fault policies will only be executed when an invoke activity fails.