Matt W's Windows Workflow Place : activities

Finding the Variables in Scope Within the WF Designer

mwinkle — Fri, 06 Nov 2009 06:21:35 GMT

In this thread, one of our forum customers asked the question:

“how do I find all of the variables that are in scope for a given activity in the designer?”

We do not have a public API to do this. Internally we have a helper type called VariableHelper that we use to display the list of variables in the variable designer, as well as passed into the expression text box intellisense control.

One thing that I would like to point out is that if you are implementing your expression editor and want to be able to enumerate the variables (to highlight the tokens that are in scope), your implementation of IExpressionEditorService.CreateExpressionEditor() will get a list of model items that correspond to the inscope variables.

Now, if you are not building an expression editor, and want to be able to enumerate all of the in scope variables, you will need to do a little more work. Here are the basic steps

Go to parent container
Does it contain variables*
Does it have a parent?
Go to parent’s parent
Repeat from step 2

* This is basically the tricky part, because it is not something we can cleanly determine (and it can also be altered at runtime by adding some additional ones via the CacheMetadata() method. I’ll describe what the designer is currently doing to accumulate this list, and then talk about designs we could have in a future release.

Current Approach

Currently, there are two things that we look for when we navigate up the model item tree.

Collections of Variables name Variables
Variables injected by the use of ActivityAction

As we walk up the tree, we need to find these. Let’s first consider the following workflow we will use for our tests:

   1:  wd.Load(new Sequence

   2:  {

   3:      Activities =

   4:      {

   5:          new Sequence

   6:          {

   7:              Activities =

   8:              {

   9:                  new ForEach<string>

  10:                  {

  11:                      Body = new ActivityAction<string>

  12:                      {

  13:                           Argument = new DelegateInArgument<string> { Name="foo" },

  14:                           Handler =

  15:                              new Sequence

  16:                              {

  17:                                  Activities =

  18:                                  {

  19:                                      new WriteLine()

  20:                                  }

  21:                              }

  22:                      }

  23:                  }

  24:              }

  25:          }

  26:      }

  27:  });

Line 13 is the only one that might look a little different here, I’ll eventually have a post up about ActivityAction that talks in more detail what’s going on there.

So, this loaded in a rehosted designer looks like the following:

Now, let’s look at the code to figure out what is in scope of the selected element. First, let’s get the selected element :-)

 Selection  sel = wd.Context.Items.GetValue<Selection>();
 if (sel != null)
 {
        ModelItem mi = sel.PrimarySelection;

mi is now the model item of my selected item. Let’s write some code to walk up the tree and add to a collection called variables

   1:  while (mi.Parent != null)

   2:  {

   3:      Type parentType = mi.Parent.ItemType;

   4:      if (typeof(Activity).IsAssignableFrom(parentType))

   5:      {

   6:          // we have encountered an activity derived type

   7:          // look for variable collection

   8:          ModelProperty mp = mi.Parent.Properties["Variables"];

   9:          if (null != mp && mp.PropertyType == typeof(Collection<Variable>))

  10:          {

  11:              mp.Collection.ToList().ForEach(item => variables.Add(item));

  12:          }

  13:      }

  14:      // now we need to look action handlers

  15:      // this will ideally return a bunch of DelegateArguments

  16:      var dels = mi.Properties.Where(p => typeof(ActivityDelegate).IsAssignableFrom(p.PropertyType));

  17:      foreach (var actdel in dels)

  18:      {

  19:          if (actdel.Value != null)

  20:          {

  21:              foreach (var innerProp in actdel.Value.Properties)

  22:              {

  23:                  if (typeof(DelegateArgument).IsAssignableFrom(innerProp.PropertyType) && null != innerProp.Value)

  24:                  {

  25:                      variables.Add(innerProp.Value);

  26:                  }

  27:              }

  28:          }

  29:      }

30:

31:

  32:      mi = mi.Parent;

  33:  }

Lines 4-13 handle the case where I just encounter an activity. Lines 16-29 handle the slightly more tricky case where I need to handle ActivityAction (which ultimately derives from ActivityDelegate). There are a few loops there but basically I look through all of the properties of the item which inherit from ActivityDelegate. For each one of those, and for each property on that, I look for properties assignable from DelegateArgument. As I find them I add them to my collection of model items for variables.

In my WPF app, I have a simple list box that shows all of these. Because of the loosely typed data template I use in my WPF app, I get a pretty decent display since they share common things like ItemType from ModelItem, and a Name that routes through to the underlying Name property both elements share.

<ListBox Name="listBox1" Grid.Row="1" Grid.ColumnSpan="2" Grid.Column="0">

    <ListBox.ItemTemplate>

        <DataTemplate>

            <StackPanel Orientation="Horizontal">

                <TextBlock>Foo:</TextBlock>

                <TextBlock FontWeight="Bold" Text="{Binding Path=ItemType}"/>

                <TextBlock Text="{Binding Path=Name}"/>

            </StackPanel>

        </DataTemplate>

    </ListBox.ItemTemplate>

</ListBox>

Potential Future Approach

Our approach outlined above is generally correct. That said, you can imagine a deeply nested data structure on an activity that contain variables that get injected into the scope at runtime. We need a way for an activity to provide a way to declare how to get all of its variables. The current approach is one of inspection, which works for all of our activities. In the future we may need to add an extensibility point to allow an activity author to specify how to find the variables that are available to its children. The way that we could do that is to introduce an “VariableResolver” attribute which points to a type (or maybe a Func<>) that operates on the activity and returns the list of variables. Actually today you could likely introduce a custom type descriptor that lifted the variables out of the activity and surfaces them in such a way that they would be discovered by the inspection above.

Disclaimer: the Potential Future Approach is simply something that we’ve discussed that we could do, it does not represent something that we will do. If you think that is an interesting extensibility point that you might want to take advantage of down the road, let me know.

Activities Survey

mwinkle — Fri, 19 Oct 2007 00:29:20 GMT

So, we're getting close to .NET 3.5 getting out the door, and as always we're thinking about what comes next. The activities team is looking how to make activities better going forward, and they are very interested in what you have to say, how you have been using them and how you'd like to use them.

This feedback will help us understand how to shape the future of things and how we should think about the pain points you are experiencing.

Fill survey out here!

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.

Dynamically Generating an Operation Contract in Orcas using WF

mwinkle — Fri, 27 Apr 2007 19:45:00 GMT

This kicks off a set of posts where I'll be discussing some of the interesting features coming out in Orcas.

I want to focus on this post on the Receive Activity, and a nice little feature in the designer that lets you create a contract on the fly, without having to drop into code and write a decorated interface. This allows us to divide the world into two approaches:

One where I design my contract first, and then start creating a workflow to implement the operations on the contract.
Design my workflow first, and have it figure out the contract for me (this is what I will focus on in more detail)

Designing a Contract First

This is what most WCF folks will be familiar with:

[ServiceContract]
public interface IOrderProcessing
{

    [OperationContract]
    bool SubmitOrder(Order order);

    [OperationContract]
    Order[] GetOrders(int customerId);
}

When I drop a receive activity onto a workflow, I can now import this contract:

This will bring up a type chooser that lets me pick my service contract:

This imports all of the details and we can see the the operation picker

If we look at the activity properties we now see the parameters to the method. The (ReturnValue) is the object that we need to return in the operation. The order parameter is the message that is going to be passed when the method is called. I can take that and bind that to values in my workflow or whatever I want to do with it.

Designing a Workflow First

The other approach we can take is to create the contract as we create the workflow. That's right, we don't need to create the contract explicitly in code. To do that, drop a receive activity onto the designer and double click. Instead of selecting "Import Contract" select "Add Contract". This will create a new contract with a basic operation. By selecting the contract or the operation we can name it something a little nicer.

By selecting the operation, I can customize all of its behavior. I can create parameters to be passed in, I can set the types of those parameters (as well as the return type of the operation).

It's relevent to point out that I can select any type that would be valid in a WCF contract. The drop down list displays the basic types, but by selecting "Browse Type" I am brought into a type picker where I can select custom types. As you can see below I have created a "CancelOrder" operation that takes in an order, the reason and who authorized the cancellation.

When I click ok, my activity has had new dependency properties added to it, as can be seen in the property grid for the activity.

So what's happening here?

In the workflow I created, I used a code separation workflow, so I have an .xoml file which contains the workflow definition. Let's take a quick peek at how the receive activity is defined (note, some of the xml is truncated, if you view in an rss reader or copy and past you can see all the details, I'll work on updating the blog layout):

    <ns0:ReceiveActivity x:Name="receiveActivity2">
        <ns0:ReceiveActivity.ServiceOperationInfo>
            <ns0:OperationInfo PrincipalPermissionRole="administrators" Name="CancelOrder" ContractName="MyContract">
                <ns0:OperationInfo.Parameters>
                    <ns0:OperationParameterInfo Attributes="Out, Retval" ParameterType="{x:Type p9:Boolean}" Name="(ReturnValue)" Position="-1" xmlns:p9="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                    <ns0:OperationParameterInfo Attributes="In" ParameterType="{x:Type p9:Order}" Name="order" Position="0" xmlns:p9="clr-namespace:WcfServiceLibrary1;Assembly=WcfServiceLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                    <ns0:OperationParameterInfo Attributes="In" ParameterType="{x:Type p9:String}" Name="reason" Position="1" xmlns:p9="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                    <ns0:OperationParameterInfo Attributes="In" ParameterType="{x:Type p9:String}" Name="authorizedBy" Position="2" xmlns:p9="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                </ns0:OperationInfo.Parameters>
            </ns0:OperationInfo>
        </ns0:ReceiveActivity.ServiceOperationInfo>
    </ns0:ReceiveActivity>

Here you can see that within the metadata of the activity, we have the definition for the contract and the operation that I defined. When we spin up a WorkflowServiceHost to host this workflow as a service, the host will inspect the metadata for the workflow, looking for all of the endpoints and will create them. You can also see within the OperationInfo element that I am able to define the PrincipalPermissionRole defining the role of allowed callers, taking advantage of the static security checks which I will talk about in another post. So, defined declaratively in the XAML is the contract for the operations. I didn't need to write the interface or the contract explicitly, I was able to write a workflow, specifiy in the workflow how it will communicate and then let the WorkflowServiceHost figure out the nitty gritty details of how create the endpoints. The other part here that is important to mention is that the config will play a part determining what the transport channel and other such details will be. Within the config, when we set up an endpoint we need to specify the contract is "MyContract", or the name that we assigned when we created it.

Summary

We talked about the way that we can implement contracts that already exist in a receive activity, as well as how we can use the designer to actually create our contract while we are designing the workflow. The WorkflowServiceHost does the heavy lifting here in order to enable this little bit of nifty-ness.

Mechanical Turk Activities

mwinkle — Wed, 07 Feb 2007 21:05:00 GMT

Mark Blomsma has put together some activities and an article which shows how to interact with Amazon's Mechanical Turk with WF activities.

I've linked to the sample on here.

Cool, cool, cool