Matt W's Windows Workflow Place : patterns

Advanced Workflow Service Talk (Demo 4 of 4)

mwinkle — Mon, 11 Aug 2008 18:52:10 GMT

When we start doing this two way style of messaging, we now open up to start modeling some interesting business problems. In the previous post, you'll note that I did not include the code, because I mentioned we needed to be more clever in scenarios where we listen in parallel.

First, a brief diversion into how the Receive activity works. Everybody remembers the workflow queues, the technology that underlies all communication between a host and a workflow instance. The Receive activity works by creating a queue that the WorkflowServiceHost (specifically the WorkflowOperationInvoker) will use to send the message received off the wire into the workflow. Now, the Receive activity normally just creates a queue that is named the same as the operation the Receive activity is bound to. However, if we have two Receive activities listening for the same operation at the same time, no longer is a single queue useful to route responses back as we want to route to the correct Receive activity instance.

There is property on the Receive activity called ContextToken. Normally this is null in the simple case. However, when we want our Receive activity to operate in parallel, we need to indicate that it needs to be smarter when it creates a queue.

By setting this property (you can just type in a name, and then select the common owner all of the parallel receive's share. This will cause the Receive activity to create a queue named [OperationName] +[ConversationId], the conversation ID takes the form of a GUID, and is the second element inside a context token.

The sample that I show for this talk is simply the conversations sample inside the SDK. This is the sample to check out to understand all sorts of interesting ways to use the context tokens to model your processes.

Now, there are two conversation patterns here. One is the one shown above, which I refer to as an n-party conversation where n is fixed at design time. We can accomplish this with the parallel activity. The other is where n is arbitrary (imagine you send out to business partners stored in the database). The way to do this is to use the Replicator activity. The Replicator is a little known gem shipped in 3.0 that essentially gives you "ForEach" semantics. But, by flipping the ExecutionType switch to parallel, I now get the behavior of a parallel, but operating with an arbitrary n branches.

So, in order to enable conversations, we need to tell our receive activity to be a little smarter about how it generates its queue name, and then we simply follow the duplex pattern we discussed in the last two posts. Once we do that, we're in good shape to start modeling some more interesting communication patterns between multiple parties.

Where can we go from here?

We can just make the patterns more interesting. One interesting one would be the combination of the long running work with cancellation and a Voting activity in order to coordinate the responses and allow for progress to be made when some of the branches complete (if I have 3 yes votes, I can proceed). The power of building composite activities is that it gives me a uniform programming model (and a single threaded one to boot) in order to handle the coordination of different units of work. Get out there and write some workflows :-)

N of M Question (Why Use ActivityExecutionContextManager?)

mwinkle — Mon, 09 Jul 2007 19:32:21 GMT

In this post, mstiefel asked the following:

# re: Implementing the N of M Pattern in WF

Since you are not looping, do you have to use the ActivityExecutionContextManager to generate a new context for the child activities? Couldn't you use the context passed into the Execute method?
Friday, July 06, 2007 7:54 PM by mstiefel

If I were creating a parallel activity, and simply wanted to execute a number of distinct child activities, I would just use the passed in context as you suggest to schedule execution of each of the activities. The difference here is subtle, and that is I don't have distinct child activities, I have one child activity which I need to clone m times and execute those cloned children separately. The need to create the context is so that each one of those clones maintains it's own execution context, what variables are where, who is in what state, etc. This is important while executing, and while after completion in the need where I want to compensate for the individual activities.

This line

ActivityExecutionContext newContext = aecm.CreateExecutionContext(this.Activities[0]);

is what will cause the activity to be cloned, allowing me to schedule the execution of the clone, and not the template activity (which, incidentally, will never be scheduled, leaving me with m+1 copies of the activity. This is the same behavior that I get in a While or a Replicator (or the CAG, depending upon how it is configured). A state machine workflow will do a similar thing as I may re-enter a state multiple times.

If, instead of allowing a user to specify the list of approvers and dynamically creating the activities, I designed it so that a user would have to drop and configure an activity for each approval (similar to the parallel activity), I would have used code like this:

// Code to schedule distinct activities in parallel, aka code similar to the parallel activity
protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
{
        foreach (Activity activity in ChildActivities)
        {
            // i is some counter I use to track how many branches there are so I know when
            // I am done
            i++;
            // I'm interested in what happens when this guy closes.
            activity.RegisterForStatusChange(Activity.ClosedEvent, this);
            executionContext.ExecuteActivity(activity);
        }
        return ActivityExecutionStatus.Executing;
}

Implementing the N of M Pattern in WF

mwinkle — Wed, 27 Jun 2007 03:38:27 GMT

The second in my series of alternate execution patterns (part 1)

I recently worked with a customer who was implementing what I would call a "basic" human workflow system. It tracked approvals, rejections and managed things as they moved through a customizable process. It's easy to build workflows like this with an Approval activity, but they wanted to implement a pattern that's not directly supported out of the box. This pattern, which I have taken to calling "n of m", is also referred to as a "Canceling partial join for multiple instances" in the van der Aalst taxonomy.

The basic description of this pattern is that we start m concurrent actions, and when some subset of those, n, complete, we can move on in our process and cancel the other concurrent actions. A common scenario for this is where I want to send a document for approval to 5 people, and when 3 of them have approved it, I can move on. This comes up frequently in human or task-based workflows. There are a couple of "business" questions which have to be answered as well, the implementation can support any set of answers for this:

What happens if an individual rejects? Does this stop the whole group from completing, or is it simply noted as a "no" vote?
How should delegation be handled? Some business want this to break out from the approval process at this point.

The first approach the customer took was to use the ConditionedActivityGroup (CAG). The CAG is probably one of the most sophisticated out of the box activities that we ship in WF today, and it does give you a lot of control. It also gives you the ability to set the Until condition which would allow us to specify the condition that the CAG could complete, and the others would be cancelled (see Using ConditionedActivityGroup)

ConditionedActivityGroup

What are pros and cons of this approach:

Pros

Out of the box activity, take it and go
Focus on approval activity
Possibly execute same branch multiple times

Cons

Rules get complex ( what happens if the individual rejections causes everything to stop)
I need to repeat the same activity multiple times (especially in this case, it's an approval, we know what activity needs to be in the loop)
I can't control what else a developer may put in the CAG
We may want to execute on some set of approvers that we don't know at design time, imagine an application where one of the steps is defining the list of approvers for the next step. The CAG would make that kind of thing tricky.

This led us to the decision to create a composite activity that would model this pattern of execution. Here are the steps we went through:

Build the Approval activity

The first thing we needed was the approval activity. Since we know this is going to eventually have some complex logic, we decided to take the basic approach of inheriting from SequenceActivity and composing our approval activity out of other activities (sending email, waiting on notification, handling timeouts, etc.). We quickly mocked up this activity to have an "Approver" property, a property for a timeout (which will go away in the real version, but is useful to put some delays into the process. We also added some code activities which Console.WriteLine 'd some information out so we knew which one was executing. We can come back to this later and make it arbitrarily complex. We also added the cancel handler so that we can catch when this activity is canceled (and send out a disregard email, clean up the task list ,etc). Implementing ICompensatableActivity may also be a good idea so that we can play around with compensation if we want to (note, that we will only compensate the closed activities, not the ones marked as canceled).

Properties of the Approval Activity

Placing the Approval Activity inside our NofM activity.

What does the execution pattern look like?

Now that we have our approval activity, we need to determine how this new activity is going to execute. This will be the guide that we use to implement the execution behavior. There are a couple of steps this will follow

Schedule the approval's to occur in parallel, one per each approver submitted as one of the properties
Wait for each of those to finish.
When one finishes, check to see if the condition to move onward is satisfied (in this case, we increment a counter towards a "number of approvers required" variable.
If we have not met the criteria, we keep on going. [we'll come back to this, as we'll need to figure out what to do if this is the last one and we still haven't met all of the criteria.]
If we have met the criteria, we need to cancel the other running activities (they don't need to make a decision any more).
Implement the easy part of this (scheduling the approvals to occur in parallel)

I say this is the easy part as this is documented in a number of places, including Bob and Dharma's book. The only trickery occurring here is that we need to clone the template activity, that is the approval activity that we placed inside this activity before we started working on it. This is a topic discussed in Nate's now defunct blog.

    protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
    {
        // here's what we need to do.
        // 1.> Schedule these for execution, subscribe to when they are complete
        // 2.> When one completes, check if rejection, if so, barf
        // 3.> If approve, increment the approval counter and compare to above
        // 4.> If reroute, cancel the currently executing branches.
        ActivityExecutionContextManager aecm = executionContext.ExecutionContextManager;
        int i = 1;
        foreach (string approver in Approvers)
        {
            // this will start each one up.
            ActivityExecutionContext newContext = aecm.CreateExecutionContext(this.Activities[0]);
            GetApproval ga = newContext.Activity as GetApproval;
            ga.AssignedTo = approver;
            // this is just here so we can get some delay and "long running ness" to the
            // demo
            ga.MyProperty = new TimeSpan(0, 0, 3 * i);
            i++;
            // I'm interested in what happens when this guy closes.
            newContext.Activity.RegisterForStatusChange(Activity.ClosedEvent, this);
            newContext.ExecuteActivity(newContext.Activity);
        }
        return ActivityExecutionStatus.Executing;
    }

Code in the execute method

One thing that we're doing here is RegisterForStatusChange() This is a friendly little method that will allow me to register for a status change event (thus it is very well named). This is a property of Activity, and I can register for different activity events, like Activity.ClosedEvent or Activity.CancelingEvent. On my NofM activity, I implment IActivityEventListener of type ActivityExecutionStatusChangedEvent (check out this article as to what that does and why). This causes me to implement OnEvent which since it comes from a generic interface is now strongly typed to accept the right type of event arguments in. That's always a neat trick that causes me to be thankful for generics. That's going to lead us to the next part.

Implement what happens when one of the activities complete

Now we're getting to the fun part of how we handle what happens when one of these approval activities return. For the sake of keeping this somewhat brief, I'm going to work off the assumption that a rejection does not adversely affect the outcome, it is simply one less person who will vote for approval. We can certainly get more sophisticated, but that is not the point of this post! ActivityExecutionStatusChangedEventArgs has a very nice Activity property which will return the Activity which is the one that caused the event. This let's us find out what happened, what the decision was, who it was assigned to, etc. I'm going to start by putting the code for my method in here and then we'll walk through the different pieces and parts.

public void OnEvent(object sender, ActivityExecutionStatusChangedEventArgs e)
{
    ActivityExecutionContext context = sender as ActivityExecutionContext;
    // I don't need to listen any more
    e.Activity.UnregisterForStatusChange(Activity.ClosedEvent, this);
    numProcessed++;
    GetApproval ga = e.Activity as GetApproval;
    Console.WriteLine("Now we have gotten the result from {0} with result {1}", ga.AssignedTo, ga.Result.ToString());
    // here's where we can have some additional reasoning about why we quit
    // this is where all the "rejected cancels everyone" logic could live.
    if (ga.Result == TypeOfResult.Approved)
        numApproved++;
    // close out the activity
    context.ExecutionContextManager.CompleteExecutionContext(context.ExecutionContextManager.GetExecutionContext(e.Activity));
    if (!approvalsCompleted  && (numApproved >= NumRequired))
    {
        // we are done!, we only need to cancel all executing activities once
        approvalsCompleted = true;
        foreach (Activity a in this.GetDynamicActivities(this.EnabledActivities[0]))
            if (a.ExecutionStatus == ActivityExecutionStatus.Executing)
                context.ExecutionContextManager.GetExecutionContext(a).CancelActivity(a);
    }
    // are we really done with everything? we have to check so that all of the 
    // canceling activities have finished cancelling
    if (numProcessed == numRequested)
        context.CloseActivity();  
}

Code from "OnEvent"

The steps here, in English

UnregisterForStatusChange - we're done listening.
Increment the number of activities which have closed (this will be used to figure out if we are done)
Write out to the console for the sake of sanity
If we've been approved, increment the counter tracking how many approvals we have
Use the ExecutionContextManager to CompleteExecutionContext, this marks the execution context we created for the activity done.
Now let's check if we have the right number of approvals, if we do, mark a flag so we know we're done worrying about approves and rejects and then proceed to cancel the activities. CancelActivity. CancelActivity schedules the cancellation, it is possible that this is not a synchronous thing (we can go idle waiting for a cancellation confirmation, for instance.
Then we check if all of the activities have closed. What will happen once the activities are scheduled for cancellation is that each one will eventually cancel and then close. This will cause the event to be raised and we step through the above pieces again. Once every activity is done, we finally close out the activity itself.

Using it

I placed the activity in a workflow, configured it with five approvers and set it for two to be required to move on. I also placed a code activity outputting "Ahhh, I'm done". I also put a Throw activity in there to raise an exception and cause compensation to occur to illustrate that only the two that completed are compensated for.

So, what did we do?

Create a custom composite activity with the execution logic to implement an n-of-m pattern
Saw how we can use IEventActivityListener in order to handle events raised by our child activities
Saw how to handle potentially long running cancellation logic, and how to cancel running activities in general.
Saw how compensation only occurs for activities that have completed successfully

Extensions to this idea:

More sophisticated rules surrounding the approval (if a VP or two GM's say no, we must stop)
Non binary choices (interesting for scoring scenarios, if the average score gets above 95%, regardless of how many approvers remaining, we move on)
Create a designer to visualize this, especially when displayed in the workflow monitor to track it
Validation (don't let me specify 7 approvals required, and only 3 people)

Different Execution Patterns with WF (or, Going beyond Sequential and State Machine)

mwinkle — Fri, 25 May 2007 00:34:49 GMT

How do I do this?

A lot of times people get stuck with the impression that there are only two workflow models available: sequential and state machine. True, out of the box these are the two that are built in, but only because there are is a set of common problems that map nicely into their execution semantics. As a result of these two being "in the box," I often see people doing a lot of very unnatural things in order to fit their problem into a certain model.

The drawing above illustrates the flow of one such pattern. In this case, the customer wanted parallel execution with two branches ((1,3) and (2,5)). But, they had an additional factor that played in here, 4 could execute, but it could only execute when both 1 and 2 had completed. 4 didn't need to wait for 3 and 5 to finish, 3 and 5 could take a long period of time, so 4 could at least start once 1 and 2 were completed. Before we dive into a more simple solution, let's look at some of the ways they tried to solve the problem, in an attempt to use "what's in the box."

The "While-polling" approach

The basic idea behind this approach is that we will use a parallel activity, and in the third branch we will place a while loop that loops on the condition of "if activity x is done" with a brief delay activity in there so that we are not busy polling. What's the downside to this approach:

The model is unnatural, and gets more awkward given the complexity of the process (what do we do if activity 7 has a dependency on 4 and 5)
The polling and waiting is just not an efficient way to solve the problem
This Is a lot to ask a developer to do in order to translate the representation she has in her head (first diagram, with the model we are forcing into).

The SynchScope approach

WF V1 does have the idea of synchronizing some execution by using the SynchronizationScope activity. The basic idea behind the SynchronizationScope is that one can specify a set of handles that the activity must be able to acquire before allowing it's contained activities to execute. This let's us serialize access and execution. We could use this to mimic some of the behavior that the polling is doing above. We will use sigma(x, y, z) to indicate the synchronization scope and it's handles (just because I don't get to use nearly as many Greek letters as I used to).

This should work, provided the synchronization scopes can obtain the handles in the "correct" or "intended" order. Again, the downside here is that this gets to be pretty complex, how do we model 4 having a dependency on 3 and 2? Well, our first synchronization scope now needs to extend to cover the whole left branch, and then it should work. For the simple case like the process map I drew at the beginning, this will probably work, but as the dependency map gets deeper, we are going to run into more problems trying to make this work.

Creating a New Execution Pattern

WF is intended to be a general purpose process engine, not just a sequential or state machine process engine. We can write our own process execution patterns by writing our own custom composite activity. Let's first describe what this needs to do:

Allow activities to be scheduled based on all of their dependent activities having executed.
- We will start by writing a custom activity that has a property for expressing dependencies. A more robust implementation would use attached properties to push those down to any contained activity
Analyze the list of dependencies to determine which activities we can start executing (perhaps in parallel)
When any activity completes, check where we are at and if any dependencies are now satisfied. If they are, schedule those for execution.

So, how do we go about doing this?

Create a simple activity with a "Preconditions" property

In the future, this will be any activity using an attached property, but I want to start small and focus on the execution logic. This one is a simple Activity with a "Preconditions" array of strings where the strings will be the names of the activities which must execute first:

public partial class SampleWithPreconProperty: Activity
{
    public SampleWithPreconProperty()
    {
        InitializeComponent();
    }

    private string[] preconditions = new string[0];

    public string[] Preconditions
    {
        get { return preconditions; }
        set { preconditions = value; }
    }

Create the PreConditionExecutor Activity

Let's first look at the declaration and the members:

[Designer(typeof(SequentialActivityDesigner),typeof(IDesigner))]
public partial class PreConditionExecutor : CompositeActivity
{
    // this is a dictionary of the executed activities to be indexed via
    // activity name
    private Dictionary<string, bool> executedActivities = new Dictionary<string, bool>();

    // this is a dictionary of activities marked to execute (so we don't 
    // try to schedule the same activity twice)
    private Dictionary<string, bool> markedToExecuteActivities = new Dictionary<string, bool>();

    // dependency maps
    // currently dictionary<string, list<string>> that can be read as 
    // activity x has dependencies in list a, b, c
    // A more sophisticated implementation will use a graph object to track
    // execution paths and be able to check for completeness, loops, all
    // that fun graph theory stuff I haven't thought about in a while
    private Dictionary<string, List<string>> dependencyMap = new Dictionary<string, List<string>>();

We have three dictionaries, one to track which have completed, one for which ones are scheduled for execution, and one to map the dependencies. As noted in the comments, a directed graph would be a better representation of this so that we could do some more sophisticated analysis on it.

Now, let's look at the Execute method, the one that does all the work.

protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
{
    if (0 == Activities.Count)
    {
        return ActivityExecutionStatus.Closed;
    }
    // loop through the activities and mark those that have no preconditions
    // as ok to execute and put those in the queue
    // also generate the graph which will determine future activity execution.
    foreach (Activity a in this.Activities)
    {
        // start with our basic activity
        SampleWithPreconProperty preconActivity = a as SampleWithPreconProperty;
        if (null == preconActivity)
        {
            throw new Exception("Not right now, we're not that fancy");
        }
        // construct the execution dictionary
        executedActivities.Add(a.Name, false);
        markedToExecuteActivities.Add(a.Name, false);
        List<string> actDependencies = new List<string>();
        if (null != preconActivity.Preconditions)
        {
            foreach (string s in preconActivity.Preconditions)
            {
                actDependencies.Add(s);
            }
        }
        dependencyMap.Add(a.Name, actDependencies);
    }
    // now we have constructed our execution map and our dependency map
    // let's do something with those, like find those activities with
    // no dependencies and schedule those for execution.
    foreach (Activity a in this.Activities)
    {
        if (0 == dependencyMap[a.Name].Count)
        {
            Activity executeThis = this.Activities[a.Name];
            executeThis.Closed += currentlyExecutingActivity_Closed;
            markedToExecuteActivities[a.Name] = true;
            executionContext.ExecuteActivity(this.Activities[a.Name]);
            Console.WriteLine("Scheduled: {0}", a.Name);
        }
    }
    return ActivityExecutionStatus.Executing;
}

Basically, we first construct the execution tracking dictionaries, initializing those to false. We then create the dictionary of dependencies. We then loop through the activities and see if there are any that have no dependencies (there has to be one, this would be a good point to raise an exception if there isn't. We record in the dictionary that this one has been marked to execute and then we schedule it for execution (after hooking the Closed event so that we can do some more work later). So what happens when we close?

void currentlyExecutingActivity_Closed(object sender, ActivityExecutionStatusChangedEventArgs e)
{
    e.Activity.Closed -= this.currentlyExecutingActivity_Closed;
    if (this.ExecutionStatus == ActivityExecutionStatus.Canceling)
    {
        ActivityExecutionContext context = sender as ActivityExecutionContext;
        context.CloseActivity();
    }
    else if (this.ExecutionStatus == ActivityExecutionStatus.Executing)
    {
        // set the Executed Dictionary
        executedActivities[e.Activity.Name] = true;
        if (executedActivities.ContainsValue(false) /* keep going */)
        {
            // find all the activities that contain the precondition 
            // and remove them, and then cycle through any that have 0 
            // preconditions (and have not already executed or are marked
            // to execute
            // who contains this precondition? 
            foreach (Activity a in this.Activities)
            {
                // filter out those activities executed or executing
                if (!(executedActivities[a.Name] || markedToExecuteActivities[a.Name]))
                {
                    if (dependencyMap[a.Name].Contains(e.Activity.Name))
                    {
                        // we found it, remove it
                        dependencyMap[a.Name].Remove(e.Activity.Name);
                        // if we now have no dependencies, let's schedule it
                        if (0 == dependencyMap[a.Name].Count)
                        {
                            a.Closed += currentlyExecutingActivity_Closed;
                            ActivityExecutionContext context = sender as ActivityExecutionContext;
                            markedToExecuteActivities[a.Name] = true;
                            context.ExecuteActivity(a);
                            Console.WriteLine("Scheduled: {0}", a.Name);
                        }
                    }
                }
            }
        }
        else //close activity
        {
            ActivityExecutionContext context = sender as ActivityExecutionContext;
            context.CloseActivity();
        }
    }
}

There are a few lines of code here, but it's pretty simple what's going on.

We remove the event handler
If we're still executing, mark the list of activities appropriately
Loop through and see if any of them have dependencies on the activity which just now completed being done
If they do, remove that entry from the dependency list and check if we can run it (if the count == 0). If we can, schedule it, otherwise keep looping.
If all the activities have completed (there is no false in the Executed list) then we will close out this activity.

To actually use this activity, we place it in the workflow, place a number of the child activity types within it (again, with the attached property, you could put nearly any activity in there) and specify the activities that it depends on. Since I haven't put a designer on it, I just use the SequenceDesigner. Here's what it looks like (this is like the graph I drew above but kicks off with the "one" activity executing first:

Where can we go from here

Validation, remember all that fun graph theory stuff checking for cycles and completeness and no gaps. Yeah, we should probably wire some of that stuff up here to make sure we can actually execute this thing
Analysis of this might be interesting, especially as the process gets more complex (identifying complex dependencies, places for optimization, capacity stuff)
A designer to actually do all of this automatically. Right now, it is left as an exercise to the developer to express the dependencies by way of the properties. It would be nice to have a designer that would figure that out for you, and also validate so you don't try to do the impossible.
Make this much more dynamic and pull in the preconditions and generate the context for the activities on the fly. This would be cool if you had a standard "approval" activity that you wanted to have a more configurable execution pattern. You could build the graph through the designer and then use that to drive the execution

I'm going to hold off on posting the code, as I've got a few of these and I'd like to come up with some way to put them out there that would make it easy to get to them and use them. You should be able to pretty easily construct your own activity based on the code presented here.