Unit 17: Flow Activity

BPEL Fundamentals, Part 2
Unit 17: Flow Activity

BPEL Fundamentals
This is Unit #17 of the BPEL Fundamentals course. In past Units weve looked at
ActiveBPEL Designer, Workspaces and Projects, created the Process itself and
then declared our Imports, PartnerLinks and Variables and then we created
Interaction Activities in various ways. Next, we looked at the Sequence activity,
Assignments and Copies and then we studied Correlation, Scopes and Fault
Handling. In our last five units we examined Compensation, Event Handling,
Termination Handlers and the If activity, which allows us to do conditional
processing and finally at the rest of the BPEL Basic activities. In this Unit we'll look
at BPEL's Flow activity, which is the third of our container activities, after the
Sequence and the Scope.
Copyright 2004-2007 Active

Endpoints, Inc.
Unit Objectives
At the conclusion of this unit, you will be familiar

with:
Flow activity
Simple concurrent processing
Process Modeling using flows and links
Transition conditions
Join conditions
Dead-path elimination
Copyright 2004-2007 Active Endpoints, Inc.

Endpoints, Inc.
BPEL Structure Roadmap

process
Global Declarations
Structured Activities
flow
forEach
if
pick
repeatUntil
scope
Process
Definition
sequence
while
Basic Activities
In this unit well look at the Flow activity, which is used for concurrent processing,
and how it uses links and transition conditions. The Flow is a structured activity and
is part of our BPEL process definition. The use of links will lead us logically to
consideration of Join conditions and dead path elimination. Weve dealt with
activities that implement program-like structures until now, but with Flow we can do
graph-like structures.

Endpoints, Inc.
flow Activity Overview and Syntax
Used to define a set of activities that will execute

concurrently
Most fundamental use of this construct
Further allows expression of synchronization

dependencies between activities
Control flow defined by a network of links
<flow standard-attributes>
standard-elements
<links>?
<link name="ncname">+
</links>
activity+
</flow>
A Flow defines one or more child activities that execute concurrently, which is the
most basic use of this construct. The Flow activity also allows us to synchronize
activities, such that one activity starts when another ends. On this slide we can see
the syntax, and we see that you can optionally define one or more links, which must
have names that are unique within their scope.

Endpoints, Inc.
flow Activity Semantics
Directly nested activities are started concurrently

as soon as the flow activity is started
flow activity completes when all nested

activities complete
All directly nested activities within a Flow are started at same time. The Flow
completes when all of its nested activities are complete.

Endpoints, Inc.
Unit Objectives

with:
9Flow activity
Join conditions

Endpoints, Inc.
Simple Concurrent Processing
In a business process it is typical to have

activities running in parallel
Improves response time
Increases productivity
flow construct can be used to perform

concurrent processing
Flow activities allow us to perform parallel processing. So, if there are no

dependencies among them, we can perform multiple activities at same time. This
concurrent processing improves response time, increases efficiency, etc. And, just
a word about concurrent or parallel processing. This is, of course, going to be
engine-dependent, but this will not affect the User or the way their process
executes, because the time differences between any two engines implementations
are so minor from a human timescale point of view - as to be meaningless in most
cases.

Endpoints, Inc.
Simple Concurrent Processing Scenario
Sequence
Flow
Invoke
Invoke
Invoke
Here we have a Sequence with a Flow that has two directly nested Invoke
activities, and a third invoke following the flow.
1.) First, the Sequence starts.
2.) Then the Flow starts.
3.) Then the two Invoke operations are executed - in parallel - as soon as
the Flow is started.
4.) If the invokes are using a request/response pattern, for example, the
Flow will complete when both Invokes have received their Replies.
5.) The third Invoke will then be fired immediately after the Flow completes.
6.) The original Sequence completes.

Endpoints, Inc.
Simple Concurrent Processing Example
<sequence>
<flow>

<invoke partnerLink="Seller" ... />
<invoke partnerLink="Shipper" ... />
</flow>
<invoke partnerLink="Bank" ... />
</sequence>
Here is the syntax for the example on the previous slide. There is an outer
Sequence and then there are two Invokes each directly nested under the Flow.
Notice that there are no links between the Invokes. This means that they will
execute in parallel because they are both direct children of the Flow activity. Once
both of the Invokes in the Flow have completed, the Invoke of the bank partnerLink
will be executed. When that Invoke is complete, then the Sequence is complete.

Endpoints, Inc.
Isolated scope
Provides concurrency control in governing access

to a common set of shared resources including:
Variables
PartnerLinks
Control links
Ensures there will be no conflicting situations

among several concurrent isolated scopes
Behaves as if scopes were executed in sequence, one
after another, rather than concurrently
10
Set the optional scope attribute isolated to

"true" to mark a scope as isolated
Isolated scopes are use to control the access to global variables, partnerLinks and
control Links, which can result in different values as each of the Scope's activities
access them. Isolating a Scope means there will be no conflicting values among
the Scopes executing activities. If the Isolated attribute is set to TRUE, then they
are executed in a defacto sequence, not in parallel. This involves the concept of
"serializability."
DEFINITION: Serializable
1.) The intuitive meaning (and mathematical definition) of "serializable" execution is
that any two successfully committed concurrent transactions will appear to have
executed strictly serially, one after the other although which one appeared to
occur first may not be predictable in advance.
2.) In databases and transaction processing, schedule (transaction history) is
serializable, has the Serializability property, if its outcome (the resulting database
state, the values of the database's data) is equal to the outcome of its transactions
executed sequentially without overlapping. Transactions are normally executed
concurrently (they overlap), because it is the most efficient way. Serializability is
considered the highest level of isolation between transactions, and plays an
essential role in concurrency control.

Endpoints, Inc.
10
Isolated scope Scenario

process
<variable name="x" type="xsd:string"/>
Flow
isolated="true"
isolated="true"
2*
1*
Assign
'foo' to variable x
Assign
'bar' to variable x
Invoke
Invoke
* The order in which isolated scopes are executed is random

11
Here is a typical example using Isolated Scopes. A Variable from outside the Flow,
called x with the type string (as defined in the Standard Schema), is declared.
Then we have a Flow activity, which has two directly nested and Isolated Scopes. Both Scopes contain an Assign activity that writes to variable x, but with
different values. If x is used during the execution of the two parallel Invoke
activities, the values for x could be different in each case.

Endpoints, Inc.
11
Isolated scope Example

<process ...>
<variables>
<variable name="x" type="xsd:string"/>
</variables>
<flow>
<scope isolated="true">
<assign>
<copy>
<from>"foo"</from>
<to variable="x"/>
</copy>
</assign>
<invoke ... />
</scope>
<scope isolated="true">
<assign>
<copy>
<from>"bar"</from>
<to variable="x"/>
</copy>
</assign>
<invoke ... />
</scope>
</flow>
</process>
12
Here we see the syntax for the example seen on the previous slide. We start with a
Process-level variable declared as x of the string type. The Primary activity for
the process is the Flow. Inside the flow we have two Scopes with the Isolated
attribute set to TRUE." Each contains an Assign activity with a single Copy
Operation.

Endpoints, Inc.
12
Unit Objectives

with:
9Flow activity
9Simple concurrent processing
Join conditions
13

Endpoints, Inc.
13
Two Approaches for Process Modeling

Program-like structure
Control flow defined by
sequences, loops and branches
sequence
Graph-like structure
Control flow defined by a network
of links
flow
basic activity
basic
activity
loop (while condition is true)

basic activity
basic activity
structured
activity
basic
activity
basic
activity
basic
activity
if
condition 1
basic
activity
14
condition 2
basic
activity
else
basic
activity
Now that we understand how a Flow works, and we understand the concept of
Isolated Scopes, we can look at two different approaches to process modeling:
Sequence vs. Flow. On the left is a typical programming-style structure, with a
single path of execution. On the right is a Graph-like structure that has a series of
links, and notice that the programming-style structure on the left does not.
Note: The programming style on the left comes from Microsoft's contribution to the
BPEL language and the graph-like structure on the right comes from the IBM
contribution to the BPEL language.

Endpoints, Inc.
14
link Overview and Syntax
Connects the completion of one activity to the

execution of another activity
link prescribes the potential flow of control

between activities in a flow
<flow>
<links>
<link name="ncname">+
</links>
...
</flow>
15
A Link connects the completion of one activity to the start of another activity. The
purpose of a link in a Flow is to make the potential execution of the Flow
conditional, i.e., based on the logic and values contained in the Link's conditions.

Endpoints, Inc.
15
link Scenario
Control flow using a link

Flow
Invoke A
Invoke B
16
Here, by using a Link, we turn a Flow into a Sequence, in effect. Invoke A will
execute first, and upon its completion the Link will be evaluated and if its conditional
resolves to TRUE then Invoke B will be executed.

Endpoints, Inc.
16
link Example
Control flow using a link

<flow>
<links>
<link name="AtoB"/>
</links>
<invoke name="A"/ >
<sources>
<source linkName="AtoB"/>
</sources>
</invoke>
<invoke name="B">
<targets>
<target linkName="AtoB"/>
</targets>
</invoke>
</flow>
17
Here is the syntax for the example we saw on the previous slide. It starts with a
Flow activity, which has a Links section (one or more must be declared if a Links
section is used.) We can name a Link anything we want, but here we are calling the
first link AtoB." There are two Invokes in the Flow, each with the standard
attributes and elements. The first Invoke A is the source of the link AtoB." The
second Invoke B is the target of the link AtoB." When declaring a Link, the
Source element and Target element define where the link begins and ends and are
used to control the flow of execution within the enclosing activity.

Endpoints, Inc.
17
link Semantics
link is defined separately and must be

uniquely named within the flow activity
Standard source and target elements of an

activity are used to connect two activities
An activity can be the source of one or more links and
an activity can be the target of one or more links
Each link MUST have exactly one activity within the
flow as its source and exactly one activity within the
flow as its target
18
Target activity can be performed only after the

source activity has completed
Here are the semantics of our Links. Links only apply to the Flow activity. Links
must be uniquely named within the Flow. The purpose of a link is to control the
order of execution. Each link must have exactly one source and exactly one target.
However, mutliple links can leave and enter a single source or target, provided that
they are coming from or going to separate and distinct activities. The target activity
of a Link will not commence until the Source activity of the link is complete.

Endpoints, Inc.
18
Linking Multiple Activities
19
Allows for a convenient way to quickly link

multiple activities within a flow
So, how do we Link activities when working in the Designer? Recall that Links can
only be used in a Flow activity. Simply select the activities in the desired execution
order, and then use the Right Mouse context menu and select Link Activities.

Endpoints, Inc.
19
Implicit flow Activity
ActiveBPEL Designer automatically creates a

flow activity whenever multiple activities are
placed on the canvas where only a single
primary activity is expected
flow activity is not visually displayed in the canvas
20
In ActiveBPEL Designer, there is an implicit Flow activity created in the background

if two or more activities are dropped onto the canvas without any Sequence, Scope
or Flow container. The reason is because Designer doesn't know which order to
execute them in, so it adds the Flow to the source code in order to keep it "legal."
Note that this implicit Flow is not displayed on the canvas graphic, but it is in the
Source code, if you switch to the Source tab. When we created the first two
interaction activities of our process (the original Receive and Reply activities),
Designer created an implicit Flow in the background, but we didn't know that yet.

Endpoints, Inc.
20
Unit Objectives

with:
9Flow activity
9Process Modeling using flows and links
Join conditions
21

Endpoints, Inc.
21
Transition Condition Overview
Determines whether or not an outgoing link is

traversed
Boolean expression that is associated with an

activity's source element
If true, the link receives a true status
If false, the link receives a false status
<activity>
<sources>?
<source linkName="ncname">+
<transitionCondition expressionLanguage="anyURI"?>?
bool-expr
</transitionCondition>
</source>
</sources>
...
</activity>
22
Transition conditions can only apply to a Link within a Flow activity. These
conditions determine whether or not the Link is traversed, and the condition
expression must evaluate to a boolean value to be valid. Here the transition
condition is for the Source end of a Link, and can therefore be called an outbound
link condition.

Endpoints, Inc.
22
Transition Condition Overview
transitionCondition attribute on the

source element contains the boolean
expression
Links are not required to have a transition condition
z
23
If omitted, a default value of true is used
Properties can be used in

transitionConditions
BPEL also defines the $<variableName> syntax

that extracts values from variables
Links within a Flow activity do not have to have explicit transition conditions. If they
dont, they have an implicit transition condition whose default value is TRUE. A
property value can be used in a transition condition, and we are allowed ot use the
$variable syntax style in our transition conditions.

Endpoints, Inc.
23
Transition Condition Scenario

Flow
order total <= 500
order total > 500
Invoke A
Invoke B
Invoke C
Invoke D
24
Here is a typical Transition condition scenario. The Flow activity starts and Invoke
A complete its actions. Once the Invocation of A is complete, we can evaluate
order total to fire either Invocation B or Invocation C. Based on the "order total"
value, one Invoke (i.e., B or C) or the other is chosen, fired and completed, followed
by the Invocation of D." Note that whichever one of B or C is not traversed will
never be traversed.

Endpoints, Inc.
24
Transition Condition Example

<flow>
<links>
<link name="AtoB"/> <link name="AtoC"/> <link name="BtoD"/>
<link name="CtoD"/>
</links>
<invoke name="A" ...> <sources>
<source linkName="AtoB">
<transitionCondition> $order.ordTotal <= 500 </transitionCondition>
</source>
<source linkName="AtoC">
<transitionCondition> $order.ordTotal > 500 </transitionCondition>
</source>
</sources> </invoke>
<invoke name="B" ...>
<targets> <target linkName="AtoB"/> </targets>
<sources> <source linkName="BtoD"/> </sources>
</invoke>
<invoke name="C" ...>
<targets> <target linkName="AtoC"/> </targets>
<sources> <source linkName="CtoD"/> </sources>
</invoke>
<invoke name="D" ...>
<targets> <target linkName="BtoD"/> <target linkName="CtoD"/> </targets>
</invoke>
</flow>
25
Here is the syntax for the transition condition example we saw on the previous slide.
The declarations for the Links are first, and here we have four of them: AtoB,
AtoC, BtoD, CtoD. The first invoke, A, is the source for two links: AtoB and
AtoC. Each of these two Links has a transition condition based on the value of
$order.ordTotal. The next invoke, B, is the source for one (BtoD), and a target
for one (AtoB). The next invoke, C, is the source for one (CtoD), and the target for
one (AtoC). And finally, the last invoke D is the target for two links: BtoD and
CtoD.

Endpoints, Inc.
25
Fork Activity and Concurrent Processing
Fork Activity
Source activity that has more than one outgoing link
All links whose transition conditions evaluate to true
will be followed
Concurrent Processing
Achieved whenever two or more outgoing links
evaluate with a true transition condition
Activity
Activity BB
Activity
Activity A
A
Activity
Activity C
C
26
The Fork activity is conceptual only. There is no actual Fork activity on the
pallette. A Fork activity is any activity that has more than one outgoing link. If two
(or more) transition conditions that each evaluate to true, then all of the target
activities at the end of those Links are executed concurrently.

Endpoints, Inc.
26
Unit Objectives

with:
9Flow activity
9Transition conditions
Join conditions
27

Endpoints, Inc.
27
Join Activity and Synchronization
Join Activity
Conceptual term identifying a target activity that has
more than one incoming link
Does not start until the status of all its incoming links
have been evaluated
Synchronization
Achieved whenever two or more incoming links
evaluate with a true link status
Activity
Activity BB
Activity
Activity D
D
Activity
Activity C
C
28
Now we look at the Join activity. Much like the Fork activity, a "Join activity" is a
conceptual term. This term applies when one activity is the target for more than one
link. Note, of course, that there is no actual Join activity, but there is a join
condition attribute which like transition conditions - must evaluate to a Boolean
value. For example, here activity D has two inbound links, making it a Join
activity. Activity D wont be executed until all incoming transition conditions to the
activity are evaluated. Because of this behavior, joining two paths is often called
synchronization.

Endpoints, Inc.
28
Join Condition Overview
Exists to specify requirements about one or more

paths reaching a target activity
Determined by the link status of the incoming link(s)
Boolean-valued expression associated with an activity
that has incoming links, and comprised of only
z
BPEL-defined $<linkName> syntax

Returns a value of true, false or unset, depending on the status of
the link
Boolean operators (OR, AND)
If not explicitly defined, then the status of at least

one incoming link has to be true
Note that an activity with even one incoming link will have
an implicit join condition
29
Join conditions exist to specify whether one or more paths will reach a target
activity. This is determined by the status of all of the activity's incoming links. Each
Link evaluates to True, False or Unset and, because these resolve to Booleans,
we can also use OR and AND in our expressions. Note that if the status of a Join
Condition is not explicitly defined, it is an implicit join condition. The status of at
least one incoming link to a given activity MUST be true.

Endpoints, Inc.
29
Join Condition Overview
true
false
$L1 and $L2

Activity
Activity A
A
30
Here is a Join Condition overview example. (This is an animated slide.)

1.) Activity A is a Join activity, i.e., it has a join condition and is the target for more
than one inbound link. Here it is the target for two links $L1 and $L2." We
evaluate all of the links to evaluate the activitys join condition, using the boolean
expressions defined for them.
2.) This particular Join evaluates to False, because both links must evaluate to
True in order to get a True condition. Because $L2 evaluates to False and the
condition is based on an "And" then the entire condition evaluates to False.

Endpoints, Inc.
30
Join Condition Scenario

Flow
Invoke A
Invoke B
Invoke C
true
true
$BtoD and $CtoD
joinCondition
Invoke D
31
Here is a typical Join condition scenario. We have a Flow activity, with an Invoke
"A" as its primary activity. Invoke "A" is the source of two links, one to Invoke "B"
and one to Invoke "C." Each of the Invokes "B" and "C" are the source for links that
go to the target, Invoke "D." In this case, we wont execute Invoke D unless both
Invoke B and Invoke C execute successfully.

Endpoints, Inc.
31
Join Condition Example

<flow>
<invoke name="A" ...>
<sources>
<source linkName="AtoB" /> <source linkName="AtoC" />
</sources>
</invoke>
<sources> <source linkName="BtoD"/> </sources>
</invoke>
<sources> <source linkName="CtoD"/> </sources>
</invoke>
<invoke name="D">
<targets>
<joinCondition>"$BtoD and $CtoD"</joinCondition>
<target linkName="BtoD"/> <target linkName="CtoD"/>
</targets>
</invoke>
</flow>
32
Here is the syntax for the previous example. We are inside a Flow, and Invoke "A"
is source of two links: AtoB and AtoC. Invoke B is the source of one link and the
target of one link, as is Invoke C. Invoke D is a target of two links and has a join
condition to evaluate the status of those links. In this case, both BtoD and CtoD
must evaluate to TRUE for Invoke D to execute.

Endpoints, Inc.
32
Join Condition Builder
Assists in creating an explicit joinCondition

expression for any activity that is the target of
one or more links
Must show Advanced

properties
33
Now let's take a look at how to use the Join condition builder when working in the
Designer. First, select the target activity, click on "Show Advanced Properties," and
then create the expression using the Join Condition Builder. (Note: you must click
in the Join Conditions Value field in order to make the ellipsis icon visible and
enabled.) Once you are in the Join Condition Builder dialog, you must first choose
to use either the default expression language or select another one. The Join
Condition itself is constructed using the data in the three panes: Links (which shows
only those in scope), Functions and Operators. We can double-click on a Link to
add it to the Join Condition, and then follow that with whatever Functions and
Operators are appropriate to construct our Join Condition. Note that you can also
edit the Join Condition's textfield manually, if you wish to do so.

Endpoints, Inc.
33
Suppressing Join Failures
When a joinCondition evaluates to false

By default, a standard joinFailure fault is thrown
Suppressing Join Failures

Instead of throwing a joinFailure fault the activity
would simply not be performed without any fault
thrown
Standard attribute suppressJoinFailure

Associated with any basic or structured activity
If not set, the value is inherited from a parent container
34
Next we'll look at the "Suppress Join Failure" setting. This is set at the scope level,
but can be overridden. When a join condition evaluates to False a joinFailure fault
is thrown. We can either handle the fault or suppress it using the attribute
suppressJoinFailure. (Note: if you have one link and its condition evaluates to
False, it will always throw a joinFailure fault.) "SuppressJoinFailure" is a standard
attribute, and can be associated with any basic or structured BPEL activity. If this
value is not explicitly set, it is automatically inherited from its parent container, which
can be a scope, sequence or process, for example.

Endpoints, Inc.
34
Suppressing Join Failure Scenario

Flow
order total <= 500
order total > 500
Invoke A
Invoke B
Invoke C
Invoke D
35
Note that this is an animated slide.

1.) In this scenario we have an enclosing Flow activity, which has an initial Invoke
activity that is the Source for two links, one to Invoke B and one to Invoke C. Since
the Transition Conditions for AtoB and AtoC are mutually exclusive, only one of the
two links will be traversed.
2.) So, in this case Invoke C, or Invoke B, depending on the execution, will never
execute. Now, because one of the two second-level Invokes will never execute 3.) the Join Condition for Invocation C will fail, because the Link will never be
traversed and the Invoke activity will never execute. Note that, as we stated earlier,
an activity with even one link will have an implicit join condition, and if the single link
is not traversed then the condition must fail.
So in this case, we need to suppress the Join Failure on Invocation C, not
Invocation D.

Endpoints, Inc.
35
Suppressing Join Failure Example

<process suppressJoinFailure="no">
<flow suppressJoinFailure="yes">
<invoke name="A" ...> <sources>
<source linkName="AtoB"> <transitionCondition>
$order.ordTotal <= 500
</transitionCondition> </source>
<source linkName="AtoC"> <transitionCondition>
$order.ordTotal > 500
</transitionCondition> </source>
</sources> </invoke>
</invoke>
</invoke>
<invoke name="D" ...> <targets>
<target linkName="BtoD"/> <target linkName="CtoD"/>
</targets> </invoke>
</flow>
</process>
36
Here is the syntax for the "SuppressJoinCondition" example on the previous slide.
We are inside a process with the value set to "no" and then we are inside a Flow
where the value is set to "yes." Invoke A has two links, to Invokes B and C, with the
transition conditions and target activities shown. There are also links from both
Invokes B and C to Invoke D.

Endpoints, Inc.
36
Unit Objectives

with:
9Flow activity
9Transition conditions
9Join conditions
37

Endpoints, Inc.
37
Dead Path Elimination
Needs to occur whenever it becomes clear

during execution that a particular activity will
never be performed
Traverses the underlying flow until the next join

activity or end activity is reached
Propagates the false link status along entire paths until
a join condition is reached that evaluates to true
38
Next, we'll take a look at Dead Path Elimination. This happens at execution time, as
the system evaluates the flow of execution and checks to see if there are any paths
wont be traversed, meaning that there are activities that will not indeed cannot be traversed for execution. The system automatically fills in the Link status to the
value of False, as appropriate.

Endpoints, Inc.
38
Dead Path Elimination Scenario

Flow
order total <= 500
order total > 500
Invoke A
Invoke B
Invoke C
Invoke D
Invoke E
39
Let's examine the same scenario, but with some new links. If the value of order
total is less than or equal to 500, the Path on the right side - a-c-d-e - will never be
executed during this run.

Endpoints, Inc.
39
Dead Path Elimination Scenario

Flow
order total <= 500
order total > 500
Invoke A
Invoke B
Invoke C
false
Automatically
propagates a false
link status
true
Invoke D
false
Invoke E
40
The system knows this and automatically propagates a False status to all the Links
down the entire Dead path.

Endpoints, Inc.
40
Lab 12 flow activity and flow modeling
Overview of Lab Exercises

Perform audit and check credit service concurrently
Use flow modeling concepts to model remaining order
process
Add appropriate transition conditions
Add two global fault handlers
Use an empty activity as a place holder for "work to
be done"
41
The next Lab in the BPEL Fundamentals class is Lab #12. (Note: This is lab #4 if
you are taking BPEL Fundamentals II.) In this lab we will add a Flow activity after
the initial Receive activity in order to perform an Audit and a Credit Check
concurrently. We'll use the concepts we just learned to re-order the remaining
Order Process by adding Link transitions where needed. Then, we'll add two Global
Fault handlers, add a Throw activity and finally, we'll use the Empty Activity as a
placeholder.

Endpoints, Inc.
41
Unit Summary
Now you are familiar with:

Flow activity
Join conditions
42

Endpoints, Inc.
42

Unit 17: Flow Activity

Uploaded by

Copyright:

Available Formats

You might also like

Unit 17: Flow Activity

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 17: Flow Activity

Uploaded by

Copyright:

Available Formats

BPEL Fundamentals, Part 2