The Invoke Activity with Inline Fault Handler
Introduction
This sample focuses on the invoke activity and how it can be configured with its own inline fault handler (catch). It includes an example BPEL process that demonstrates the use of the invoke activity with an inline catch.
The sample process contains a sequence that starts with a receive activity which accepts a message containing a credit check request. The sequence ends with a reply that returns a message containing a string. In between the receive and the reply is an invoke with an inline fault handler (a catch).
The invoke activity's inline fault handler contains a single primary activity, an assign, which will construct an error message and place it into the variable (approvalMessage) that will be sent back to the client. If a fault occurs during the execution of the invoke, the catch will be triggered and the assign will be executed.
Whether or not a fault occurs during execution of the invoke, approvalMessage is copied to the message to be returned by the reply activity.
A second BPEL process is the target of the invocation. It looks at the loan amount and either returns "approved" if the loan amount is < 10,000 or returns a WSDL fault with error code 101 if the loan amount is >= 10,000.
The Invoke Activity and Inline Fault Handlers
The invoke activity provides a way for a BPEL business process to consume (invoke) other Web Services. Simply put, an invoke sends messages to other services and optionally waits for a response.
One of the features available to an invoke activity is an inline fault handler—a catch or catchAll activity. If an invoke experiences a fault during its execution, and that fault matches an inline catch, or the inline fault handler is a catchAll (which triggers on any fault), then the activity in the fault handler will be executed. As with any other fault handler, the primary activity can be any valid BPEL construct, including a container with nested activities. The BPEL specification defines this as follows:
Semantically, the specification of local fault ... handlers is equivalent to the presence of an implicit scope immediately enclosing the activity and providing those handlers. The name of such an implicit scope is always the same as the name of the activity it encloses.
Keep this in mind if you view the sample process in ActiveBPEL Designer, which will display the implicit scope in the designer canvas. The scope won't actually appear in the BPEL's XML source.
Why Use Inline Fault Handlers?
An inline fault handler for an invoke activity lets you define fault handling behavior that's specific only to the invoke itself, precluding the need for an enclosing scope activity. The fault handling behavior is identical to what you would get if an explicit scope were used.
XML Syntax and Semantics
<invoke partnerLink="ncname" portType="qname" operation="ncname"
inputVariable="ncname"? outputVariable="ncname"?
standard-attributes>
standard-elements ... <catch faultName="qname" faultVariable="ncname"?>*
activity
</catch> <catchAll>?
activity
</catchAll> ... </invoke>
Standard attributes and elements
The standard-attributes are name,
joinCondition, and suppressJoinFailure.
The standard-elements are source
and
target, used when linking activities together.
Attributes
The partnerLink, portType, operation, inputVariable and
outputVariable define the details of interaction with the Web
Service
being invoked.
Fault handlers
The invoke activity may contain zero or more catch
elements
and an optional catchAll element. Each of these may
contain a
single primary activity.
Whenever no inline catch or catchAll is defined for an invoke, the default behavior is to throw the fault to the invoke's parent scope. This process continues until the global process scope is reached.
Activity
As mentioned above, a catch or catchall contains exactly one activity. That activity may be a structured activity, which implies that an invoke's inline fault handlers may encompass arbitrarily complex behavior.
Deploying the Processes
See Deploying the Samples. You will need to deploy two BPEL processes: smallloanapproval and invoke_with_catch.
Running the Process
See Running the Samples.
The
service name to use is riskAssessmentLinkTypeService. The sample data
file
testInvoke.xml can be used as input for this example.
There are two paths through this process. It is a simple illustration of the use of an inline fault handler for an invoke activity and it invokes a service which returns a fault for loan approval amounts of 10000 or more, ultimately returning a response string of "Approver Error! Error code: 101". Loan amounts of less than 10000 will result in an "approved" response.
Copyright © 2004–2007 Active Endpoints, Inc.