The most basic way to create a custom activity is to simply inherit from System.Workflow.ComponentModel.Activity. This will create all the basic machinery for an activity, except for the actual logic implemented by the activity. To do this, one should override the Execute() method, as shown in Listing 5.1.

public class BasicActivity: Activity
{
        public BasicActivity()
        {
                this.Name = "BasicActivity";
        }
        protected override ActivityExecutionStatus Execute
            (ActivityExecutionContext executionContext)
        {
            Console.WriteLine("Basic Activity");
            return ActivityExecutionStatus.Closed;
        }
}

The Execute() method performs the work of the activity and is required to notify the runtime its status. In this case, a status of Closed is returned, indicating the activity has completed its work. A more complex pattern would be to return a status of Executing while waiting for some long-running work to complete. On completion of the long-running work, such as a manager approving an expense report, the activity notifies the runtime it has been completed. While waiting, the workflow instance might be idled and persisted awaiting the completion of the long running work.

As activities form the building blocks of a workflow, this pattern shows how one can very quickly wrap existing functionality inside an activity. An existing code library or component call can be wrapped inside of an activity with very little work. In Chapter 6, “Using the Windows Communication Foundation and the Windows Workflow Foundation Together,” this technique will be used to encapsulate calls to Windows Communication Foundation services. The activity shown earlier is not particularly interesting, nor does it expose any useful customization. This might work if one is wrapping an API consisting completely of hard coded or parameter-less functions. One usually wants to control some parameters that will affect the behavior to provide a useful activity. The simplest way to expose that capability is to add a property to the activity class, as shown in Listing 5.2.

public string TextToPrint
{
      get {return textToPrint;}
      set {textToPrint = value;}
}
protected override ActivityExecutionStatus Execute
      (ActivityExecutionContext executionContext)
{
      Console.WriteLine("Text To Print: {0}", TextToPrint);
      return ActivityExecutionStatus.Closed;
}

By adding this property, the activity can be configured when the workflow is designed, as shown in Figure 5.3.

Figure 5.3. A standard property on the property grid.

When declaratively creating workflows in XAML (Extensible Application Markup Language), the XML representation of the workflow, these properties are set as attributes on the activity, as in Listing 5.3.

<SequentialWorkflowActivity x:Class="SampleWFApplication.Workflow1"
  x:Name="Workflow1" xmlns:ns0="clr-namespace:SampleWFApplication"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
  <ns0:BasicActivity TextToPrint="Hello World"
    x:Name="basicActivity1"/>
</SequentialWorkflowActivity>

This allows the properties to be set in the designer to customize the behavior of the activity. But it remains fairly static, limited to the value input at design time. What if the scenario called for passing in a customer object that the workflow was created to evaluate? This is accomplished through the use of dependency properties. Dependency properties are similar to the standard .NET properties described earlier, but differ in declaration and usage. There is a built-in code snippet to create these in Visual Studio, but the general pattern is given in Listing 5.4.

public static DependencyProperty OrderAmountProperty = System.Workflow. ComponentModel
.DependencyProperty.Register("OrderAmount", typeof(int), typeof(BasicActivity));
[Description("This property holds the amount of the order")]
[Category("Order Details")]
[Browsable(true)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
public int OrderAmount
{
    get
    {
        return ((int)(base.GetValue(BasicActivity.OrderAmountProperty)));
    }
    set
    {
        base.SetValue(BasicActivity.OrderAmountProperty, value);
    }
}

This slightly longer declaration appears to have some elements of a property, but also contains a static DependencyProperty declaration. A DependencyProperty is a special type of property that is attached to a DependencyObject, one of the classes that Activity inherits from. A DependencyProperty differs from a traditional property in that it supports three special use cases:

The most common scenario is using dependency properties to support activity binding. The advantage gained by using dependency properties is additional design-time behaviors. Dropping the activity onto the design surface and inspecting its properties yields a new icon next to the property just declared, as shown in Figure 5.4.

Figure 5.4. DependencyProperty in grid.

Clicking on that new icon raises a new dialog, the bind dialog, as shown in Figure 5.5.

Figure 5.5. The Bind dialog.

The Bind dialog allows the value of the property to be dynamically bound to another value in the workflow. This could be a property on the workflow passed in at the time of workflow creation or this could be a property on another activity. At design time, the activity is told where to look for the value of this property. By selecting another value in the workflow of the same type (and this can be a custom type), a binding expression now appears in the property grid as the value of the property. It looks something like this:

Activity=Workflow1, Path=WorkflowOrderAmount

The first part allows for the source (in this case, the parent workflow) and then the property on that activity to be resolved. Dot notation can be used here, so if the desired value to be bound is a few layers beneath a property, it can be reached.

Of course, with a dependency property, the value can still be hard-coded. In the previous example, there would be nothing to prevent one from inputting a fixed number, say 42, into the property grid.

Within the Bind dialog is a Bind to a New Member tab, as shown in Figure 5.6.

Figure 5.6. Property promotion via binding to a new member.

This dialog lets a dependency property of an activity be “promoted” to be a member of the containing activity. In this case, binding to a new member will create a dependency property (or public member) on the workflow and insert the proper binding syntax for the activities value. This lets the property of an activity contained within a composite activity to bubble up to a property on the containing activity. When creating activities through composition, this is a useful way to mimic the polymorphism of inheritance. The containing activity can expose the properties of a contained activity as if it had inherited them from that activity.

The second way to create an activity, and the one Visual Studio defaults to, is through composition. The activity class definition of a newly created activity in Visual Studio looks like this:

public partial class ACompositeActivity: SequenceActivity

This inherits from SequenceActivity, the fundamental activity for building sequential workflows. The Execute() method of SequenceActivity is responsible for scheduling the execution of each contained child activity in sequence. By inheriting, that behavior is not overwritten, it is desired. Additionally, the design behavior of the SequenceActivity is preserved. This allows an activity developer to create a new activity by dragging and dropping other activities into the new activity, thus creating an activity out of existing activities. This is a powerful tool for creating new units of work, activities to be used inside of a workflow. This means that given a powerful enough set of basic activities implemented in code, perhaps wrapping an existing API, one can very rapidly create those units of functionality into new, higher-level units of functionality. To drive this concept home, consider the following activities:

With these activities, along with some of the structural activities provided by the out of the box activities, one can compose an arbitrarily complex approval activity, and then expose that activity out as “the” approval activity to use in any workflow (see Figure 5.7).

Figure 5.7. An Approval activity composed of more basic activities.

As higher-order activities are created, such as Approval, these too can be composed again and again into additional activities, allowing process of arbitrary sophistication to be created. A NewProductIdeaGeneration activity might consist of a parallel activity containing a set of cross-departmental feedback requests that each need an approval. This activity could then be used in a New Product Creation workflow with the workflow developer unaware of the many layers of implementation detail there are behind the NewProductIdeaGeneration activity. This developer just knows that the NewProductIdeaGeneration activity will execute, and when it completes, it will be populated with a set of vetted, approved ideas to be used elsewhere in the workflow. As mentioned earlier, properties of contained activities can be promoted to be properties on the containing activity, allowing the useful customization properties to be exposed to users of the containing activity.

It is in these higher-level, composition-based activities where many organizations look to have nondevelopers arrange them into workflows. Consider the document approval activity created earlier. By providing that activity and a parallel activity, a business analyst could create the approval workflow for a given class of documents. This is the approach exposed through SharePoint Designer and Microsoft Office SharePoint Server, which allows a business analyst or power user to create and customize document workflows in SharePoint. The challenge of providing a repository where activities can be referenced across an enterprise or department, and their characteristics expressed for other developers and analysts to reference, is left as an exercise to the reader.

There exists an additional type of activity one can create—a custom composite activity. A composite activity is one that contains child activities, and its Execute() method is responsible for scheduling the execution of those child activities. Out of the box, examples of composite activities are Sequence, While, and Parallel.

Those activities, however, express only a few types of execution semantics. There exist many other ways in which one might want to execute the child activities, such as a priority execution where child activities are executed in some type of prioritized ordering. One might want to have an activity that executes in parallel but allows the developer to set a looping variable on each branch, so that not only does it executes in parallel, but also executes each branch a specified number of times.

The implementation of such activities deals with some advanced intricacies of activity execution. Shukla and Schmidt’s “Essential Windows Workflow Foundation” is recommended to explore the details of activity execution and ways to create advanced, custom composite activities.

The composite activity executes by scheduling execution of its child activities and subscribing to those child activities’ completed event. The activity then returns the Executing status, indicating to the runtime to continue by executing the next activity scheduled. On receiving the child completed event, the composite can proceed scheduling other activities or evaluate if it can close. When all of the activities complete or the composite decides enough has been done, the composite will return a state of Closed, indicating it has completed. The workflow runtime will enforce a restriction that all child activities must be Closed before allowing the parent activity to close.

Validation is an important aspect to the design behavior of an activity. To validate an activity, there are two steps:

An ActivtyValidator object implements one important method:

public ValidationErrorCollection Validate (ValidationManager manager, object obj)

This method evaluates any and all possible validation conditions and returns a collection of the errors that occurred. In addition, there are two types of errors: errors and warnings. An error will stop compilation of the workflow; a warning will allow compilation to complete, but will output a warning message. An example of this might be on a ShipItem activity: One might not be required to put a postal code on the shipping label, however, it is important enough that its absence should be called to someone’s attention at compile time. It might be the desired behavior not to provide a postal code, but most of the time, one should be provided, so a warning will alert the developer of the potential error.

Activity validators are also called when a workflow is loaded from an XmlReader in order to ensure that a valid workflow has been handed to the runtime to execute. In this case, a failed validation will result in an error during the attempted loading of the workflow.

A sample validator follows in Listing 5.8, this code checks to ensure that a value has been entered for the TransactionAmount property:

private class CustomValidator : ActivityValidator
{
    public override ValidationErrorCollection Validate
                      (ValidationManager manager, object obj)
    {
        ValidationErrorCollection errorCollection =
            base.Validate(manager, obj);
        DemoActivity demoActivity = obj as DemoActivity;
        if (obj.TransactionAmount <= 0)
        {
            errorCollection.Add(new ValidationError
              ("Transaction Amount must be greater than 0",8675309, false));
        }
        return errorCollection;
    }
}

The constructor for ValidationError has a few overloads, allowing an error number to be specified, a Boolean for determining whether this is a warning, and a property name if a specific property is responsible for the error. The property name, if specified, will allow the designer to set focus to that property in the property grid if the validation error is clicked on in the designer.

When an error collection is retuned, the developer is notified of this through the smart tag that appears adjacent to the activity. Clicking on the smart tag allows the developer to review the different errors that were returned by the executing validator, as shown in Figure 5.12.

Figure 5.12. Validation results displayed in a smart tag.

The validator is applied to an activity by decorating the definition of the class with the ActivityValidator attribute, as shown in the following code.

[ActivityValidator(typeof(CustomValidator))]
public partial class DemoActivity : SequenceActivity

When just sketching a process, not many boxes will be drawn until the inevitable decision diamond appears, indicating some choice that needs to be made. When drawing, the criteria is often written inside the diamond, indicating the criteria that defines the condition, as shown in Figure 5.16.

Figure 5.16. Napkin workflow with decision diamond.

Inside of a workflow, when a decision needs to be made, the IfElse activity is used. The IfElse activity contains at least a single child branch, an activity of type IfElseBranchActivity. An IfElseBranchActivity is a sequential composite activity with a special property, Condition. It is the condition that determines whether the activities contained inside the IfElseBranchActivity are to be executed or ignored. The IfElse activity can contain an arbitrary number of branches, each having a defined condition. The IfElse activity defined last, or appearing to the rightmost side in the designer, will not require a condition. This activity is the else branch inside the if statement. Within the designer, to add an additional branch, right-click on the IfElse activity and select the Add Branch item that appears on the context menu, as shown in Figure 5.17. The result is seen in Figure 5.18.

Figure 5.17. IfElse context menu.

Figure 5.18. Multiple branch IfElse activity.

The validators on the IfElseBranchActivity require a condition be assigned unless it is the Else branch. However, there is no enforcement of exclusivity of conditions. That is, there might be three branches: The first defines a condition x > 5 and the second defines a condition x > 10. The validators do not look to see that there is a collision (namely, if x > 10, the condition on both branches would be satisfied). The IfElse activity will evaluate the conditions in a left-to-right sequence and will execute the first branch, and only the first branch, whose condition evaluates to true. If all the conditions evaluate to false and there is an Else branch, the Else branch will be executed. The different types of rule conditions and their use are discussed later in this chapter in the “Rules Engine” section.

Within the process, there might be a time when multiple activities need to execute simultaneously. There might also be a time where one wants to ensure that some number (n) of activities have completed before moving on to the next activity. The activities arranged in parallel might all execute over roughly the same amount of time, or the time might be radically different; one branch calling quickly to a web service to retrieve the credit limit of a customer, while another branch is waiting for a call-center representative to complete an over the phone survey of the same customer. Hopefully, the web service containing credit limit information would return well before the phone survey occurs. The model of this process can be seen in Figure 5.19

Figure 5.19. A simple parallel activity.

The Parallel activity is designed for this scenario. The Parallel activity consists of at least two Sequence activities. Additional branches can be added by selecting the Parallel activity, right-clicking, and selecting Add Branch in the same way that one adds branches to the IfElse activity. This leads to the very important conversation regarding the execution order of items contained inside a Parallel activity, which first must start off with the statement that the Parallel activity is not multithreaded.

This point bears repeating: The Parallel activity is not multithreaded. This stems primarily from the design decision made by the team that a workflow instance will run on one and only one thread at a given time. This decision was made to keep the simple, compositional nature of the Windows Workflow Foundation programming model, in a word, simple. In the words of the architects themselves:

Multithreaded programming is complicated, and the ability to reuse activities in multiple workflow types makes activity-hardening a very tough task when the concerns of multi-threading are added. Additionally, this is not to say that the runtime engine is single-threaded. On the contrary, by default the engine will schedule workflow instances to execute on as many threads as it has been programmed to use to execute workflows. A workflow instance is tied to a single thread while it is executing, but the usual use of workflow is that there will be multiple instances of that workflow running at any one time, each on its own thread. Workflows can execute in parallel on multiple threads, but a single workflow instance will use one thread.

The question inevitably is raised, “What about my <tricky bit of computation> that requires me to multithread or else my performance will be horrible?” Again, going back to Shukla and Schmidt:

In other words, if one has such a computation, the best way to leverage it from a work-flow is to expose it as a service, using many of the techniques described elsewhere in this book. Chapter 6 will deal with integrating Windows Communication Foundation services with Windows Workflow Foundation programs.

Consider the following workflow that contains a parallel activity in three branches. Each of the activities will output the branch they are in and the position in which they appear in the branch, as shown in Figure 5.20.

Figure 5.20. A parallel activity with three branches.

The output of this workflow will be the following:

Output of Parallel Execution

Left 0
Middle 0
Right 0
Left 1
Middle 1
Right 1
Left 2

To understand the earlier interleaved sequence, one must understand how the activities are actually being executed. A workflow instance maintains a schedule of activities to execute. As the parallel activity executes, it schedules each of the child activities (these are Sequence activities) for execution. This is scheduled by placing a delegate to the Execute() method onto the execution queue used by the runtime. The Parallel activity has scheduled the Left, Middle, and Right Sequence activities to execute, in that order. The execution queue now looks as shown in Figure 5.21.

Figure 5.21. Execution queue as scheduled by the Parallel activity.

The first activity to execute is Left Sequence. It is responsible for executing its contained activities, so it adds its activity to the execution queue. The queue now looks as shown in Figure 5.22.

Figure 5.22. The execution queue after the Left Sequence activity executes.

Execution continues until the queue looks as shown in Figure 5.23.

Figure 5.23. The execution queue with code activities scheduled.

When the left0 activity completes, the event handler of the Left Sequence activity is called and schedules the next activity, left1, for execution. The queue now looks as shown in Figure 5.24.

Figure 5.24. The execution queue after left0 executes.

This pattern continues until all the Sequence activities have completed. Then the Parallel activity completes and the workflow moves on.

The workflow developer can have finer-grained control over the execution sequence by using the SynchronizationScope activity. SynchronizationScope is a composite activity one can use to serialize the execution of a group of activities. In the workflow just shown, assume that the right branch must execute only after the left branch has completed fully. It might be that the business process describes these two branches as parallel, but due to implementation, it is necessary that one execute prior to another (note to the process consultant, this might be a bottleneck to look at!). A SynchronizationScope activity has a SynchronizationHandles property that is used to determine the way in which the various SynchronizationScope activities interact with one another. The SynchronizationHandles property is a collection of strings used as handles on a shared resource. When a SynchronizationScope executes, it attempts to obtain a lock on each of the handles and will not execute until it obtains the lock. If the handle is locked by another SynchronizationScope, the other SynchronizationScope activities will wait to acquire the lock. In this way, access to these handles, and the activities within, can be serialized.

This is best shown by the workflow in Figure 5.25, which is the example shown earlier modified to contain three SynchronizationScope activities. The left most synchronization activity has a synchronization handle of a, the middle b, and the right a, b, or both of them. In plain language, the right branch activity will not execute until both the left and middle branch have completed.

Figure 5.25. A parallel activity with SynchronizationScope activities on each branch.

Listing 5.11 expresses this in XAML.

<SequentialWorkflowActivity x:Class="WCFHandsOne.SynchronizationWithParallel"
  x:Name="SynchronizationWithParallel"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
  <ParallelActivity x:Name="parallelActivity1">
    <SequenceActivity x:Name="sequenceActivity1">
      <SynchronizationScopeActivity
       x:Name="synchronizationScopeActivity1" SynchronizationHandles="a">
        <CodeActivity x:Name="codeActivity1"
          ExecuteCode="codeActivity1_ExecuteCode" />
        <CodeActivity x:Name="codeActivity4"
          ExecuteCode="codeActivity1_ExecuteCode" />
        <CodeActivity x:Name="codeActivity7"
          ExecuteCode="codeActivity1_ExecuteCode" />
      </SynchronizationScopeActivity>
    </SequenceActivity>
    <SequenceActivity x:Name="sequenceActivity2">
      <SynchronizationScopeActivity
         x:Name="synchronizationScopeActivity2" SynchronizationHandles="b">
          <CodeActivity x:Name="codeActivity2"
             ExecuteCode="codeActivity2_ExecuteCode" />
           <CodeActivity x:Name="codeActivity5"
             ExecuteCode="codeActivity2_ExecuteCode" />
      </SynchronizationScopeActivity>
    </SequenceActivity>
    <SequenceActivity x:Name="sequenceActivity3">
      <SynchronizationScopeActivity
        x:Name="synchronizationScopeActivity3" SynchronizationHandles="a, b">
        <CodeActivity x:Name="codeActivity6"
           ExecuteCode="codeActivity3_ExecuteCode" />
        <CodeActivity x:Name="codeActivity3"
           ExecuteCode="codeActivity3_ExecuteCode" />
      </SynchronizationScopeActivity>
    </SequenceActivity>
   </ParallelActivity>
</SequentialWorkflowActivity>

With the code beside in Listing 5.12:

public partial class SynchronizationWithParallel: SequentialWorkflowActivity
{
        private int i,j,k;
        private void codeActivity1_ExecuteCode(object sender, EventArgs e)
        {
            Console.WriteLine("Left {0}", i);
            i++;
        }
        private void codeActivity2_ExecuteCode(object sender, EventArgs e)
        {
            Console.WriteLine("Middle {0}", j);
            j++;
        }
        private void codeActivity3_ExecuteCode(object sender, EventArgs e)
        {
            Console.WriteLine("Right {0}", k);
            k++;
        }
}

It is insightful to trace through the execution of this workflow. Earlier, the behavior of the Parallel activity was discussed, assume that the execution queue is as shown in Figure 5.26.

Figure 5.26. Execution queue scheduling of SynchronizationScope activities.

The left SynchronizationScope will attempt to lock on the handle a, and will be successful. It will schedule its first child activity for execution, yielding the queue shown in Figure 5.26.

Figure 5.27. The execution queue following the left SynchronizationScope successfully locking its handle, A.

The middle SynchronizationScope will successfully lock its handle, b, and will schedule middle0 for execution. When the right SynchronizationScope executes, it will attempt to obtain locks on a and b and will fail to obtain them. The left and middle SynchronizationScope activities will execute in an interleaved fashion until the right SynchronizationScope can obtain locks on both A and B. Therefore, its execution output would look like this:

Execution Output of Synchronization Scope Workflow

Left 0
Middle 0
Left 1
Middle 1
Left 2
Right 0
Right 1

One can also imagine the use of long-running activities in the braches, those activities that do some work and then await a message to conclude execution, such as a RequestApproval activity. In these scenarios, when an activity yields control, such as by returning a status of Executing while it waits for some message, the Parallel activity will continue executing the other branches. If an activity does a long-running amount of CPU-intensive work and never yields control back to the scheduler (by return Executing or Closed), the Parallel activity will not continue with the other items. This makes sense because the workflow instance is single threaded, so if one activity is continuing to do work, another activity cannot execute.

A defining feature of a workflow system is its capability to enable long-running work. Long-running work generally refers to a pattern of request-response activities, with the time span between request and response a suitably long duration (minutes, hours, days). Windows Workflow Foundation provides this ability to workflow developers, and makes the task of persisting workflows while they wait transparent. This is accomplished through a persistence service. When a workflow is idled or is required to persist, the work-flow runtime provides access to a persistence service. If a persistence service is not available, the workflow will not be persisted and will remain in-memory while awaiting its eventual resumption.

The persistence service is responsible for storing all the information about the workflow state to some location outside the workflow runtime. When an event occurs that requires that specific workflow instance, the workflow runtime will first check in memory to see whether that workflow is already executing. If it is not, it uses the persistence service to load the workflow instance back into memory. What is important to note is that the workflow can be reloaded into memory weeks after the last time it did anything. Additionally, the workflow could be reloaded onto a completely different machine than the one that initially persisted it. It is through a persistence service that one can obtain scalability by hosting workflow within a farm setting. The runtime will attempt to persist the workflow in the following situations:

To force persistence at a point within the workflow, an “empty” activity decorated with the PersistOnClose attribute could be used to ensure persistence.

Out of the box, Windows Workflow Foundation provides a default implementation of a persistence service: SqlWorkflowPersistenceService. To use SqlWorkflowPersistenceService, the following steps are necessary:

The last step is done either in code or within the application configuration file. The approaches are outlined in Listing 5.14 and Listing 5.15, respectively.

using (WorkflowRuntime workflowRuntime = new WorkflowRuntime())
{
    WorkflowPersistenceService persistenceService =
        new SqlWorkflowPersistenceService(
        "Initial Catalog=SqlPersistenceService;Data Source=localhost; Integrated
 Security=SSPI;",
        false,
        new TimeSpan(1, 0, 0),
        new TimeSpan(0, 0, 5));
    workflowRuntime.AddService(persistenceService);
...

}

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
       <configSections>
               <section name="WorkflowRuntime" type="System.Workflow.Runtime.Configuration
.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
 PublicKeyToken=31bf3856ad364e35"/>
       </configSections>
       <WorkflowRuntime Name="WorkflowServiceContainer">
               <Services>
                       <addtype="System.Workflow.Runtime.Hosting.
 SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0,
 Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionString="Initial
 Catalog=WorkflowPersistenceStore;Data Source=localhost;Integrated Security=SSPI;"
 UnloadOnIdle="true"/>
               </Services>
       </WorkflowRuntime>
...
</configuration>

In the second case, the persistence service is being configured with the UnloadOnIdle flag set to true. This forces the runtime to persist the workflows whenever they are reported as idle. SqlWorkflowPersistenceService is also responsible for managing the tracking of timers. If an expense-reporting workflow has a timeout of one week before the approval must escalate, something needs to keep track of that timer in order to load the workflow in the case where nothing happens for a week. SqlWorkflowPersistenceService stores the timer expiration within its SQL tables. When the runtime is started and the service is loaded, one of the first actions it performs is a scan of the timer expirations to determine whether any were “missed” while the host was unavailable. In this way, the persistence service ensures that even if the host was down, on resuming, any workflows whose timers have expired will be processed. There are a number of other features in SqlWorkflowPersistenceService that pertain specifically to scaling out in a farm setting. The reader is encouraged to explore the documentation further to investigate that scenario.

While a workflow is executing, there are many potentially interesting pieces of data one might want to collect. How long did an activity take? When did the workflow start and when did it finish? What was the value of the purchase order that went through the system? All of these questions can be answered via the information recorded by the tracking service. The tracking service is used by the workflow runtime to output various pieces of data to some kind of external store.

The mechanics of the tracking service are relevant to understand here. The runtime will call the TryGetProfile() method of the tracking service to obtain a tracking profile, if it exists, for the currently executing instance. If a profile exists, it describes what information should be sent via the tracking channel. The tracking service itself does not determine what data gets tracked; it provides a profile to the runtime, which in turn decides when to track. This design does not rely on a tracking service author to provide a high performance implementation of event filtering.

<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<TrackingProfile xmlns="http://schemas.microsoft.com/winfx/2006/workflow/trackingprofile" 
version="1.0.0">
     <TrackPoints>
         <ActivityTrackPoint>
             <MatchingLocations>
                  <ActivityTrackingLocation>
                      <Activity>
                          <TypeName>activityName</TypeName>
                          <MatchDerivedTypes>false</MatchDerivedTypes>
                      </Activity>
                      <ExecutionStatusEvents>
                          <ExecutionStatus>Initialized</ExecutionStatus>
                          <ExecutionStatus>Executing</ExecutionStatus>
                          <ExecutionStatus>Canceling</ExecutionStatus>
                          <ExecutionStatus>Closed</ExecutionStatus>
                          <ExecutionStatus>Compensating</ExecutionStatus>
                          <ExecutionStatus>Faulting</ExecutionStatus>
                      </ExecutionStatusEvents>
                      <Conditions>
                          <ActivityTrackingCondition>
                              <Operator>Equals</Operator>
                              <Member>memberName</Member>
                              <Value>memberValue</Value>
                          </ActivityTrackingCondition>
                      </Conditions>
                  </ActivityTrackingLocation>
              </MatchingLocations>
              <ExcludedLocations>
                  <ActivityTrackingLocation>
                      <Activity>
                          <TypeName>activityName</TypeName>
                          <MatchDerivedTypes>false</MatchDerivedTypes>
                      </Activity>
                      <ExecutionStatusEvents>
                          <ExecutionStatus>Compensating</ExecutionStatus>
                      </ExecutionStatusEvents>
                  </ActivityTrackingLocation>
              </ExcludedLocations>
              <Annotations>
                  <Annotation>Track Point Annotations</Annotation>
              </Annotations>
              <Extracts>
                  <WorkflowDataTrackingExtract>
                      <Member>Name</Member>
                  </WorkflowDataTrackingExtract>
              </Extracts>
          </ActivityTrackPoint>
      </TrackPoints>
</TrackingProfile>

The scheduler service is responsible for providing threads to the runtime in order to actually perform the execution of workflows. As noted in the discussion of the Parallel activity, a single instance of a workflow executes on only one thread. The engine itself can schedule multiple threads to be executing different workflow instances at the same time. It is quite probable that the number of executing workflow instances will be greater than the number of threads available to the application. Therefore, the runtime has to marshal threads to workflow instances in some fashion, and the way that is implemented is via the scheduler service.

DefaultWorkflowSchedulerService is, as its name implies, the default behavior of the runtime. It uses the .NET thread pool to provide threads for the executing workflows. It has one configuration setting of note, MaxSimultaneousWorkflows, which specifies how many threads will be used to execute workflow instances at the same time. By default, MaxSimultaneousWorkflows is set to a multiple of the number of processors on the machine. One is free to change this setting, but there are some words of caution. The scheduler service itself uses a single thread, so setting MaxSimultaneousWorkflows = Max Threads would be very bad, possibly resulting in a deadlock as the scheduler service is starved out of ever getting a thread. Additionally, the thread pool used by the default scheduler is the system thread pool, so there are plenty of other things that could take those threads. Operations such as transactions involving the Distributed Transaction Coordinator (DTC) might involve additional threads, so setting MaxSimultaneousWorkflows close to the maximum number of threads is generally not recommended. As with any performance tuning, it is best to experiment with this setting at a stage of development where the process is well defined, and the experiment can be repeated in order to truly understand the impact of turning this control knob.

There are also times in which multithreading is not desirable. Consider a workflow used by an ASP.NET page. Spawning additional threads within IIS takes away from the number of threads IIS has to serve additional incoming requests. The solution to this seems obvious enough: The ASP.NET page is not going to complete executing until the workflow does some work and then reaches an idle state or completes, so why not use that thread? This is precisely the scenario ManualWorkflowSchedulerService was created for.

ManualWorkflowSchedulerService provides a thread for the workflow to execute on by donating the currently executing thread to the workflow. Put another way, ManualWorkflowSchedulerService says, “Hey, I’m waiting here until the workflow is done, so why don’t you use this thread I’d just be hogging anyway?” Therefore, control on the host is blocked until the workflow yields that thread, namely by completing or by going idle. Because the workflow will use the current thread, just calling WorkflowInstance.Start() is not enough to execute the workflow; doing so simply places the workflow in the running state where it awaits a thread in order to begin executing.

To hand the thread to the workflow, call ManualWorkflowSchedulerService.RunWorkflow(). This assigns the current thread of execution to the workflow to handle the next item on the queue, namely, the execution of the workflow. When the workflow completes, terminates, or goes idle, the call to RunWorkflow() will complete and return control to the host. Similarly, after sending a message to an idled workflow in this environment, the message will not be processed until RunWorkflow() is called again. This is similar to kicking a can down the street. It will roll and do some work, but it will reach a point at which it stops and waits to be kicked again in order to continue down the street. In Listing 5.17, note that the workflow will not process the event raised by the local service until RunWorkflow() has been called. RunWorkflow() will give the current thread to the runtime in order to execute a specific instance of the workflow until that instance completes or goes idle.

public bool OrderProcess(Order order)
{
    ManualWorkflowSchedulerService schedulerService =
    workflowRuntime.GetService<ManualWorkflowSchedulerService>();
    orderLocalService.RaiseProcessing(order.WorkflowID);
    schedulerService.RunWorkflow(order.WorkflowID);
    // RunWorkflow completes when the workflow completes or goes idle
    return true;
}

The persistence, tracking, and scheduler services are the most common services a workflow developer will encounter. Writing a scheduler service is not a common task, but the choice between the default and manual services is one that will be frequently encountered. The persistence and tracking services have been optimized for the general scenario, and it is not uncommon to find developers writing a custom version of one or both of these services. In the case of the tracking service, the services can be “stacked” on top of one another, allowing multiple means of tracking. The persistence service is more fundamental to the operation of the runtime, so only one of those is allowed. The runtime services do not stop there, however; a developer might encounter a number of other services, and in some scenarios, want to customize them.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <configSections>
        <section name="WorkflowServiceContainer" type="System.Workflow.Runtime
.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=1.0.0.0,
 Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    </configSections>
    <WorkflowServiceContainer Name="Container Name" UnloadOnIdle="true">
         <CommonParameters>
           <add name="ConnectionString" value="Initial Catalog=WorkFlowStore;Data
 Source=localhost;Integrated Security=SSPI;" />
        </CommonParameters>
        <Services>
            <add type="System.Workflow.Runtime.Hosting. DefaultWorkflowSchedulerService, 
System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
           <addtype="System.Workflow.Runtime.Hosting.
 SharedConnectionWorkflowTransactionService, System.Workflow.Runtime, Version=1.0.0.0,
 Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
            <add type="System.Workflow.Runtime.Tracking.SqlTrackingService, System
.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
            <add type="System.Workflow.Runtime.Hosting. SqlWorkflowPersistenceService,
 System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
        </Services>
    </WorkflowServiceContainer>
    <system.diagnostics>
    </system.diagnostics>
</configuration>

As rule sets become increasingly complicated, there will inevitably exist dependencies between rules. Rule 4 might base the discount on the expected profit from the order. Rule 10 might perform an analysis of the customer’s delinquency rate and change the expected profit based on a new probability that the customer might not pay. Now that this expected profit has changed, what becomes of rule 4? It might be that the business requirement is that this rule should be evaluated again. This is referred to as the forward-chaining behavior of a rules engine. The rules engine is responsible for detecting such dependencies and selectively re-executing rules based on changes to the facts that the conditions depend on. Consider the rule set in Table 5.2.

For inputs, Order.Total = 1200, Shipping = 0, and ShipToState = 'WA'.

The execution of this rule set is as shown in Table 5.3.

As rule sets contain more rules, the evaluation pattern will become increasingly complicated. Consider modeling this execution behavior in code, especially the ability to reevaluate rules when the facts it depends on change. This code would quickly spiral out of any state of maintainability and not easily allow new rules to be added. Something such as a pricing policy might be extremely flexible, and rule-based calculation enables that flexibility.

Forward chaining can be used to evaluate across a collection of objects as well. Consider an Order object with an array of OrderItem objects. Additionally, consider a counter variable, i, an integer initialized to 0. Using the following rule set:

With this single rule, the ProcessItem() method will be called for each item. The execution is easy to trace: evaluate initially, process the item for the counter, and then increase the counter. Increasing the counter changes the fact the rule depends on, forcing its reevaluation. To make this more robust, a higher priority rule should be executed that initializes the counter to 0.

The previous examples have focused on rules executing within the context of a workflow, with the object being operated on as the workflow class. But this is simply a matter of how the functionality is surfaced. A rule set can execute against any .NET object, any custom class that one creates may be the target of a rule set. The following steps are necessary to execute rules against an arbitrary object:

The code in Listing 5.25 does this.

RuleExecution ruleExecution;
WorkflowMarkupSerializer serializer = new WorkflowMarkupSerializer();
XmlTextReader reader = new XmlTextReader(new StringReader(ruleSetXmlString));
RuleSet ruleSet = serializer.Deserialize(reader) as RuleSet;
//check that rules are valid
RuleValidation ruleValidation = new RuleValidation(executionObject.GetType(), null);
if (!ruleSet.Validate(ruleValidation))
{
    // handle errors
}
else
{
    ruleExecution = new RuleExecution(ruleValidation, executionObject);
}
ruleSet.Execute(ruleExecution);

This can be generalized to scenarios where processing occurs on many clients, but it is desirable to have a central rule store to ensure that all the clients are always using the same rule policies.