Microsoft & .NET.NETBuilding a Practical Application with Windows WorkFlow Foundation

Building a Practical Application with Windows WorkFlow Foundation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In the previous article I provided a theoretical introduction to Microsoft Windows WorkFlow Foundation; in this part the practical applications will be sketched out.

Windows WorkFlow Foundation is one of the core components of the WinFX .NET Framework wave from Microsoft. It provides a singular engine to ensure the workflow execution for all Microsoft applications in the Windows platform. The Foundation consists of a set of tools to enable programmers and users to create workflows; the working engine and the Object Model that permit developers to interact programmatically with the system.

The First Step: Programming a WorkFlow; a Basic Approach to the Code-Behind

Because Visual Studio is Microsoft’s default developing tool for all the Windows products, it is also the most powerful tool to develop WorkFlows. After installing the WorkFlow Foundation runtime in the developing machine, it is necessary to install the “2005 Extensions for Windows WorkFlow Foundation” (the software can be downloaded from the Microsoft .NET FrameWork 3.0 site, formerly WinFX; at the time of writing, in Beta 2.2). The software includes project templates, intellisense support for the WorkFlow namespace (System.Workflow) and integrated documentation.

Developing a WorkFlow in Visual Studio is equally effortless as developing an aspx or Windows application: select Activities from the provided Base Activity Library (BAL) that includes a number of fundamental activities, connect them, and write the specified code. This works in the same way as selecting and adding Web or Windows controls. Visual Studio 2005 provides a graphic tool (the WorkFlow Designer) that allows you to define graphically the shape of the WorkFlow, the participant activities and the order of execution. Figure 1 shows a Sequential WorkFlow in the Visual Studio 2005 Designer (central panel), the Tools Panel with the Activities Library (left panel) and the project and properties panels (on the right side).

Figure 1: The Visual Studio Designer

A typical WorkFlow paradigm begins with an initialization situation, which in this case is a decisions branch (IfElseBranchActivity). The relatively simple example WorkFlow follows an approval process of a document to be published. The initial condition determines if the document concerned pursues a Refusal or a Publishing process (Editorial_Work/Publication_Queue/Publication) and finally, the conclusion of the WorkFlow is a notification to the author.

The example uses various “Code Activities” (Editorial_Work, Publication, and Refusal), an “ifElseBranchActivity” (Approvation), a “Delay Activity” (Publication_Queue), and one “InvokeWebService Activity” (Author_Notification)

The WorkFlow defines two properties at the beginning of the code:

private string_authorName;
public string AuthorName
   get { return _authorName; }
   set { _authorName = value; }

private int _numberOfWords;
public int NumberOfWords
   get { return _numberOfWords; }
   set { _numberOfWords = value; }

These properties will be the input parameters that define the principal characteristics of the document to be published.

The ifElseBranchActivity and the Refusal Activities show a red marker at the right corner to indicate that the Activities are not properly configured. In the case of the Refusal Activity, IntelliSense indicates that the “Property ‘execution code’ is not set”; this property can be changed in the Properties panel. In the code-behind, events are defined for the Code Activities:

private string _authorName;
private void EditorialWork_Handler(object sender, EventArgs e)
   //This method does Editorial Work in the document,
   // for example, converts a Word document to HTML

private void Publication_Handler(object sender, EventArgs e)
   //This method can send the document to the printer queue
   // or publish it in a Content Manager System

private void Refusal_Handler(object sender, EventArgs e)
   //This method can send the document back to the author or
   // start a back-end process for Administration Work

The Code Completion capabilities of Visual Studio 2005 allow you to choose the method to define the property from the callable methods.

The ifElseBranchActivity needs a definition for the condition (therefore the exclamation red mark). The Designer offers a special window to define the condition where IntelliSense and Code Completion are activated. This is shown in Figure 2.

Figure 2: The Conditions Editor

It also is possible to define a method in the code-behind (that returns true or false) to be connected to the condition branch. In this case, first it is necessary to define the method in code, and thereafter the Code Completion will indicate the method to be selected.

The Delay Activity defines a predetermined waiting period before the WorkFlow resumes the execution. The Delay Activity can be used to await a response from external processes or people. If the delay is going to be for a long time, the runtime engine can “Dehydrate” the WorkFlow (the idle WorkFlow instance will be unloaded from memory and written to a persistent store), and “Rehydrate” it (load the WorkFlow back from the store and assign a thread to be executed on) after the expiration time. This mechanism allows a WorkFlow instance to be idle for a long period without using server resources and insures that the system survives machine reboots.

Finally, the Author_Notification is an “InvokeWebService Activity” that makes a call to an external “SendEmailWebService” (a proxy in the example). This Activity can realize any kind of work, for example—and as the name indicates—sending an e-mail using SMTP or Exchange.

The Next Step: Using a WorkFlow; Object Model, WebServices

Each WorkFlow needs a Host to reside in, as explained in Part I. For the sample WorkFlow, you can use a Windows application that initializes the process, sets the required properties and, eventually, displays the resultant status.

The FrontEnd of the Windows application allows you to specify the value of the two WorkFlow properties and contains one button to initialize the process (See Figure 3).

Figure 3: Windows FrontEnd Application

Note: Because this is a test program, there are no validations for the input or other kinds of code to prevent failures. The first step is set references to the following: System.Workflow.Activities, System.Workflow.ComponentModel, and System.Workflow.Runtime namespaces, making it possible to work with the Object Model of the WorkFlow Foundation. Additionally, a reference must be set to the newly created WorkFlow assembly that will be initialized and used in the code.

It is not actually necessary, but very convenient, to set a statement for “using System.Workflow.Runtime” (in C#) or “Imports System.Workflow.Runtime” (in Visual Basic) at the beginning of the code-behind file. Following this, a global variable for the Runtime object is declared:

Private WorkflowRuntime _myWfRuntime;

The code for the event handler of the button:

private void btnBegin_Click(object sender, EventArgs e)
   //Instance of WorkflowRuntime
   if (_myWfRuntime == null)
      _myWfRuntime = new WorkflowRuntime();

   Dictionary<STRING, object> WfParameters =
      new Dictionary<STRING, object>();
   WfParameters.Add("AuthorName", txtAuthorName.Text);
   WfParameters.Add("NumberOfWords", txtNumberWords.Text);

   WorkflowInstance WfInstance =
      (Jupiter_WorkflowConsoleApp.Workflow1), WfParameters);

The event handler of the button initializes the instance of the global WorkFlow Runtime variable if it does not exist; it also uses a Generic of the type Dictionary to declare and hold the values of the parameters for the WorkFlow. Furthermore, it declares a variable of the type WorkFlowInstance that creates the real WorkFlow in the engine, using the method “CreateWorkflow”, with the referred WorkFlow and its initialization values (given by the Generic) as parameters. Finally, the instance uses the method “Start” to begin the WorkFlow process.

Because only one instance of the WorkFlow can be used at a time, it is necessary to release the activated objects. The event “FormClosed” can be used for this purpose:

private void Form1_FormClosed(object sender, FormClosedEventArgs e)
   if (_myWfRuntime != null)
      if (_myWfRuntime.IsStarted)

Note: For test purposes, the methods of the WorkFlow have been changed to write the status of the Activities to a text file. The WebService is also modified in the same way. From this site the source code for all components can be downloaded.*

To test the WorkFlow, simply run the assembly of the test program with values for the “Author” and “Number of Words” parameters, and the outcome of the process can be followed in the output log file as shown in Figure 4.

Figure 4: Output of the test program

If the “Number of Words” parameter is between 1000 and 2000, the WorkFlow follows the “Publishing” path, otherwise, the “Rejecting” path will be followed. Finally, the WebService is called with a “Message” parameter, and the parameter is written in the log file.

When the WorkFlow is concluded and tested, Visual Studio allows the developer to create an installation package with different possibilities: publication to a Web Server, to a shared file path, or to a stand-alone installation for distributable media. Additionally, it is possible to make the WorkFlow updatable using the Microsoft “OneClick” deployment technology, which automates the publishing of the application, letting users install the software and minimizing the impact of software rollouts.

A second method of publishing is by creating a WebService of the whole WorkFlow. Visual Studio consents to the construction of Web services from the WorkFlow project using a Wizard. The Wizard takes care of the correct configuration of IIS, creates the appropriate proxys and copies the files to the necessary directories.

Beyond the WorkFlow: Integrating WorkFlows into Other Applications (SharePoint, Office)

With the WorkFlow Foundation, Microsoft is creating a unified workflow framework for all its products. Until now, each Microsoft server has had its own WorkFlow engine. For example, the Human WorkFlow of BizTalk is well known, but CRM also boasts its own WorkFlow engine; and finally, SharePoint 2003’s engine, though very flexible, lacks ample power.

The Office 2007 family of products, and specifically Windows SharePoint Server 2007, will be the first Windows software that integrates the WorkFlow Foundation into the core of the system. For the first time, a Microsoft server (SharePoint 2007) will be able to use the engine of the Foundation as an external paradigm, enabling not only SharePoint Lists and Libraries, but also individual documents inside a Library, to work as a host for a WorkFlow instance.

Because SharePoint is well integrated with all the products of the Office family, individual Office components such as Word and InfoPath are capable of initializing and using WorkFlows utilizing the WorkFlow implementation within SharePoint. Specially created to customize SharePoint, the SharePoint Designer (formally known as FrontPage) is a new Office product and can be used to ensemble WorkFlows for implementation by SharePoint.

There are two ways to initialize a WorkFlow from SharePoint: launched manually by a user or configured to run automatically when a document or item is changed or created. It is also possible to define a WorkFlow for a complete Library or arrange it in such a way that each item has its own WorkFlow. In any case, it is necessary to choose the WorkFlow from the repository of available templates.

Figure 5: Initialization of a WorkFlow from a document in SharePoint 2007

After configuration and initialization, the status of the WorkFlow instance is visible on the List and Item windows and a complete reporting system reveals the statistics of the WorkFlows in use in Excel.

Figure 6: WorkFlow report of activity from SharePoint 2007

The SharePoint Designer sanctions users to create, configure, and install WorkFlows for SharePoint 2007. The WorkFlows can be assembled using the Lists and Fields of the present site as input conditions and can manage different tasks as output actions.

Figure 7: SharePoint Designer creating a new WorkFlow for SharePoint 2007

The SharePoint Designer interface is markedly different from the Visual Studio Designer and the possibilities are less extensive. For example, it is not possible to design and program Activities and State Machine Workflows. However, SharePoint generates a fully functional Sequential WorkFlow where the conditions are defined using the WorkFlow Foundation rules engine. Another limitation of the SharePoint Designer is that it restricts using the created workflow with Libraries or Lists other then for its original instance. A further disadvantage is that the user cannot modify WorkFlows while the program is in use.

That said, it makes the learning curve for non-technical users less pronounced because of the ease of using the Wizard and the fact that the deployment is realized automatically by the tool.

If Word 2007 is installed in a computer with a connection to SharePoint 2007, it is possible to associate a Word document directly with a WorkFlow.

Figure 8: WorkFlow started from Word 2007

The Wizard will configure the Workflow for selected actors (other SharePoint users), and allows the user to determine the time to complete the process and set the values of the variables to be initialized. The chosen actors will receive an e-mail that announces their participation in the WorkFlow.

Because WorkFlows can be initiated and finalized with WebServices, each program or automated software process that can interact with SOAP WebServices can be used as a host for a WorkFlow. This opens up the potential for integration with any kind of software and back-end process. Visual Studio 2005 contains the infrastructure to publish the WorkFlow directly to a Web Server, if necessary.

Sample Code

The sample source code used in this article is available for downloading. To install and use the code, Visual Studio 2005 must be installed together with the Windows WorkFlow Foundation runtime components and the Visual Studio 2005 Extensions for Windows WorkFlow Foundation. The code was created using the Beta 2.2 version of the Foundation; this can be accessed from the Microsoft site (

The sample solution consists of the WorkFlow project “Jupiter_WorkflowConsoleApp” with its test program “TestWorkFlow” and the Web Service “SendEmailWebService” projects. Each project contains the source code and the generated assemblies.


Our daily lives revolve around a series of activities, decisions, and rules that can be grouped in an organized way within a WorkFlow. WorkFlows exist everywhere; the programming world is no exception. In a traditional programming pattern, the instructions that describe and execute a WorkFlow are integrated into the logic of the program itself, thus making it cumbersome to maintain and re-use. The Windows WorkFlow Foundation provides the framework to build workflow-enabled applications that can be hosted in almost any software environment.

With these two articles, the theoretical and practical basics of the Windows WorkFlow Foundation have been introduced. Hopefully, the example displayed will prick the imagination and stimulate readers to take the plunge to program and employ of a WorkFlow of their own.

About The Author

Gustavo Velez, MCSD, is a Senior Application Developer for Winvision (, a Microsoft Gold Partner in the Netherlands, with many years experience in developing Windows and Office applications, and more than three years of daily programming experience with SharePoint. He also is Webmaster of, the only Spanish-language dedicated SharePoint site.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories