How to Choose Your Workflow Model in WF

7/30/2019 How to Choose Your Workflow Model in WF

1/9


msdn.microsoft.com/en-us/library/cc768563.aspx

How to Choose Your Workflow Model in

WF22 out of 25 rated this helpful

Jon Flanders, PluralSight

July, 2008

Applies to:

Microsoft Windows Workflow Foundation

Microsoft .NET Framework 3.0 or later

Different applications require different execution models. Some programs are quick to execute, while others

may take weeks or months. Some programs have very specific steps for execution with little or no room for

deviation from its set path; other programs are more flexible, reacting to user actions to make decisions,

changing execution paths depending on context.

Windows Workflow Foundation (WF) is a programming model, set of tools, and runtime environment that

allows you to write declarative workflows on the Windows platform to represent the execution model of your

programs. The WF runtime is part of the .NET Framework, first appearing in .NET Framework 3.0, with

improvements in .NET Framework 3.5 to more naturally integrate with Windows Communication Foundation

(WCF).

WF programs typically model a process made up of work steps known as activities, which are implementations

of the Activity type (specifically, System.Workflow.ComponentModel.Activity). To create WF workflows, we

configure one or more activities provided with WF, usually along with custom activities, and connect them in

some configuration that creates a workflow that expresses this process and satisfies the needs of our

particular application.

At run time, the WF execution model also centers on the Activity type. The execution engine of WF, the

WorkflowRuntime, knows only about the Activity type: it knows how to create, execute, and manage the lifetime

of Activity instances. Conceptually, this Activity is expressed as either simple activities to execute simple tasks or

composite activities to execute more complex tasks.

Simple activities (often referred to as leaf activities) can do things like execute arbitrary code, write data to a

database, send an e-mail, or run a rule set. Composite activities are activities that dont have a specific execution

behavior, but rather execute their children in a well-known manner, controlling the flow of the workflow. A

simple example could be a composite activity that executes two children: a child that sends an e-mail, and

another that writes a file to the file system. In most cases, we create and run composite activities.

WF itself ships with many composite activities, all of which can be executed by the WorkflowRuntime directly. It

also ships two special composite activities, which are often called Root models. These two activities are

SequentialWorkflowActivity and StateMachineWorkflowActivity.It is important to note at this point that, although


2/9



,

these two activities over any other Activity. In fact, to the WorkflowRuntime all activities are the same, which is

why I have placed Root in quotes. Well discuss this concept again later in this article, but the main focus of

this article is to help you decide the question, What Root workflow model is right to solve my problem? This

article assumes you have some basic knowledge of WF.

SequentialWorkflowActivity

The first of the two Root models that ships with WF is named SequentialWorkflowActivity (which well refer to

as SequentialWorkflow for the rest of this article). For most developers, SequentialWorkflow is the easier of thetwo Root models to understand. Simply put, the SequentialWorkflow executes all of its children, one at a time,

in sequential order from the beginning to the end of the workflow, much like a function that executes lines of

code in the order they appear.

Figure 1: A SequentialWorkflow

Figure 1 represents an example SequentialWorkflow. Of the activities that make up the workflow, the green

activities in the workflow are the simple or leaf activities, activities that execute some functionality important

to our application. Notice that there is at least one flow-control Activity, the built-in IfElseActivity, which allows

our workflow to conditionally execute different child branches of the IfElseActivity based on its condition

evaluating to true or false.

Understanding the actual problem this workflow is meant to solve isnt necessary to understanding how it

executes. We can break down this workflow into its possible execution paths. We know, based on the design of

this workflow, that there are two possible execution paths.


3/9



,

right branch of the IfElseActivity executes. This branch has no activities as children, so we get to the end of the

workflow. There are no more children activities left to execute, so the workflow completes. You can see this in

Figure 2.

Figure 2: Execution path one.

The other potential path executes the first leaf Activity and the condition of the IfElseActivity evaluates to true.

This causes the left branch of the IfElseActivity to execute, which has another Activity (a leaf) which then

executes. After this Activity completes, the branch has no more children to execute, and returns control to its

parent, the SequentialWorkflow itself. The SequentialWorkflow has no other children to execute, so it

completes. This path is highlighted in Figure 3.

These two execution paths of the workflow were predefined at design time. That is the essence of the

SequentialWorkflow model: it has a top-to-bottom execution path, with all the potential execution paths

dictated by the design of the workflow itself.


4/9



Figure 3: Execution path two.

The typical reason for picking the SequentialWorkflow as your Root model is that you want the workflow tobe able to dictate the execution path of the application. This model sets all of the potential execution paths of

the workflowat design time, providing the application with no choice at runtime but to follow these paths,

removing such situations as an Activity at the bottom of the workflow to cause the workflow to go back to the

first leaf Activity. But activity execution is not required to occur in one time-slice.

WF is built to natively support both short-lived and long-running workflows, and the SequentialWorkflow model

supports both as well. It is easy to think of a SequentialWorkflow as a function that executes from top to

bottom in one time-slice, but in reality the SequentialWorkflow can pause and restart based on conditions

in the workflow and in the application, unloading and loading the workflow instance from memory, and can be

triggered by time delays or events.

In the workflow in figures 2 and 3, the workflow is specifically written to wait for potentially long periods of time

for either the first or second approval. The leaf activities for this workflow (DoWork and DoMoreWork)

implement the IEventActivity interface, which classifies them as what is generally called Event activitiesactivities

that are built specifically to wait for messages from the host application. These activities can cause the

workflow to pause and even be unloaded from memory while it is waiting for the incoming message (assuming

you have configured a PersistenceService with your WorkflowRuntime).

StateMachineWorkflowActivity

The other Root workflow model that ships with WF is the StateMachineWorkflowActivity (which well call

StateMachineWorkflow for simplicity). In contrast to the SequentialWorkflow, the StateMachineWorkflow has amuch more flexible and event-guided execution model.

The StateMachineWorkflow is modeled as a collection of discrete named states, having one active state at a

time. These states can contain one or more activities that derive from StateActivity. ,. When a state is the active

state, it can listen for one or more events to be raised when it is modeled using an Activity that implements the

IEventActivity. After an event is raised (usually by a message sent by the host application), a sequence of one or

more activities can be executed to respond appropriately. As part of the sequence, a SetStateActivity is usually

executed to transition the workflow from to another state. Each state can also contain a StateInitializationActivity

and aStateFinalizationActivity, which act like a state constructor and destructor respectively.


5/9



StateMachineWorkflow instance starts, it immediately transitions to the state designated as the Initial state.

When the StateMachineWorkflow instance transitions to the Completed state, this will cause the instance to

complete.

You would choose to implement a StateMachineWorkflow if you need flexibility in the execution of your

workflow. It is generally thought that the StateMachineWorkflow model is appropriate when the application or

the users of the application determine how the workflow executes at run time. Since states can be transitioned

to and from again, the workflow can execute the activities in a StateMachineWorkflow repeatedly.

Figure 4 demonstrates a simple StateMachineWorkflow.

Figure 4: StateMachineWorkflow

In this example, the MyInitialState is the initial state, which is indicated by the green icon next to its name

(configured by setting the InitialStateName property of the StateMachineWorkflow). Inside of this state, there is

a single child, the StateInitializationActivity, and an arrow from the stateInitializationActivity1

StateInitializationActivity, indicating that the workflow is being transitioned to the ChildState using a

SetStateActivity. This illustrates that, although a StateMachineWorkflow is generally a wait-and-execute type of

model, it can transition between states without messages being received.

The StateMachineWorkflow can also implement a concept known as recursive workflows. This is demonstrated

in our example above: the ChildState state is contained inside of the ProcessingState. When a recursive state is

implemented, the parent state is listening for events (which might be things like meta-events) at the same time

as the child, although the parent state can never be the active state, and only one child at a time can be

active.

And whenever a child is active, the parent event is also active and listening. In this example, the ProcessingState

has one event ( ListenForCancelEvent), which serves as a meta-event to handle the more generalized events

that are of interest to the child eventsin this case, listening for a signal from the application that the


6/9



.

states inside of ProcessingState, but the state contains only the ChildState state to keep it simple. In addition to

listening for the cancellation event, the ChildState state also listens for the ListenForMainEvent event to signal

that work is to be done.

The ChildState state has two transition arrows, one that goes to the CompleteState, and one that recursively

returns back to the ChildState state. This means that the state can transition along one of these two paths when

the state is signaled to change by SetStateActivity. The CompleteState has been configured as the Completed

state on the workflow (configured by setting the CompletedStateName property of the StateMachineWorkflow).

Inside of the ListenForMainEvent, we can assume there is a set of activities that, when executed, determines

from the incoming message whether to complete the workflow. If the answer is no, the SetStateActivity sets the

state to ChildState again; if the current approval is sufficient, the SetStateActivity will set the state to

CompleteState.

If the workflow transitions to the CompleteState state, the StateMachineWorkflow knows that it is done, and it

completes and notifies the WorkflowRuntime. If the workflow transitions along the recursive transition, the

workflow transitions back to the ChildState again, which causes the active state of the workflow to continue to

be the ChildState, and the workflow will be waiting for the ListenForMainEvent event again (as well as the

ListenForCancelEvent because of the recursive states).

As you can see, the StateMachineWorkflow model provides a lot more flexibility at run time than the

SequentialWorkflow model, allowing you to create as complex of a workflowas is necessary to support your

modeled process. The StateMachineWorkflow will generally be chosen over the SequentialWorkflow model

when the workflow requires either flexibility at run time in your application or when your application can be

more naturally modeled as a set of states.

Custom Root Models

Another point that must be made about WF Root models is that the two models provided with WF are not

the only Root models that WF supports. The Windows Workflow Foundation WorkflowRuntime processes only

instances of the Activity class, and doesnt know anything at all about either the SequentialWorkflow or

StateMachineWorkflow. It knows how to create, initialize, execute, and manage the lifetime of an Activity

instance. As composite activities of the base Activity class, SequentialWorkflow and StateMachineWorkflow

contain all of the necessary logic about their respective execution models to execute as these two models.

SequentialWorkflow and StateMachineWorkflow are, therefore, two composite Activity models that are

intended to cover a large percentage of application workflow scenarios. WF makes it clear that those two

models might not cover all application scenarios, and allows for the creation of other custom composite

activities. To make a custom composite Activity your Root model, all you have to do is decide that it will be

your Root; there arent any special interfaces or any special configuration that is necessary for your

composite Activity to be the Root model.

As an educational exercise, I once created a Root Sequential model that executes the child activities in a

random order. While this is totally useless in the real world, it does illustrate the flexibility and extensibility of

the WF model.

But there are real-world examples of when you might want to create a custom Root activity. One example that

I like to use is a case where we needed to unify disparate, event-driven processes into a larger, much more

deterministic process. In this case, the StateMachineWorkflow model was the natural model for the individual

business processes, but they needed to be unified into a coherent end-to-end process (or multiple coherent

end-to-end processes).

Thiswas accomplished by creating a custom Root Activity that is a Sequence, executing a design-time


7/9



workflow from top to bottom, but where the leaf activities are actually StateMachineWorkflow instances,

servicing the event-driven individual processes.This isnt supported out of the box because there is no way to

configure a StateMachineWorkflow as a child of a SequentialWorkflow, but it is possible to create such a model

with a little coding because the WorkflowRuntime has no hardcoded notion of either the sequential or state

machine execution models.

Sample Scenario: Document Workflow

Lets imagine a real application scenario and apply what weve learned so far. Bob, a developer at Contoso, is

tasked with building an application that executes a document workflow. After meeting with the business owners

and gathering the requirements, Bob goes back to his desk and models the workflow using Visio (shown in

Figure 5).

Figure 5: Document approval workflow in Visio

The business rules for this application (agreed to in the meeting that Bob has just attended) are that after a

document is received to be processed, the program is to wait for an approval from a manager. The manager

has the option of asking for another manager to confirm the approval of the document. So the flow of the

workflow will be either (a) to wait for one approval and then be done, or (b) to get the first approval, wait for

another approval, and then be done.

Bob has decided to use WF to implement the logic of this application, so he goes about picking the Root

model he wants to use. Since the paths of his application logic are well defined, and it seems like the more

natural model to him based on his experience, he picks the SequentialWorkflow model for this Root

model.Figure 6 shows what his workflow designer in Visual Studio looks like for the project.


8/9



Figure 6: Sequential Document Workflow

This will execute exactly as the SequentialWorkflow example introduced earlier did. After the first approval

activity executes, one of the two paths of the IfElseActivity will execute. If there needs to be an additional

approval, the left branch will execute the workflow, will wait for another approval message, and, once that

message is received, the workflow will complete. If there isnt a need for another approval, the workflow will

execute the right branch of the IfElseActivity, which is empty, and then the workflow will complete.

Bob completes this model, deploys his application, and documents start passing through his system. In a short

amount of time, however, the business owners come to Bob and ask for a small change. Now they would like

to have one, two, or three approvals. Returning to his desk and looking at the designed workflow, Bob could

add another IfElseActivity to his SequentialWorkflow model, or add a looping Activity like While to his design,

but he decides he should create something with a little more flexibility.

He decides to rework his design into a StateMachineWorkflow, which you can see in Figure 7.

Figure 7: StateMachine Document Workflow

By changing his workflow to use the StateMachineWorkflow model, Bob has introduced slightly more

complexity, but the model is generally more flexible and capable of adjusting to the user needs. Now he can

place the necessary application logic inside of the ListenForApproval EventDrivenActivity, which can handle

changes in the business, instead of having to change the workflow, creating a complex chain of nested

IfElseActivity activities. This model is more reactive to the application, rather than controlling the application


9/9


msdn microsoft com/en us/library/cc768563 aspx

(like the SequentialWorkflow model).

Summary

Once youve made the decision to adopt WF inside of your application, the next decision you need to make is

what kind of Root workflow youre going to use.

WF ships with two Root models, the SequentialWorkflow and the StateMachineWorkflow. These two models

cover most if not all of your Root model choices (again, Root is in quotes because the WorkflowRuntime

has no notion of a Root; to the WorkflowRuntime, an Activity is an Activity). As a general rule, you can think ofthe SequentialWorkflow model as being appropriate for deterministic processes, where the workflow is more

constrained and dictates the next action, and the StateMachineWorkflow model as being appropriate for

event-driven processes that allow the user or the application to dictate what the workflow does next.

Additionally, if you find that neither of the two models provided with WF fit your needs in terms of execution

model, remember that you can also easily build your own composite Activity model and use that as your

Root.This is part of the extensibility of WF that makes it a long-term viable platform for building applications.

2013 Microsoft. All rights reserved.

Documents

How to Choose Your Workflow Model in WF