Working with Windows Workflow Foundation in ASP.NET

September of 2005, Microsoft unleashed Windows Workflow Foundation (Windows WF) at its semi-annual Professional Developer's Conference. As one of the pillars of the WinFX APIs, Windows WF provides developers with a common framework on which to develop process driven and workflow-centric applications.

Currently, when organizations wish to automate business processes the standard answer is to assemble a team of developers to write the appropriate code. While this approach has generally served organizations well, it has some inherent problems. To understand why, you need to understand some fundamental characteristics of a workflow.

A workflow is essentially a way of documenting the activities involved in completing a unit of work. Typically, work "flows" through one or more activities during processing. These activities can be performed by either machines or by people, and can be as simple as defining the sequence of pages in an Internet application, or as complex as managing documents or products that must be seen, altered, and approved by any number of people.

Because so many workflows must allow for human involvement, they can take long periods of time to complete, ranging from hours to months or longer. For example, people involved in the process may be unavailable, out-of-town, or busy with other tasks; therefore, workflows must be able to persist themselves during periods of inactivity. Furthermore, processes implemented solely using code can be difficult for non-technical people to understand and for developers to change. This and other factors are the target of generic workflow frameworks such as Windows WF, which aim to make creating, altering, and managing workflows easier, both by giving them a visual interface and by defining a common API.

You can host Windows WF workflows in any type of .NET application, including Windows Forms, console applications, Windows Services, and ASP.NET Web applications. Each type requires special considerations. While examples that showcase hosting workflows in Windows Forms and console applications are already plentiful, this article focuses on issues facing ASP.NET developers who wish to integrate workflow into their applications.

Windows WF and the MVC Pattern

One common way in which you might use Windows WF in an ASP.NET application is to implement a Model-View-Controller (MVC) approach. Essentially, the goal of MVC is to separate the presentation layer, application logic, and application flow logic from each other.

To illustrate how this would be useful in an ASP.NET application, consider a help desk ticket workflow scenario. A business user starts the workflow by filling out an ASP.NET Web form and clicking a submit button. Next, a server notifies a help desk employee using a Windows Forms application that a new ticket is available. The help desk employee would then work on the problem, and eventually close the ticket. If this workflow scenario were developed using Windows WF, all the process logic and flow could be contained in the workflow itself, and the ASP.NET application would need to know nothing about the logic.

This scenario provides some solid evidence that separating presentation from logic is a good thing. Because the process of handling help desk requests is common, if the logic were implemented using C# or VB.NET code in several different .NET applications, you'd run the risk of duplicate code or worse, different implementations of the same business process in completely different code. But if you implement the process in Windows WF, the developers of applications that need the process would need to modify the steps in only one place—the workflow itself—without worrying about changing logic in their applications. Code duplication and the ambiguity of where to implement process can be mitigated with Windows WF.

When implementing the MVC architecture in ASP.NET using Windows WF, developers should attempt to build workflows independent of the applications in which they will be hosted. This will assist in keeping logic separate from presentationand maintain a high degree of independence between the order of workflow steps and page flow in the Web application.

A novice Windows WF developer might be tempted to develop a workflow with a set number of activities in a certain order and afterward, develop a set of ASP.NET Web forms that flow from one to another in the same order. Unfortunately, while that seems logical, it's counterproductive, because you would be implementing the workflow logic twice. Web page X should not need to know whether it needs to go to Page Y or Page Z to implement the workflow steps correctly. Instead, the workflow (the model) should tell ASP.NET (the controller) what the next step is, and then ASP.NET should determine which page (the view) to display. In this way, each page requires little knowledge of the overall process; it only needs to know how to complete one distinct activity and let the workflow worry about how the pages flow from one to the next. This separation provides developers with a great deal of flexibility related to the order of page flow. For example, if you decided to change the page display sequence, you could easily do that in the workflow, without changing one line of code in the ASP.NET application.

A Simple Workflow MVC Example To demonstrate this idea, I'll show you a simple ASP.NET application and workflow. The oversimplified workflow describes a process that collects some personal information from an external application, and then displays it. Here are the steps:

1. Call a method that signifies a request for a person's name; the workflow uses the InvokeMethod activity (see Figure 1).
2. Wait until an event is fired signifying the receipt of a name; the workflow uses the EventSink activity for this step.
3. Obtain an e-mail address from the host using a similar call.
4. Wait for an event signifying the receipt of the address.
5. After receiving both the name and e-mail address the workflow launches an InvokeMethod activity to send the personal data to the calling application. This last step does not make much sense in a real-world scenario. More likely, you'd call a Web service to send the data to some other system, or place it into a database.

To implement this workflow in ASP.NET you need a page to collect a person's name, a page to collect the email address, and a page that displays the personal data. Remember, the data entry forms should know nothing about what has happened before or what happens next. The same goes for the display page. However, the ASP.NET application has to somehow know which page to display to the user; this where the controller comes in. This example uses an HttpHandler to implement the solution. The custom handler, called WorkflowControllerHandler, deals with the following tasks:

• Obtaining a reference to the workflow runtime.
• Obtaining a reference to or starting a new workflow instance (depending on whether a workflow instance is already started).
• Setting up communications between the controller and the workflow.
• Handling events from the workflow.
• Telling ASP.NET which page needs to be displayed depending on which stage in the workflow is currently being executed.

As you can see, the custom handler essentially takes care of all the dirty work related to Windows WF and page control, letting the individual ASP.NET pages remain "dumb" about what's going on behind the scenes. The only thing the Web forms need to worry about is performing the specific task at hand and passing the necessary data to the controller. By default, Windows WF works in an asynchronous model. This means that when an application host starts a workflow instance, control immediately returns to the host while workflow execution continues on another thread. This can be very useful in a Windows Forms application where continual responsiveness of the user interface is highly desirable. Using the asynchronous model the workflow executes in the background and the user can continue to manipulate the application. In a Web application, however, this type of behavior may not be desirable, because control would usually only be returned to the user after the server completes a unit of work. This is where the extensibility of Windows WF shines. In Windows WF, developers can utilize or write "runtime services" to monitor and even modify the workflow runtime. Examples include:

• Persistence services that store workflow state between execution and idle time.
• Tracking services that output information about workflow execution to some medium
• Transaction services that help maintain data integrity in the workflow execution process

In addition, threading services let developers control how workflow instances are executed. As discussed, the workflow runtime will by default run instances asynchronously, on a separate thread from the host. But as this is probably not desirable in ASP.NET, you need to swap out the default workflow threading service. Luckily, Microsoft already provides a solution for such a purpose, the ASPNetThreadingService. To make this change, you can either manually add the ASPNetThreadingService to the workflow runtime services in code, or do it in the web.config file. The sample application uses configuration. In the WorkflowRuntime/Services section of the web.config (see Listing 1), add a line similar to the following:
   <add type=
      "System.Workflow.Runtime.Hosting.ASPNetThreadingService, 
      System.Workflow.Runtime, Version=3.0.00000.0, 
      Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

Implementing the Controller Logic

Next you need to implement the controller logic as an HttpHandler. To construct the controller, all you need to do is create a class called WorkflowControllerHandler that implements the IHttpHandler interface. So far, nothing you've seen is specially related to Windows WF—this is functionality native to ASP.NET (see this article for more information).

In the WorkflowControllerHandler class, the IHttpHandler interface method called ProcessRequest handles a Web request from the ASP.NET application. Here, you need to obtain a reference to a static workflow runtime instance, setup the event handlers for the workflow, and kick off the workflow execution. Before starting a workflow instance, you need to check to see if the request's query string values contain a GUID representing a workflow instance ID. If the ID is present, you know that an instance is already running, so you can obtain a reference to that instance, and continue execution. If the ID is not present, you need to create a new instance and begin the execution process by calling the StartWorkflow method of the workflow runtime.

After starting an instance, the event handlers will manage communications to and from the workflow. Because the purpose of this article is not to cover local communication services, I will not go into great detail on that subject here. Rather, I will cover the high level details, and again, how this might work in an ASP.NET application. To facilitate the communication process, you'll need several .NET interfaces that represent the messages sent to and from the workflow and host. You will find these in the WorkflowClassLibrary project in the sample code provided with this article. You'll also find classes that implement these interfaces and the respective functionality necessary for the workflow to function.

Take another look at the web.config file. Notice that next to the ASPNetThreadingService element discussed earlier, there will be three elements representing the communication service classes:

   <add type="Workflow.RuntimeServices.GetNameService, 
     Workflow.Library, Version=1.0.0.0, Culture=neutral, 
     PublicKeyToken=c4620ae819b5257e"/>
   <add type="Workflow.RuntimeServices.GetEmailService, 
     Workflow.Library, Version=1.0.0.0, Culture=neutral, 
     PublicKeyToken=c4620ae819b5257e"/>
   <add type="Workflow.RuntimeServices.SendDataService, 
     Workflow.Library, Version=1.0.0.0, Culture=neutral, 
     PublicKeyToken=c4620ae819b5257e"/>

Also present is an element that instructs the workflow runtime to use the SqlStatePersistenceService. This additional service persists a workflow's state to a SQL Server database between page requests. You must create this database manually ahead of time, but Microsoft provides the SQL scripts to do this. You'll find them in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Windows Workflow Foundation\SQL folder. Like the threading model service, you could have added these services programmatically, but doing it in the configuration cuts down on code and provides flexibility even after the code is in production. Also in the web.config is a line that adds an HttpModule that supports the Windows WF runtime in ASP.NET, and a line setting up the HttpHandler controller discussed earlier. As you can see, there is a lot going on in the configuration file.

In conclusion, Windows WF provides developers with an extremely versatile and extensible framework on which to develop workflow based applications. Implementing business processes has and will continue to be an important application of technology. Unless you are a technology services firm or ISV, software is there to support the business and its processes. With a tool such as Windows WF developers can approach process development with a new sense of ease and flexibility.

Page 3 of 3

Sample ASP.NET Workflow Application

http://www.devx.com/dotnet/Article/29992/0/page/1

http://www.devx.com/dotnet/Article/29992/0/page/2

http://www.devx.com/dotnet/Article/29992/0/page/3