Different ways to handle Faults in BPEL Process

This post explains fault-handling mechanisms in the context of a microflow business process designed using BPEL.
A microflow business process is a short-running process that constitutes a single transaction. In contrast, a macroflow or long-running process could constitute multiple transactions over a prolonged period. The term fault refers to any exceptional condition that can alter the normal processing of a business process. Within the context of a business process, a fault need not result in a process ending condition; instead, a fault should lead to an actionable event. If a fault is not handled, it will lead to unexpected conditions, outcomes or even unpredictable failures of the business process. A well-designed business process should handle faults so that failures lead to predictable outcomes. Within BPEL, fault handlers can catch faults and attach business relevant execution logic to deal with the exceptional situation.
To correctly approach fault handling, the team identifies all exceptional conditions that can occur in a business process. The fault handling logic can be different depending on the nature of the fault. Identifying and classifying the faults helps you to design the fault handlers and place them within the appropriate scope of the business process.
When designing fault handlers, consider the following options:

• Catch a fault and try to correct the problem, allowing the business process to continue to normal completion.
• Catch a fault and find that it is not resolvable at this scope. Now, you have additional options:
  • Throw a new fault.
  • Re-throw the original fault to allow another scope to handle it.
  • Reply with a fault to the process initiator.
  • Invoke a human task to correct the issue.
  • If the fault handler cannot resolve the issue, you might need to rollback and compensate
    

BPEL activities to propagate a fault:-
BPEL allows fault propagation using throw, rethrow and reply within a fault handler. Next we’ll look at each of these ways to propagate a fault:
Throw
A throw activity indicates a problem that a business process flow cannot handle. You use it to throw an exception corresponding to an internal error condition. You can use a throw activity within the flow of a business process or within a fault handler, to allow an outer fault handler to handle the fault. A throw activity can throw one of the standard BPEL faults or a custom fault. The throw activity is required to provide a name for the fault and can optionally include a variable with data providing further information about the fault.
 
Rethrow
You use a rethrow activity when the current fault handler cannot handle the fault and wants to propagate it to an outer-scoped fault handler. In the absence of a rethrow activity, a fault propagated to a higher level using a throw activity would be a new fault. When a rethrow activity is invoked, the fault is the same instance. The rethrow activity is available only within a fault handler because only an existing fault can be rethrown.
Faults are either application faults or system and standard faults:

• Application faults: These faults occur at set points during a business process due to application issues. The fault condition could be the result of business rules or constraint violations. For example, invoking a bank service to transfer funds can result in an insufficient funds fault. The process designer defines application faults in BPEL. An external service provider defines them in the service’s WSDL. For example see the figure1.
  

Figure 1. User-defined faults in WSDL:

 







User-defined fault in the BPEL Process:-



 
 

System faults and BPEL standard faults: These exceptions are defined by the BPEL runtime and not by the process designer or external service provider. These faults occur due to system-related issues not directly related to data content (for example, service unavailable or network failure). These faults are unexpected and can occur any time within the process execution.

These failures could be short-term (transient) failures (brief network partition) and long-term failures (disk failure). To resolve short-term failures, failure-handling logic such as retries sometimes work. Long-term failures might require human intervention to correct the system failure, followed by a recovery mechanism.
As a subset of system failures, the WS-BPEL specification defines built-in standard fault types for
 
commonly encountered problems. For example, the uninitializedVariable fault indicates an attempt to access the value of an uninitialized part in a message variable. Web Sphere Integration Developer provides the standard fault types as built-in faults, as Figure 3shows: 


Typical fault handling flow
When a fault occurs in a process, the current operational flow moves to the fault handler within the immediate scope. If the current fault handler does not have the appropriate Catch element defined to trap and handle this fault, the Business Process Container checks from inner scope to outer scope until it finds an appropriate fault handler that can trap this fault. You can visualize the various fault handlers as a chain of fault handlers going from inner to outer scopes; we refer to this as a fault handler chain. This chain, in various scopes, is responsible for trapping the appropriate fault and taking an appropriate action.
Handler attached to an invoke activity :-

 
Handler attached to a scope :-

 


Global process level handler
If there is no handler defined for a fault occurring within a given scope, the fault automatically propagates to the immediately enclosing scope. Faults progressively propagate from the inner scopes to the enclosing outer scopes until they reach a specific fault handler or reach the application-defined, global process fault handler, as Figure 5 shows. If you have not defined a global process level handler, the process will fail to complete gracefully. 


Examples of handling faults within BPEL
In this example, we look at the following fault scenarios:

• Faults thrown within a BPEL process.
• Faults thrown when invoking an service.
• Faults thrown within a Java Snippet, either raising Standard BPEL faults or Java exceptions.
  

Raising application faults from a Java snippet:-
Instead of defining a throw with the appropriate properties to raise an application fault, you can define the fault name with a Java snippet. The methods to raise fault pro-grammatically in a Java snippet are:

You define the QName with the fully qualified namespace. This listing shows the Java snippet that raises an application exception in the BPEL process in this sample:

raiseFault( QName faultName )
raiseFault( QName faultName, String variableName )

QName faultName = new QName("http://MP_FaultHandlingDemo/com/mss/eai/process", "JavaSnippetException");

raiseFault(faultName);

I included a sample project you can download from the  below link:
Download FaultHandlingDemoPI 

 Please use the provided values for faultName and raiseFault documented in the following sections with this sample project.(Follow the below testcases)


Test Cases:
Case1:-If the input to the process is faultName = invalid and raiseFault = true, then it executes the raiseInvalidException case. We throw an application exception using the throw activity.
Output:-In the Console view of Integration Designer, you should see the following output.

SystemOut     O InvalidInputException Caught

Case2:-
The inputs to the process to execute this branch are faultName = Java and raiseFault = true
output:-

SystemOut      "JavaSnippetException Caught"; 

Case3:-
If the input to the process is faultName = innerscope and the raiseFault = true, then it executes the raiseInnerScopeException case. In this branch, we throw an application exception using the throw activity.
The Console window shows the following message:

SystemOut O InnerScopeException was caught by global process catch BpelEngine I CWWBE0061E: A fault 'InnerScopeException' was raised by activity 'ThrowInnerScopeException'.

Case4:-

To test for application faults from an external service, test the MP_FaultHandlingDemoModule with faultName = external and raiseFault = true.
The Console displays the following message:

SystemOut O This has found the Otherwise case. we will log and let fall through to the invoke SystemOut O Application Fault from external service caught

You can simulate the built-in runtimeFailure fault by stopping the MP_FaultHandlingDemoModule App enterprise application from the administration console, or by removing the project from the server via the Servers view.

Now redo the test of MP_FaultHandlingDemoModule with faultName= external and raiseFault = true.
The Console log output displays this message:

ExternalFaultRaiseModuleApp systemout O This has found the Otherwise case. we will log and let fall through to the invoke . . . faultString: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x45) was found in the prolog of the document. Message being parsed: Error 404: No target servlet ..................  SystemOut O Runtime Fault from external service caught