Almost any application that you write will involve a workflow wherein a process involves people and process steps that requires people to act on each of the process steps. Some of these processes are completely automated and primarily involve communication between applications. However some other processes rely on people to initiate, approve different steps in the process, and resolve any exceptional situations that arise, and more. In those cases, you can specify a discrete series of steps as a workflow to describe the activities of the people and software involved in the process. Once you define a workflow, you can easily build an application around this definition to support the business process. This article will focus on at the basics of Windows Workflow Foundation by discussing its architecture, key building blocks that make up Windows Workflow Foundation. This article will also provide a simple example that shows how to create a simple workflow using Visual Studio 2005. After that, it will explore the steps involved in passing parameters to a workflow from a hosting application.
Prerequisites
To follow along with the examples throughout this article series, you need the following installed on your system:
- .NET Framework 3.0 - Because
Windows Workflow Foundation is built on top of this, you need the .NET Framework 3.0 installed for runtime functionality. Windows Vista comes with the .NET 3.0 Framework out of the box as long as you select this option at the time of installing Windows Vista. If you are running an operating system other than Windows Vista, you need to install the .NET Framework 3.0.
Visual Studio 2005 (any edition) - Required for workflow development.
Windows Workflow Foundation extensions for Visual Studio 2005 - Available for download from Microsoft.
Introduction
Windows Workflow Foundation is a core component of .NET Framework 3.0, that provides developers with a common framework for building workflows. Prior to the introduction of WF, flow charts used for documenting the software were separate from the code developers wrote based on those flow charts. Since both of these were managed separately, evolution of one really left the other one out of date. With the introduction of WF, you now have a workflow technology where in the workflow itself is an executable component and is made up of different activities with each activity representing a piece of logic that can be in the form of a conditional activity, web service invocation activity and so on. Because of this, you can easily extend the workflow to meet the ever-changing needs of the business.
What is a Workflow?
A workflow can be defined as the movement of information, documents, and tasks through a working process with different actors playing different roles along the steps in the workflow. Through WF, you can describe, visually design, and program algorithms to create workflows not only for Windows applications, but also for any kind of system using the embedded SOAP Web Services. By using Visual Studio 2005, you can create the workflows in addition to creating the constitutive parts (known as workflow activities) that make up a workflow.
Workflows are a set of activities. An activity can be defined as a smallest piece of action that the flow employs. An activity can be anything from a straightforward action to a composite action that consists of an assembly of several activities. They can be aggregated to a workflow by using the workflow visual designer supplied with Visual Studio 2005. Activities can also be sequential, as the whole workflow itself, where the order of the steps is predetermined at design time, or it can be event-driven, where the order of the actions is determined at run time in response to external events, as in the case of state machine workflow.
Different Types of Workflow Supported by WF
There are two main kinds of workflows that can be implemented through WF.
- Sequential – In this workflow, actions are executed in some predefined order with a beginning and an end. For example, when you are installing software, the installation goes through a sequence of steps to complete the installation.
- State machines: As the name suggests, this workflow doesn’t have a path and is represented as a set of states and transitions between states. For example, in a e-commerce site you may need different types of states depending on user details. For some users, they need to pay via credit card and for some users, they may need a PO and for some users, you could use the persisted credit card details to pay for the transaction.
Architecture of Windows Workflow Foundation
The below diagram shows the architecture of WF highlighting the key building blocks that make up WF.

The object model of the WF provides the classes, methods, and properties to program against the WF engine. Through this rich object model, you can start, stop or a query a workflow. More advanced tasks, such as controlling the state and modifying a workflow at run time, are also possible through the rich object model. WF is made up of the following key building blocks:
- Base Activity Library – Contains the library of out-of-box activities and base classes for custom activities. The included activities provide functionality for communication with services and applications, control flow, event handling, conditions and looping, and state management. In addition, some activities can also act as a container for other activities. For example, activities such as exception handlers, compensation, and event handlers can host every kind of activity. In addition to the base activity library, you can also build custom activity libraries through the extensibility features of
WF. The Visual Designer allows you to construct work flows using a rich graphical and code-based editor.
- Runtime Engine – Provides workflow execution and state management.
- Runtime Services – Provides hosting flexibility and communication. Note that the
WF has no intrinsic execution processes; instead, it is an in-process engine that runs in a host process. The host process provides the set of services needed for the lifecycle of the workflow.
Workflows typically run within a host process with a host being any .NET application or server. Any application that can execute workflows of the WF and manage their lifetime (start, stop, pause) can be considered as a host. As an example, any application (like a console application, Windows application, ASP.NET application, Windows service) that can execute managed code on the .NET Framework can execute workflows and be a host. The host is in charge of initializing the workflow and has control over its lifetime, messaging, and configuration-related tasks.
Implementation of a Simple Workflow
To start with, create a new project using Visual Studio 2005. In the New Project dialog box, select Workflow under the Visual C# node in the Project types pane and select Sequential Workflow Console Application as the template in the right pane. Name the project HelloWorldWorkflow as shown below:

After the project is created, select View->Solution Explorer from the menu so that you can examine the files within the project. The Workflow1.cs file is the workflow itself, and the Program.cs file contains the .NET code that starts the application. The following sections discuss both files.
The Workflow Class
Open the workflow by double-clicking Workflow1.cs in the Solution Explorer if it is not already open. The document is labeled Workflow1.cs [Design] in the document view area of Visual Studio. Just as with ASP.NET Web forms, you can use a code-beside model to create workflows. Through the code behind, you can keep the workflow design separate from code. To see the .NET code that is behind the workflow, right-click on Workflow1.cs in the Solution Explorer and select View Code. The following code is displayed:
Note that the Workflow1 class is derived from the System.Workflow.Activities. SequentialWorkflowActivity class. For the purposes of this example, let us add a simple line of code to display a message box from the workflow. You can accomplish this by adding a Code activity to the workflow.
Next, drag the Code activity from the Windows Workflow section of the Toolbox onto the design surface of the workflow. The Code Activity is arguably the most utilized activity for programming custom algorithms in the workflow because it permits adding code handlers everywhere in the workflow. This activity enables developers to insert .NET code (such as C# or VB.NET code) into the workflow and this code gets compiled together with the code-behind of the workflow. For the purposes of this example, drag the Code activity between the start step and the stop step. Rename the Code activity to displayHelloWorld by selecting View->Properties Window from the menu.
Now if you look at the work flow, you will see a red circle with an exclamation point in the upper-right corner of the Code activity. This indicates that an action required for the Code activity has not yet been set. In this case, the ExecuteCode property has not been set for the Code activity. To solve this, you need to wire a handler to the ExecuteCode event (the same way you wire an event handler in a Windows Forms application in Visual Studio). To accomplish this, double click on the empty text area right next to the ExecuteCode property in the properties window and that will take you to the code editor with the following code populated.
In the above code, let us add a line of code to display a simple message box. To display a message box, you first need to add reference to the System.Windows.Forms assembly through the Project->Add Reference menu. After that, add the below line of code to the displayHelloWorld_ExecuteCode event handler.
Now build the project to make sure that everything is working fine. Now that you have created the workflow, let us discuss the code required to host the workflow.
Hosting the Workflow
To invoke a workflow from a hosting application, you need to go through the following steps:
- Create an instance of a
WorkflowRuntime object and wire its WorkflowTerminated and WorkflowCompleted event handlers.
- Workflows are always executed asynchronously within workflow bounds. For that reason, you use a wait handle to tell the program to finish when the workflow is completed. You perform this within the
WorkflowCompleted event handler.
- Next create an instance of a
WorkflowInstance object by invoking the WorkflowRuntime.CreateWorkflow() method passing in the type of workflow as an argument.
- Finally you initiate the workflow by calling the
WorkflowInstance.Start() method.
If you open up the Program.cs file from the solution explorer, you will see the following hosting code that is auto-generated at the time of creating the project.
The event handler for WorkflowCompleted is an Anonymous method. Anonymous methods are features of C# that enable developers to create inline code that typically exists in a method. This feature is usually used with small amounts of code.
By default, the WF runtime engine will execute the workflow asynchronously, which is not desirable in this simple example. To avoid that, you block that thread through a AutoResetEvent object and wait for workflow to complete.
Because of the AutoResetEvent, the thread will be blocked until it is set in the WorkflowCompleted event handler.
Now you are ready to run the project. To test it, press F5. The code should compile, and a console window should appear with the output message box displaying the below output.

Passing Parameters to a Workflow
In this example, let us build on the previous example and see how to pass parameters to a workflow. To be able to pass parameters to a workflow, you need to go through the following steps:
- Declare the parameters in the workflow class as public properties. Through getters and setters, you can control whether a parameter is read-only or write-only or both.
- Inside the workflow, write code to process the parameters passed into the workflow.
- From the host application, pass the parameters to the workflow in the form of a
Dictionary<string, object> collection. You pass this collection object to the WorkflowRuntime.CreateWorkflow() method as its second argument.
To start with, add the following lines of code to the Worlflow1 class.
Modify the displayHelloWorld_ExecuteCode() method to display the value contained in the Name property as well:
Now open the Program.cs and modify the Main() method to pass the Name parameter to the workflow. To pass parameters to a workflow, you instantiate a Dictionary<string, object> and add the required parameters using its Add() method.
For reasons of brevity, the above code only shows the code required to supply parameters to the workflow. Once the Dictionary<string, object> is created, you add the parameters by calling the Add() method supplying the parameter name as well as the value for that parameter. After adding all the parameters, you pass that parameter collection to the CreateWorkflow() method as the second argument.
Here is the output produced by running the application.

Conclusion
Although the examples presented in this installment were simple, they covered some key points. First, you learned how to implement a workflow using Visual Studio 2005. After creating the workflow, you saw the steps involved in invoking the work flow from a standard .NET Windows forms application. This Windows forms application is referred to as a host. In addition, you were introduced to a very important piece of the workflow framework, known as activities. Activities are the reusable building blocks for composing workflows. The next installments in this series will get into more advanced features of WF including invoking a Web service from a WF, creating a custom activity, and invoking a workflow from another workflow and so on.
Downloads
WindowsWorkflowFoundationPart1 (Visual Studio Project)
About Thiru Thangarathinam
 |
Sorry, no bio is available
This author has published 4 articles on DotNetSlackers. View other articles or the complete profile here.
|
You might also be interested in the following related blog posts
WPF 4 (VS 2010 and .NET 4.0 Series)
read more
Announcing the WebsiteSpark Program
read more
GiveCamps Get a new Sponsor
read more
Foxit PDF Previewer update
read more
More On The CodePlex Foundation
read more
My History of Visual Studio (Part 6)
read more
Scenarios for WS-Passive and OpenID
read more
My History of Visual Studio (Part 3)
read more
My History of Visual Studio (Part 2)
read more
SOA Patterns presentation on E-VAN (recording)
read more
|
|
Please login to rate or to leave a comment.