WF Features

WF includes a namespace in the .NET Framework version 3.0 that includes classes and tools for use in building workflow applications. It includes graphical designers for Visual Studio 2005 and a workflow runtime engine that moves workflow objects from one activity to the next until it reaches a stop condition.

A workflow contains a set of activities that represent some sort of action or event. From a programming perspective, a workflow is a class that represents this set of activities defined in Visual Basic (or C#) or XAML.

An activity can perform a single function (such as sending an e-mail or reading data from a database), or it can be composed of a collection of other activities. WF currently defines almost 40 common types of activities such as CodeActivity (executes Visual Basic code), CallExternalMethodActivity (calls a method in a service application), IfElseActivity (tests a condition and executes one of several activities based on the result), EventDrivenActivity (executes other activities in response to an event), and TerminateActivity (ends the workflow). You can also define your own activities if none of the predefined activities fit your needs.

WF includes several services that you can use to help manage your workflows. These include persistence services that can store a workflow’s state in a database, tracking services that can record events during a workflow’s lifetime, and scheduling services that let you determine whether workflows are processed synchronously or asynchronously. The engine’s persistence features let it save and resume workflows, even if they remain active for a long time, and even if the applications interacting with the workflows start and stop repeatedly. In the bug report example, that means you might create a bug report one day, fix the bug the next day, and not test and release the fix until several days later.

If a workflow encounters an exception, it can undo certain kinds of previously executed activities to fix the error. WF calls this compensation. You can use compensation to recover from errors by rolling back operations that did not finish correctly.

For example, suppose a bug report enters a workflow and is evaluated, queued, and assigned to an engineer. That engineer does some tests and discovers that the bug should really have been assigned to someone else. The workflow could use compensation to roll back the incorrect assignment and let the person who queued the report try again.

Activities that call external routines and that respond to external events provide mechanisms for the workflow’s code to communicate with a host application. The sequential workflow example described later in this chapter demonstrates these methods of communication.

WF even lets you modify a workflow’s structure as it runs. You can add, remove, rearrange, and modify activities to dynamically alter the workflow. In practice, this kind of self-modifying code can be extremely tricky to build and debug, so I don’t recommend it, but it potentially lets you handle tasks that would otherwise be impossible. For example, you could let a manager define new tasks if they are discovered after a job has begun moving through a workflow.