BPMN Embedded Sub-processes

Lab #1 – Page 1 of 8 - ActiveVOS Fundamentals
ActiveVOS Fundamentals
Lab #5
BPMN Embedded Sub-processes
Copyright © 2004-2011 Active Endpoints, Inc.
Lab #1 – Page 2 of 8 - ActiveVOS Fundamentals
Lab Plan
In this lab we will learn about BPMN’s Embedded sub-processes. Embedded subprocesses – called Scopes in BPEL – are the main building blocks of a process. They
are each treated as a logical unit of work and are the means by which we build our
processes in a hierarchical structure. They can also be used to implement other process
logic, such as fault handling and event handling, as we will see later.
Lab Prep
Before starting make sure that:
- you have completed Labs 1-4.
Lab Steps
Use a simple Embedded Sub-process
1. Go to the class resources and import the ActiveVOS_5_EmbeddedSubprocess
project.
2. Open the SimpleEmbeddedSubProcess process file. Examine the process
definition. This process begins when it takes in a simple string as the input and
writes it into a variable called Consumer Request. It ends when it sends a simple
string as output to the caller using a variable called ConsumerResponse.
3. From the palette open the Control Flow tray, drag an Embedded Sub-process onto
the canvas and drop it into the sequence after the Receive Input event. An
embedded sub-process is a complex activity, i.e., one that can contain other
activities and events. Embedded sub-processes can be nested to any arbitrary
depth to create hierarchical process structures. Each one must contain simple start
and end events, but beyond that they can be simple or very complex. Once they are
on the canvas, we can display them three different ways.
4. Right-click on the scope you dropped into the process. Choose Collapse Container
to reduce the scope to a single rounded rectangle. This menu item works like a
toggle to collapse and expand the scope. Use right-click and Expand Container to
return it to its original condition.
Copyright © 2004-2011 Active Endpoints, Inc.
Lab #1 – Page 3 of 8 - ActiveVOS Fundamentals
5. You can also use the “drill-down” feature of the canvas to drill into the sub-process
and display it in a child level diagram on its own canvas. Collapse the container and
click on the plus icon to see the child sub-process displayed. Using this structured
modeling technique means we don’t need a 20 foot long drawing taped to the wall of
our office to see the whole process. Click on the breadcrumb links starting in the
upper left corner to return to higher levels in the process.
6. Embedded sub-processes can be used to demarcate functional boundaries within the
organization and to make clear who has responsibility for each of the different parts
of the entire process. These containers can define the boundaries of department or
entity actions within the organization, while still maintaining the integrity of the entire
process. The screenshot below shows the process from a high level, while still
allowing us to drill into any scope and see more of the details within each, as
needed. See if you can build this sequence on your own:
7. Sub-processes are normally defined within the end-to-end process definition. If a
sub-process is going to be called by multiple processes, you can model that process
externally, and then invoke it with a standard web service Call from the parent
processes that use it. (Note that when you call an external process you have to pass
data to it, but if it is embedded, it will use data from the parent process.) In the
diagram below, the Finance sub-process is defined externally, deployed to the server
and then called from multiple processes, including this one. We will see how to do
this during our implementation labs later in the week.
Copyright © 2004-2011 Active Endpoints, Inc.
Lab #1 – Page 4 of 8 - ActiveVOS Fundamentals
Use a Looping Embedded Sub-process
1. Go to the BPEL folder and open the LoopingEmbeddedSubprocess file. Examine
the process until you understand it. Pay special attention to the input message that
starts the process. Right-click on the SubmitOrder operation and use the Open
menu item to see the message’s details in the WSDL editor or the text editor.
2. Go to the Control Flow tray of the palette and drag and drop a Loop into the process
sequence in between the default start and end events. Call the Loop Check Items
Against Inventory. The Loop artifact on your canvas is implemented as the BPEL
While loop. It uses a conditional expression to repeat the block of code inside the
scope as long as the conditional expression remains true. This artifact can be
expanded and collapsed like any other embedded sub-process.
3. We can insert patterns and artifacts from the palette into the sub-process to define
the sequence(s) that the loop will execute. Add an Conditional Pattern to the loop.
Label the gateway If In Inventory. Label one path In Inventory and one path Not In
Inventory. It will look like this:
4. Finally, we add the activities and events to each of the two paths. Drop a Service
Task into the In Inventory path and call it Add Item to Count. Drop another Service
Task into the Not In Inventory path and call it Notify Warehouse. Your process will
look like this:
Copyright © 2004-2011 Active Endpoints, Inc.
Lab #1 – Page 5 of 8 - ActiveVOS Fundamentals
5. As with any Embedded Sub-process, we can collapse the container to display it as a
Complex Task. The + sign on the task signals us that it is not just a simple task of
some kind, but that there is a nested sub-process defined inside the container.
Use a Multi-Instance Embedded Sub-process
1. Go to the BPEL folder and open the MultiInstanceEmbeddedSubprocess file.
Examine this process until you understand it. This process uses the same
SubmitOrder operation as the previous process that used the While loop.
2. In this part of the lab we’ll again iterate through the list of products that the customer
is buying and we’ll check and see whether they are in our inventory list. (One of the
major difference between using a While type Loop and a Multi-Instance loop is that a
multi-instance loop can be executed in parallel, so that all of the iterations execute
simultaneously. This can dramatically improve the speed of execution, although it
does require more resources to do so.) Drag a Multi-Instance artifact from the
Control Flow tray of the palette and drop it into the sequence. Call it Check Items
Against Inventory. Drop a None End event from the Throw Event tray. The
sequence should look like this:
Copyright © 2004-2011 Active Endpoints, Inc.
Lab #1 – Page 6 of 8 - ActiveVOS Fundamentals
3. The order we received has a list of products that the customer wants to buy. It is a
repeating node with each node defining a product in the order. We need to find out
how many items are in the list before we can iterate through it. Select the multiinstance and go to the Property view. Set the Start Counter Value to 1. This is the
start value of the loop. Open the ellipsis to the right of the Final Counter Value to
open the builder. The Final Counter Value is the final value of the loop, so the Start
and Final values will control the number of iterations of the loop.
(Final Counter Value – Start Counter Value) + 1 = number of loop iterations
4. In the builder we will use the Count function under Node Sets on the Functions
pane. We will apply it to the Item element of the SubmitOrderRequest variable,
which is the list of products, implemented as a repeating XML node.
5. Now we need to check each product against our inventory. For simplicity, we’ll just
do a simple check of each item’s Part Number. Use a Conditional Pattern with an
expression that uses an index to check each product in the list. In each iteration of
the loop there is a local variable called counter. This is how we can tell which
iteration of the loop we are in. We’ll use the counter variable, enclosed in square
brackets to define it as an index, like this:
$SubmitOrderRequest / ns11:items [$counter] / ns11:item / ns11:partNumber = 'RND32050'
Copyright © 2004-2011 Active Endpoints, Inc.
Lab #1 – Page 7 of 8 - ActiveVOS Fundamentals
6. Now that we have looped through the list of items and determined which ones are in
stock, we need to set flags in response to these values. Create Script Tasks to set
the values as appropriate. Add one Script Task to each of the two paths. Label one
Set Found Flag and one Set Not Found Flag. Label the Conditional Pattern
branches to complete the process.
7. To complete the process we have to create the two flag variables and then define the
copy operations for each of the two script tasks. Go to the Outline view and right
click on the Variables node. Select Add / Declaration / Variable.
8. In the dialog select the Schema Type radio button and xsd:Boolean for the type.
Click OK.
9. Call one variable Found and one NotFound. No spaces allowed in variable names.
Copyright © 2004-2011 Active Endpoints, Inc.
Lab #1 – Page 8 of 8 - ActiveVOS Fundamentals
10. In the Set Found Flag script task, create a copy operation that sets the variable value
to true.
11. In the Set Not Found Flag script task, create a copy operation that sets that value to
true.
12. Simulate the process and pay special attention to the Debug view and the
execution of the Multi-instance sub-process.
13. One you have simulated the process successfully, go to the Multi-instance’s property
sheet and enable the Parallel Execution Flag. Simulate again and notice the
difference in the execution tree of the Debug view.
Copyright © 2004-2011 Active Endpoints, Inc.