BPEL 2.0 Standard Faults Introduction to BPEL Standard Faults

Using Fault Handling in a BPEL Process 11-5 ■ Otherwise, if the fault data is a WSDL message type in which the message contains a single part defined by an element and there exists a catch activity without a faultName attribute that has a faultVariable whose associated faultElement’s QName matches the QName of the runtime element data of the single WSDL message part, the fault is sent to the identified catch activity with the faultVariable initialized to the value in the single part’s element. ■ Otherwise, if there is a catchAll activity, the fault is sent to the catchAll fault handler. ■ Otherwise, the fault is handled by the default fault handler.

11.3 Introduction to Categories of BPEL Faults

A BPEL fault has a fault name called a Qname name qualified with a namespace and a possible messageType. There are two categories of BPEL faults: ■ Business faults ■ Runtime faults

11.3.1 Business Faults

Business faults are application-specific faults that are generated when there is a problem with the information being processed for example, when a social security number is not found in the database. A business fault occurs when an application executes a throw activity or when an invoke activity receives a fault as a response. The fault name of a business fault is specified by the BPEL process service component. The messageType, if applicable, is defined in the WSDL. A business fault can be caught with a faultHandler using the faultName and a faultVariable. catch faultName=ns1:faultName faultVariable=varName

11.3.2 Runtime Faults

Runtime faults are the result of problems within the running of the BPEL process service component or web service for example, data cannot be copied properly because the variable name is incorrect. These faults are not user-defined, and are thrown by the system. They are generated if the process tries to use a value incorrectly, a logic error occurs such as an endless loop, a Simple Object Access Protocol SOAP fault occurs in a SOAP call, an exception is thrown by the server, and so on. Several runtime faults are automatically provided. These faults are included in the http:schemas.oracle.combpelextension namespace. These faults are associated with the messageType RuntimeFaultMessage. The WSDL file shown in Example 11–2 defines the messageType: Example 11–2 messageType Definition ?xml version=1.0 encoding=UTF-8 ? definitions name=RuntimeFault targetNamespace=http:schemas.oracle.combpelextension xmlns:xsd=http:www.w3.org2001XMLSchema xmlns=http:schemas.xmlsoap.orgwsdl message name=RuntimeFaultMessage part name=code type=xsd:string part name=summary type=xsd:string part name=detail type=xsd:string 11-6 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite message definitions If a faultVariable of messageType RuntimeFaultMessage is used when catching the fault, the fault code can be queried from the faultVariable, along with the fault summary and detail.

11.3.2.1 bindingFault

A bindingFault is thrown inside an activity if the preparation of the invocation fails. For example, the WSDL of the process fails to load. A bindingFault is not retryable. This type of fault usually must be fixed by human intervention.

11.3.2.2 remoteFault

A remoteFault is also thrown inside an activity. It is thrown because the invocation fails. For example, a SOAP fault is returned by the remote service.

11.3.2.3 replayFault

A replayFault replays the activity inside a scope. At any point inside a scope, this fault is migrated up to the scope. The server then re-executes the scope from the beginning.

11.4 Using the Fault Management Framework

Oracle SOA Suite provides a generic fault management framework for handling faults in BPEL processes. If a fault occurs during runtime in an invoke activity in a process, the framework catches the fault and performs a user-specified action defined in a fault policy file associated with the activity. If a fault results in a condition in which human intervention is the prescribed action, you perform recovery actions from Oracle Enterprise Manager Fusion Middleware Control. The fault management framework provides an alternative to designing a BPEL process with catch activities in scope activities. This section provides an overview of the components that comprise the fault management framework. ■ The fault management framework catches all faults business and runtime for an invoke activity. ■ A fault policy file defines fault conditions and their corresponding fault recovery actions. Each fault condition specifies a particular fault or group of faults, which it attempts to handle, and the corresponding action for it. A set of actions is identified by an ID in the fault policy file. ■ A set of conditions invokes an action known as fault policy. ■ A fault policy bindings file associates the policies defined in the fault policy file with the following: – SOA composite applications – BPEL process and Oracle Mediator service components – Reference binding components for BPEL process and Oracle Mediator service components The framework looks for fault policy bindings in the same directory as the composite.xml file of the SOA composite application or in a remote location identified by two properties that you set. Using Fault Handling in a BPEL Process 11-7 ■ The fault policy file fault-policies.xml and fault policy bindings file fault-bindings.xml are placed in either of the following locations: – In the same directory as the composite.xml file of the SOA composite application. – In a different location that is specified with two properties that you add to the composite.xml file. This option is useful if a fault policy must be used by multiple SOA composite applications. This option overrides any fault policy files that are included in the same directory as the composite.xml file. Example 11–3 provides details about these two properties. In this example, the fault policy files are placed into the SOA Metadata Service MDS shared area. Example 11–3 Fault Policies used by Multiple SOA Composite Applications property name=oracle.composite.faultPolicyFileoramds:appsfaultpolicyfiles fault-policies.xml property property name=oracle.composite.faultBindingFileoramds:appsfaultpolicyfiles fault-bindings.xml property See Chapter 21, Using Oracle Mediator Error Handling for details about Oracle Mediator fault handling capabilities.

11.4.1 How to Design a Fault Policy

This section describes how to design a fault policy.

11.4.1.1 Understanding How Fault Policy Binding Resolution Works

A fault policy bindings file associates the policies defined in a fault policy file with the SOA composite application or the component service component or reference binding component. The framework attempts to identify a fault policy binding in the following order: ■ Reference binding component defined in the composite.xml file. ■ BPEL process or Oracle Mediator service component defined in the composite.xml file. ■ SOA composite application defined in the composite.xml file. Note: A fault policy configured with the fault management framework overrides any fault handling defined in catch activities of scope activities in the BPEL process. The fault management framework can be configured to rethrow the fault handling back to the catch activities. Note: The Facades API enables you to programmatically perform the abort, retry with a success action, continue, rethrow, and replay recovery options. For information, see Oracle Fusion Middleware Infrastructure Management Java API Reference for Oracle SOA Suite.