An activity is a discrete unit of work; that is, it performs a task. An activity doesn't have to just perform a single task — in fact an activity can contain other activities (known as a composite activity), which can each contain activities themselves, and so on. A workflow is an activity itself, and so are control flow activities (discussed shortly). You can think of an activity as the fundamental building block of workflows.

Activities can have input and output arguments, which enable the flow of data in and out of the activity, and can return a value. An activity can also have variables, which (like in code) store a value that any activities the activity contains can also get/set. The activity in which a variable is defined designates its scope.

WF includes a base library of predefined activities that cover a wide variety of tasks, which you can use in your workflow. These include activities that:

Of course, despite this wide range of predefined activities available to you, you will no doubt want to create custom activities to suit your own requirements, especially when you have complex logic to implement. These are written in code, will appear in the Toolbox in the WF designer, and you can drag and drop them into your workflow.

When creating your own custom activities, you have a number of custom activity types to choose from: Activity, CodeActivity, NativeActivity, and DynamicActivity (the custom activity inherits from one of these base classes).

Activities based on the Activity class are composed of other activities, and are designed visually in the WF designer. As previously stated, workflows are activities themselves, so your workflow is actually based on the Activity class. Activities composed in this manner can be used in other activities too.

An activity that is based on CodeActivity, as its name suggests, is an activity whose action(s)/logic is defined in code. This code is actually a class that inherits from CodeActivity and overrides the Execute method in which the code to be executed should be placed.

Activities don't necessarily have to be executed synchronously, blocking the continuing execution of the workflow while performing a long-running task, or waiting for an operation to complete, a response or input to be received, or an event to be raised. You can create asynchronous activities by inheriting from the AsyncCodeActivity class. This is much like the CodeActivity class, except rather than having a single Execute method to be overridden, it has a BeginExecute and an EndExecute method instead. When an asynchronous activity is executed, it will do so on a separate thread from the scheduler and return immediately. It can then continue to execute without blocking the execution of the main workflow. The scheduler that invoked it will be notified when it has completed executing.

An activity that is based on the NativeActivity class is much like one that inherits from CodeActivity, but whereas CodeActivity is limited to interacting with arguments and variables, NativeActivity has full access to all the functionality exposed by the workflow run time (which passes it a NativeActivityContext object that provides it with this access). This includes the ability to schedule and cancel child activity execution, aborting activity execution, access to activity bookmarks, and scheduling and tracking functions.

Control flow activities are used to control the flow of activities — essentially providing the binding between them that organizes them into a workflow and forming the logic/rules of the process being modeled. Control flow activities are just standard activities themselves, but designed to control the execution/flow of the activities it contains (by scheduling the execution of those activities).

There are two primary types of control flow activities (essentially workflow types): Sequence and Flowchart. A Sequence executes the activities that it contains (as its name suggests) in sequence. It's not possible to go backward and return to a previous step in a sequence; execution can only move forward through the sequence. A Flowchart, however, enables the execution to return to a previous step, making it more suited to decision making (that is, business) processes than sequences.

If you've worked with previous versions of WF, you will note that there is no longer a state machine control flow activity. There is, however, expected to be an out-of-band release of a state machine control flow activity at some stage in the near future.

You are not limited to using a single control flow activity in a workflow — because they are activities, you can mix and match them as required in the same workflow.

Expressions are VB code (only) that return a value, and are used in the designer to control the values of variables and arguments. You can think of them much like formulas in, say, Excel. Expressions are generally bound to an activity's input arguments, used to set the value of variables, or used to define conditions on activities (such as the If activity).

The workflow run time (also known as the scheduler) is the engine that takes a workflow definition file and executes it in the context of a host application. The host application starts a given workflow in the workflow run time using the WorkflowInvoker, the WorkflowApplication, or the WorkflowServiceHost classes.

The WorkflowInvoker class is used in a "hands off" approach to executing the workflow, leaving the workflow run time to handle the entire execution of the workflow. The WorkflowApplication class is used when requiring a "hands on" approach to executing the workflow (such as resuming a persisted instance), enabling the execution to be controlled by the host. The WorkflowServiceHost class is used when hosting the workflow as a service to be used by client applications.

A bookmark marks a place in the workflow, from which its execution can be resumed at a later point in time. Bookmarks enable a workflow instance to be "paused" while it's waiting for input to be received, specifying a point from which it will be resumed when that input has been received. A bookmark is given a name and specifies a callback function, pinpointing the activity that is currently executing and specifying the method in the activity that should be called when the workflow is resumed.

Creating a bookmark stops the workflow from executing, and releases the workflow thread (although the workflow isn't complete, but simply paused), enabling the workflow to be persisted and unloaded. The host is then tasked with capturing the input that the workflow is waiting on, and resuming that workflow's instance execution again from the bookmark position (passing in any data to the callback method received from the awaited input).

Bookmarks are particularly useful in long-running processes where the workflow is waiting for an input to be received, that potentially may not be received for quite some time. In the meantime, it releases the resources that it's using (freeing them up for use by other workflows), and its state can be persisted to disk (if required).

Persistence enables the current state of a workflow instance and its metadata (including the values of in-scope variables, arguments, bookmark data, and so on) to be serialized and saved to a data store (known as an instance store) by a persistence provider, to be retrieved and resumed at a later point in time. To persist a workflow instance, the workflow execution must be idle (such as if it's waiting for input), and a bookmark must be defined to mark the current execution point in the workflow.

Persistence is particularly important when you have long-running workflows, where you want to be able to unload workflows that are idle and waiting for input, or if the machine/server may restart in the times that the workflow is idle, or if the execution may even continue on a different server (such as in a server farm).

WF comes with a default persistence provider called SqlWorkflowInstanceStore that handles persisting a workflow instance to a SQL Server database. You can also create your own custom persistence provider by inheriting from the InstanceStore class.

You have two ways to persist a workflow instance. One is to use the predefined Persist activity from the Toolbox in your workflow, which will persist the workflow instance when executed by the run time. The other option is for the host to register an event handler for the PersistableIdle event, which is raised by the run time when the workflow instance is idle (but not yet complete). The host can then choose whether or not to persist the workflow instance, returning a value from the PersistIdleAction enumeration that will tell the run time what it should do.

WF enables you to implement tracking in your workflows, where various aspects of the execution of a workflow can be logged for analysis. Tracking provides transparency over your workflow, enabling you to see what it has done in the past and its current execution state by the workflow run time emitting tracking records.

You can specify the granularity at which the tracking records will be emitted by configuring a tracking profile, which can be defined either in the App.config file or through code. This will enable you to specify which tracking records you want the workflow run time to emit. The types of tracking records that can be emitted include workflow life cycle records (such as when a workflow starts or finishes), activity life cycle records (such as when an activity is scheduled or completes, or when an error occurs), bookmark resumption records, and custom tracking records (which you can emit from your custom activities). These tracking records can include associated data, such as the current values of variables and arguments.

Where tracking records are written is determined by specifying a tracking participant. By default, the WF run time emits tracking records to the Windows Event Log. You can create your own tracking participants if you, for example, want to write tracking records to a different source, such as a database.

You can also trace the execution of a workflow for troubleshooting and diagnostic purposes, which makes use of the standard .NET trace listeners. Tracing can be configured in the App.config file.

The first thing you want to do is to drop a control flow activity onto the designer that will schedule the execution of the activities that it contains. For this example, you will use a Sequence activity for this purpose. You will find the Sequence activity under the Control Flow category in the Toolbox. Drag and drop it into your SimpleProcessWorkflow workflow, as demonstrated in Figure 32-8.

Figure 32-8. Figure 32-8

At this point, it would be useful to give it a meaningful name — click in its header and change it to SimpleProcessSequence. You can also simply select the activity and set its DisplayName property in the Properties tool window.

For this initial example, you'll get the workflow to execute a do/while loop that will write a message to the console five times. To do this, you then need to drop a DoWhile activity into the Sequence activity from the Control Flow category in the Toolbox. Once you've done that, you will find that both the new activity and the Sequence activity are now displaying as invalid (a red icon with an exclamation mark appears in the right side of the headers of both activities). This is because an expression needs to be assigned to the condition of the DoWhile activity before it can be considered valid.

Because you want to place more than one activity in the DoWhile activity, add a Sequence activity as its child. Call this sequence WriteHelloWorldSequence.

Now find the WriteLine activity in the Toolbox (under the Primitives category), and drag and drop that into the WriteHelloWorldSequence activity. To make it write Hello World to the output each time it's executed, set its Text argument to "Hello World" (with the argument accepting an expression and being a string value that you are assigning, you need to assign it as a literal value by enclosing it in quotes).

So that the output can be seen more easily, drop a Delay activity (from the Primitives category in the Toolbox) into the WriteHelloWorldSequence activity, following the WriteLine activity. The Delay activity's Duration argument accepts a TimeSpan type — you'll use an expression to specify its value as 200 milliseconds because it's more readable than the literal value:

TimeSpan.FromMilliseconds(200)

To control the number of times this loop will execute, add a variable called Counter to the SimpleProcessSequence activity (which will be available to all the activities in the sequence). Select the SimpleProcessSequence activity and pop up the Variables pane. Click where it says Create Variable, enter Counter as its name, a type of Int32, and a default value of 0.

Back in the DoWhile activity, you can now specify the following expression as its condition:

Counter < 5

The final step is to actually increment the Counter variable. Add an Assign activity (from the Primitives category in the Toolbox) to the sequence (following the Delay activity), setting its To argument to Counter, and its Value argument to Counter + 1.

Your simple workflow is now complete, and should look like Figure 32-9.

Figure 32-9. Figure 32-9

Now you can run your application, which will execute the workflow with the results shown in Figure 32-10.

Figure 32-10. Figure 32-10

Now create a custom activity whose work is defined in code to get input from the user. Add a new item to your project, select the Code Activity item template from the Workflow category in the Add New Item dialog (as shown in Figure 32-11), and call it UserInput.

Figure 32-11. Figure 32-11

This creates a class that inherits from System.Activities.CodeActivity, and overrides the Execute method into which you can write the code that this activity will execute. It also includes a sample input argument called Text (defined as a property on the class), which you can delete because this activity won't require any inputs (also delete the line of code in the Execute method that retrieves its value).

This activity will obtain input from the user that other activities in the workflow can use. You can return the value either as an output argument or as a return value. Either way is acceptable, so for this example return the value.

To return a value, instead of inheriting from the CodeActivity class you will need to inherit from its generic version instead (into which you pass the type that the activity will return). Change the class to inherit from the generic CodeActivity class, passing in the type of the return value. Change the Execute method to return a type instead of void (C# developers), or to a function that returns a type (VB developers). Then it's simply a case of returning the value returned from the Console.ReadLine() function in the Execute method:

If you switch back now to the workflow in the designer, you will find that the activity is nowhere to be found in the Toolbox. However, once you compile your project, it will appear in the Toolbox, under the category with the same name as your project, as shown in Figure 32-12.

Figure 32-12. Figure 32-12

Drop the activity from the Toolbox into your workflow, in the main SimpleProcessSequence sequence activity after the DoWhile activity. You will note that there is no nice designer user interface for the activity (just a simple block), but you could design one by creating an activity designer for it. However a discussion of this is beyond the scope of this chapter.

When you select it, the Properties tool window will have a property called Result, in which an expression to work with the return value of the Execute method in the activity can be specified. What you want to do is assign the return value to a variable, which activities following it in the sequence can use. Create a new variable in the Variables pane called UserInputValue with a type of String. In the Properties tool window, you can now simply set UserInputValue as the expression for the Result property, which will assign the return value from the activity to the UserInputValue variable. You can prove this works by adding a WriteLine activity following the UserInput activity that then writes the value of this variable back out to the console.

If you inspect the Main method (the entry point of the application) in the Program.cs file (for C# developers) or Module1.vb (for VB developers) you will find the code used to execute the workflow:

This is making use of the WorkflowInvoker class to invoke the workflow, which, as described earlier in this chapter, has no control over the actual execution of the workflow other than simply initiating its execution.

If you want more control over the execution of a workflow, however (such as if you need to resume execution from a bookmark, or persist/unload a workflow), you will need to turn to the WorkflowApplication class to invoke your workflow instead. Basic use of the WorkflowApplication class to invoke a workflow and handle its Complete event is as follows:

This code assigns a delegate that will be run when the workflow has completed executing. Because the Run method returns immediately, you will wait for the workflow to complete executing before continuing (and exiting the application) using the WaitOne method on a AutoResetEvent, which is notified in the Completed handler that it can enable the thread execution to continue.

Executing a workflow via the WorkflowApplication class actually invokes it on a background thread, with the Run method returning immediately. The host can attach event handlers to various events raised by the WorkflowApplication class (such as when a workflow instance has completed, is idle, thrown an unhandled exception, and so on), and also gains the ability to abort/cancel/terminate a workflow instance, load one from a instance store, persist it, unload it, and resume from a bookmark.

You can pass input arguments into a workflow, and obtain output argument values from it. Input arguments are exposed as properties from your workflow class, so assign values to these before invoking the workflow. Output arguments are returned in a dictionary (which is the return value of the WorkflowInvoker.Invoke method), each having a string key with the name of the argument, and a corresponding object value that you can cast to the appropriate type.

As previously noted, workflows/activities are XAML files. By default, the XAML file is compiled into the application (as a resource), but what if you want to take advantage of the fact that you can reconfigure a workflow without recompiling the application? In that case, you would have to have the XAML file as a content file in your project instead, and dynamically load it into your application from file. This is where the ActivityXamlServices class is useful. Load the XAML file as an activity using the ActivityXamlServices class, and then invoke (that is, execute) the activity that it returns with the WorkflowInvoker or WorkflowApplication class:

In addition to having a rich designer support for building workflows, WF also includes debugging capabilities. To define a breakpoint in a workflow, simply select the activity and press F9, or select Breakpoint

Figure 32-13. Figure 32-13

As in a normal debugging session, in a workflow you step through code using shortcut keys. Pressing F10 steps through the workflow, and pressing F11 steps into the current activity. You can view the values of variables currently in scope in the Locals tool window.

Of course, your custom code activities can be debugged as normal by setting breakpoints in the code editor and stepping through the code.

Having a well-defined testing framework is extremely important in business applications, with it especially vital that the underlying business logic for the application is well covered with tests. Therefore, it is essential with your workflow being at the core of your business logic that it should be testable too. Luckily, this is indeed possible, and you can use your favorite unit testing framework — going so far as to use Test Driven Development (TDD) practices if you want. As discussed in the "Executing a Workflow" section, by using the WorkflowInvoker.Invoke method to execute your workflow, you can pass input argument values into the workflow and obtain the resulting output argument values (in a dictionary). Therefore, testing your workflow is as easy as supplying input argument values and asserting that the corresponding output argument values are as expected.