The Scope Activity
Introduction
This sample focuses on the scope activity: its uses, parts, and
syntax. It
includes an example BPEL process that uses all of the aspects of the
scope
activity (except one: the variableAccessSerializable
attribute,
covered in Serializable Scopes).
Scopes provide a way to organize the activities within your BPEL process. They also provide context for variables, fault handling, compensation, event handling, and correlation sets.
The sample process, shown below, contains a sequence that starts with a receive activity that accepts a message containing an order. The sequence ends with a reply that returns a message containing a string. In between the receive and the reply is an outer scope that contains an inner scope.
The outer scope declares a local variable. (This declaration isn't visible in the image below.) The scope's primary activity is a sequence containing four activities. The first assigns the string "Initial variable value" to the local variable. The second is an inner scope. The third is an empty activity named "DoSomethingInteresting" that is standing in for some fictional "interesting" activities. The final activity of the scope's sequence copies the value of the local variable to the output message.
The inner scope's activity is an assign activity that sets the local variable's value to "Inner scope value".
The previous paragraphs describe the normal flow through the process: receive a message, declare a local variable, assign a few values to it, and return the value. Now it gets interesting: the outer scope has an event handler that contains an onAlarm which times out after five minutes. If the alarm goes off, it throws a fault. The same outer scope has a fault handler that contains a catchAll, so it will catch the thrown fault. The catchAll contains a compensate activity that compensates the inner scope.
The inner scope's compensation handler sets the local variable's value to "Compensated value". So, if the alarm goes off after if the inner scope has completed normally but before the outer scope has completed normally (for example, during the execution of the "DoSomethingInteresting" activity) then the value of the local variable will be set to "Compensated value", and that value will be copied to the output message.
The Scope Activity
The scope activity partitions a BPEL business process into logically organized sections. It provides context for variables, fault handling, compensation, event handling, and correlation sets. It is a structured activity that contains one other activity, which may itself contain other activities.
A scope is very similar to the top-level BPEL process element. The only difference is that the process element may contain partner links and partners; a scopes does not.
A scope shares some of the attributes of most programming languages' lexical scoping (delimited by curly braces in C++ and Java and functions or methods in most languages): it provides a place to declare variables that are only visible within the scope. Such scoping is shared by all nested activities, including other scopes.
Fault handling may be localized by using scopes. Faults may be caught and handled within a scope, or may be passed up to the enclosing scope if not caught.
Compensation—undoing the effects of previously completed activities—is perfomed at the scope (or process) level.
Scopes can handle events such as incoming messages and alarms triggered by set times or durations. These events are handled concurrently with the normal activity being executed by the scope.
Correlation sets, which are used to bind incoming and outgoing messages to a particular BPEL process instance, may be declared local to a scope.
There is one more feature of the scope activity that is not
described here:
the attribute variableAccessSerializable. For information
about
that, see Serializable Scopes.
Why Use Scopes?
Scopes are useful for partitioning your BPEL process into logical units of work. They provide benefit as an organizational and documentation tool.
Scopes are also good for isolating units of work. Each scope can handle its own faults and can be compensated after it has completed normal execution.
XML Syntax and Semantics
<scope variableAccessSerializable="yes|no" standard-attributes>
standard-elements <variables> ... </variables>? <correlationSets> ... </correlationSets>? <faultHandlers> ... </faultHandlers>? <compensationHandler> ... </compensationHandler>? <eventHandlers> ... </eventHandlers>? activity </scope>
The variables, correlationSets,
faultHandlers, compensationHandler, and
eventHandlers elements are all optional, which is
signified by
the "?" in the abbreviated XML syntax above.
Standard attributes and elements
The standard-attributes are name,
joinCondition, and suppressJoinFailure. The
name
attribute is used by compensation handlers to identify scopes.
The standard-elements are source
and
target, used when linking activities together.
Attributes
The variableAccessSerializable attribute is covered in
Serializable Scopes.
Variables
Within the variables element you may declare local
variables. Local variables are visible only in the scope in which
they are
defined and in all scopes nested within that scope. It is possible to
"hide"
or "mask" a variable declared in an outer scope by declaring a variable
with
the same name and same type in an inner scope. It is illegal to declare
a
variable in an inner scope with the same name but a different type.
Correlation sets
The correlationSets element contains correlation set
definitions local to the scope.
Fault handlers
The faultHandlers element contains zero or more
catch elements and an optional catchAll
element.
There must be at least one catch or catchAll
element.
Once a scope receives a fault, normal processing of all nested activities are halted.
Whenever a fault handler is not present or no catch or catchAll is selected for a given scope, then a default fault handler is implicitly created. The default behavior is to rethrow the fault handler to the parent scope. This process continues until the global process scope is reached.
When a scope rethrows a fault, the scope itself ends abnormally and all outgoing links are set with a negative value. If the fault occurs in (or is rethrown to) the global process scope and there is no matching fault handler, then the process terminates abnormally.
Compensation handler
The compensationHandler element defines an activity
that may
be used to run BPEL code that undoes a previously-completed unit of
work. The
unit may be a (possibly named) scope, a single invoke, or the entire
process.
A compensation handler may only run after its scope has completed normally.
Event handlers
The eventHandlers element contains onMessage and/or
onAlarm
elements. It must contain at least one onMessage or onAlarm element.
The event
handler runs concurrently with the main execution path of the scope. It
has
access to all process-level and scope-level variables. The event
handler is
enabled when the scope starts execution and is disabled when the scope
completes.
Activity
As mentioned previously, a scope contains exactly one activity. That activity may be a structured activity, which implies that scopes may encompass arbitrarily complex behavior.
Deploying the Process
Running the Process
See Running the Samples.
The
service name to use is scopeProcessService. The sample data file
orderMessage.xml can be used as input for this example.
The reply
will contain the string "Inner scope value".
Copyright © 2004–2006 Active Endpoints, Inc. - All Rights Reserved