In my last post I pointed to a screencast I had recorded that showed how to create a custom message filter to plug your own logic into the WCF 4.0 Routing Service. However, the simple custom filter is only the start – you can actually take control of part of the routing table which allows you to make global decisions about which filters match a particular request. On that basis I have created another screencast that shows how to build one of these more complex custom filters. in this case I use the example of a round robin load balancer where you can use a file on the file system to indicate whether a specific endpoint should be considered part of the load balancing algorithm

You can find this last in the series of screencasts on the routing service, along with all the others here, on the Rock Solid Knowledge site

http://rocksolidknowledge.com/ScreenCasts.mvc

Continuing my screencast series on the Routing Service in WCF 4.0, I have just uploaded one on Data Dependent Routing

You can get to the latest screencast (and all of the others) here http://rocksolidknowledge.com/ScreenCasts.mvc

I have just published my second screencast on one of the new features of WCF 4.0 – the Routing Service. This screencast focuses on enabling multicast and failover with the Routing Service

You can get to the screencast from here http://rocksolidknowledge.com/ScreenCasts.mvc

I my last post I showed that creating a custom composite activity (one that can have one or more children) requires deriving from NativeActivity. The Retry activity that I showed was fairly simple and in particular didn’t try to share data with its child. There appears to be a catch-22 in this situation when it comes to overriding CacheMetadata: if I add a Variable to the metadata (AddVariable) then it can be used exclusively by its children – i.e. the activity itself can’t manipulate the state; if I add a variable as implementation data to the metadata (AddImplementationVariable) then the children cant see it as its seen as purely used for this activities implementation. How then do we create data that can be both manipulated by the activity and accessed by the parent?

The secret to achieving this is a feature called ActivityAction - Matt Winkler talks about it here. The idea is that I can bind an activity to one or more parent defined pieces of data then schedule the activity where it will have access to the data. Its probably best to show this with an example so I have written a ForEachFile activity that you give a directory and then it passes its child the file name of each file in the directory in turn. I’ll show the code in its entirety and then walk through each piece in turn

               1: [ContentProperty("Body")]

               2: [Designer(typeof(ForEachFileDesigner))]

               3:
              public
              class ForEachFile
: NativeActivity, IActivityTemplateFactory

               4: {

               5:
              public InArgument<string>
Directory { get; set; }

               6:  

               7: [Browsable(false)]

               8:
              public ActivityAction<string>
Body { get; set; }

               9:  

               10:
              private Variable<IEnumerator<FileInfo>>
files = new Variable<IEnumerator<FileInfo>>("files");

               11:  

               12:
              protected
              override
              void CacheMetadata(NativeActivityMetadata
metadata)

               13: {

               14: metadata.AddDelegate(Body);

               15:  

               16: RuntimeArgument
arg = new RuntimeArgument("Directory", typeof(string),
ArgumentDirection.In);

               17: metadata.AddArgument(arg);

               18:  

               19: metadata.AddImplementationVariable(files);

               20: }

               21:
              protected
              override
              void Execute(NativeActivityContext
context)

               22: {

               23: DirectoryInfo
dir = new DirectoryInfo(Directory.Get(context));

               24:  

               25: IEnumerable<FileInfo>
fileEnum = dir.GetFiles();

               26: IEnumerator<FileInfo>
fileList = fileEnum.GetEnumerator();

               27: files.Set(context,
fileList);

               28:  

               29:
              bool more
= fileList.MoveNext();

               30:  

               31:
              if (more)

               32: {

               33: context.ScheduleAction<string>(Body,
fileList.Current.FullName, OnBodyComplete);

               34: }

               35: }

               36:  

               37:
              private
              void OnBodyComplete(
NativeActivityContext context, ActivityInstance completedInstance)

               38: {

               39: IEnumerator<FileInfo>
fileList = files.Get(context);

               40:
              bool more
= fileList.MoveNext();

               41:  

               42:
              if (more)

               43: {

               44: context.ScheduleAction<string>(Body,
fileList.Current.FullName, OnBodyComplete);

               45: }

               46:
            

               47: }

               48:  

               49:
              #region IActivityTemplateFactory
Members

               50:
              public Activity
Create(DependencyObject target)

               51: {

               52: var
fef = new ForEachFile();

               53: var
aa = new ActivityAction<string>();

               54: var
da = new DelegateInArgument<string>();

               55: da.Name
= "item";

               56:  

               57: fef.Body
= aa;

               58: aa.Argument
= da;

               59:  

               60:
              return fef;

               61: }

               62:
              #endregion
            

               63: }

Ok lets start with the core functionality then we’ll look at each of the pieces that help make this fully usable. As you can see the class derives from NativeActivity and overrides CacheMetadata and Execute – we’ll look at their implementations in a minute. There are three member variables in the class: the InArgument<string> for the directory; an implementation variable to hold the iterator as we move through the files in the directory; the all important ActivityAction<string> which we will use to pass the current file name to the child activity.

Lets look at CacheMetadata more closely. Because we want to do interesting things with some of the state the default implementation won’t work so we override it. As we don’t call the base class version we need to specify how we use all of the state. We add the ActivityAction as a delegate, we bind the Directory argument to a RuntimeArgument and specify the iterator as an implementation variable – we don’t want the child activity to have access to that directly.

Next lets look at Execute. The first couple of lines are nothing unusual – we get the directory and get hold of the list of files. Now we have to store the retrieved iterator in the implementation variable, fileList. We move to the first file in the iteration, if it returns false the list was empty so as long as MoveNext returned true we want to schedule the child activity passing the current file. To do this we use the ScheduleAction<T> member on the context. However, because we’re going to process each one sequentially, we also need to know when the child is finished so we pass a completion callback, OnBodyComplete.

Now in OnBodyComplete we simply get the iterator, move to the next item in the iteration and as long as we’re not finished iterating re-schedule the child again passing the new item in the iteration.

That really is the “functional” part of the activity – everything else is there to support the designer. So why does the designer need help? Well lets look at what we would have to do to build this activity correctly if we were going to execute it from main

               1: Activity
workflow = new ForEachFile

               2: {

               3: Body
= new ActivityAction<string>

               4: {

               5: Argument
= new DelegateInArgument<string>

               6: {

               7: Name
= "item",

               8: },

               9: Handler
= new WriteLine

               10: {

               11: Text
= new VisualBasicValue<string>("item")

               12: }

               13: },

               14: Directory
= @"c:\windows"

               15: };

As you can see, its not a matter of simply creating the ForEachFile, we have to build the internal structure too – something needs to create that structure for the designer - this is the point of IActivityTemplateFactory. When you drag an activity on to the design surface normally it just creates the XAML for that activity. However, before it does that it does a speculative cast for IActivityTemplateFactory and if the activity supports that it calls the interface’s Create method instead and serializes the resulting activity to XAML.

So going back to the ForEachFile activity, you can see it implements IActivityTemplateFactory and therefore, as far as the designer is concerned, this is the interesting functionality – lets take a look at the Create method.We create the ForEachFile and wire an ActivityAction<string> to its Body property. ActivityAction<string> needs a slot to store the data to be presented to the child activity. This is modelled by DelegateArgument<string> and this gets wired to the Argument member of the ActvityAction. We also name the argument as we want a default name for the state so the child activity can use it. Notice, however, we don’t specify the child activity itself (it would be a pretty useless composite if we hard coded this). The child will be placed on the Handler property of the ActivityAction but that will be done in the ActivityDesigner using data binding.

Before we look at the designer lets highlight a couple of “polishing” features of the code: the class declared a ContentProperty via an attribute – that just makes the XAML parsing cleaner as the child doesn’t need to be specified using property element syntax; the Body is set to non-browsable – we don’t want the activities user to try to set this value in the property grid.

OK on to the designer. If you read my previous article there are a couple of new things here. Lets look at the markup – again there is no special code in the code behind file, everything is achieved using data binding

               1:
              <
              sap:ActivityDesigner
              x:Class
              ="ActivityLib.ForEachFileDesigner"
            

               2:
              xmlns
              ="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
            

               3:
              xmlns:x
              ="http://schemas.microsoft.com/winfx/2006/xaml"
            

               4:
              xmlns:s
              ="clr-namespace:System;assembly=mscorlib"
            

               5:
              xmlns:conv
              ="clr-namespace:System.Activities.Presentation.Converters;assembly=System.Activities.Presentation"
            

               6:
              xmlns:sap
              ="clr-namespace:System.Activities.Presentation;assembly=System.Activities.Presentation"
            

               7:
              xmlns:sapv
              ="clr-namespace:System.Activities.Presentation.View;assembly=System.Activities.Presentation"
            

               8:
              xmlns:me
              ="clr-namespace:ActivityLib"
              >
            

               9:
              <
              sap:ActivityDesigner.Resources
              >
            

               10:
              <
              conv:ArgumentToExpressionConverter
              x:Key
              ="expressionConverter"
              />
            

               11:
              </
              sap:ActivityDesigner.Resources
              >
            

               12:  

               13:
              <
              Grid
              >
            

               14:
              <
              Grid.RowDefinitions
              >
            

               15:
              <
              RowDefinition
              Height
              ="Auto"
              />
            

               16:
              <
              RowDefinition
              Height
              ="*"
              />
            

               17:
              </
              Grid.RowDefinitions
              >
            

               18:
            

               19:
              <
              StackPanel
              Orientation
              ="Horizontal"
              Margin
              ="2"
              >
            

               20:
              <
              TextBlock
              Text
              ="For
each file "
              />
            

               21:
              <
              TextBox
              Text
              ="{Binding
ModelItem.Body.Argument.Name}"
              MinWidth
              ="50"
              />
            

               22:
              <
              TextBlock
              Text
              ="
in "
              />
            

               23:
              <
              sapv:ExpressionTextBox
              Expression
              ="{Binding
Path=ModelItem.Directory, Converter={StaticResource expressionConverter}}"
            

               24:
              ExpressionType
              ="s:String"
            

               25:
              OwnerActivity
              ="{Binding
ModelItem}"
              />
            

               26:
              </
              StackPanel
              >
            

               27:
              <
              sap:WorkflowItemPresenter
              Item
              ="{Binding
ModelItem.Body.Handler}"
            

               28:
              HintText
              ="Drop
activity"
            

               29:
              Grid.Row="1"Margin="6"/>

               30:  

               31:
              </
              Grid
              >
            

               32:
            

               33:
              </
              sap:ActivityDesigner
              >
            

Here’s what this looks like in the designer

So the TextBox at line 21 displays the argument name that our IActivityTemplateFactory implementation set up. The ExpressionTextBox is bound to the directory name but allows VB.NET expressions to be used. The WorkflowItemPresenter is bound to the Handler property of the Body ActivityAction, This designer is then associated with the activity using the [Designer] attribute.

So as you can see, ActivityAction and IActivityTemplateFactory work together to allow us to build rich composite activities with design time support

I’m writing Essential Windows Workflow Foundation 4.0 with Maurice for DevelopMentor. One of the things that I think is less than obvious is the behavior of NativeActivity.

What is NativeActivity I hear you ask? Well there are a number of models for building custom activities in WF4. Most “business” type custom activities will be built using a declarative model in XAML by assembling building blocks graphically. However, what if you are missing a building block? At this point you have to fall back to writing code and there are three options for your base class when writing an activity in code:

CodeActivity
You use CodeActivity when you have a simple synchronous activity. All work happens in Execute and it has no child activities

AsyncCodeActivity
This is new to WF4. Here you have the ability to implement the async pattern (BeginExecute / EndExecute) to perform short lived async operations where you do not want the workflow persisted (e.g. an async WebRequest)

NativeActivity
This gives you full access to the power of the workflow execution engine. However, in the words of Spiderman’s Uncle, “with great power comes great responsibility”. NativeActivity can be a bit tricky so that is what this article is about

I’m going to walk through the code for a Retry activity – where a child activity can be rerun a number of times upon failure. The activity has two InArguments: MaxRetries and RetryDelay. MaxRetries says how many times you will retry the child before giving up. RetryDelay says how long to wait between retries. We could use a Thread.Sleep to do the delay but this would not be good for the workflow engine: we block a thread it could use and there is no way for the engine to persist the workflow – what if we wanted to retry in 2 days? So instead, as part of our implementation, we’ll use a Delay activity.

Now to explain the code we have to take a slight diversion and talk about the relationship between Activity, ActivityInstance and ExecutionContext. I talked about is a while back here when the PDC CTP first came out (that’s what the reference to some base class called WorkflowElement is about) but to expand a little: The Activity is really just a template containing the code to execute for the activity. The ActivityInstance is the actual thing that is executing. It holds the state for this instance of the activity template. Now we need a way to bind the template code to the currently running instance of the activity and this is the role of the ExecutionContext. If you are using a CodeActivity base class then most of this is hidden from you except that you have to access arguments by passing in the ExecutionContext. However, with NativeActivity you have to get more directly involved with this model.

Now how does the workflow engine know what data you need to store in the ActivityInstance? Well it turns out you need to tell it. NativeActivity has a virtual method called CacheMetadata (this post talks about it to some degree). The point being that the activity has to register all of the “stuff” that it wants to use during its execution. Now the base class implementation will do some fairly reasonable default actions but it cannot know, for example, that part of your functionality is there purely for implementation details and should not be public. Therefore, you will often override this when you create a NativeActivity

So without more ado – here’s the code for the Retry activity. I’ll then walk through it

               1: [Designer(typeof(ForEachFileDesigner))]

               2:
              public
              class Retry
: NativeActivity

               3: {

               4:
              public InArgument<int>
MaxRetries { get; set; }

               5:
              public InArgument<TimeSpan>
RetryDelay { get; set; }

               6:
              private Delay
Delay = new Delay();

               7:  

               8:
              public Activity
Body { get; set; }

               9:  

               10: Variable<int>
CurrentRetry = new Variable<int>("CurrentRetry");

               11:  

               12:
              protected
              override
              void CacheMetadata(NativeActivityMetadata
metadata)

               13: {

               14: metadata.AddChild(Body);

               15: metadata.AddImplementationVariable(CurrentRetry);

               16:  

               17: RuntimeArgument
arg = new RuntimeArgument("MaxRetries", typeof(int),
ArgumentDirection.In);

               18: metadata.Bind(MaxRetries,
arg);

               19: metadata.AddArgument(arg);

               20:  

               21: Delay.Duration
= RetryDelay;

               22:
            

               23: metadata.AddImplementationChild(Delay);

               24: }

               25:  

               26:
              protected
              override
              void Execute(NativeActivityContext
context)

               27: {

               28: CurrentRetry.Set(context,
0);

               29:  

               30: context.ScheduleActivity(Body,
OnFaulted);

               31: }

               32:  

               33:
              private
              void OnFaulted(NativeActivityFaultContext
faultContext, Exception propagatedException, ActivityInstance propagatedFrom)

               34: {

               35:
              int current
= CurrentRetry.Get(faultContext);

               36:
              int max
= MaxRetries.Get(faultContext);

               37:  

               38:
              if (current
< max)

               39: {

               40: faultContext.CancelChild(propagatedFrom);

               41: faultContext.HandleFault();

               42: faultContext.ScheduleActivity(Delay,
OnDelayComplete);

               43: CurrentRetry.Set(faultContext,
current + 1);

               44: }

               45: }

               46:  

               47:
              private
              void OnDelayComplete(NativeActivityContext
context, ActivityInstance completedInstance)

               48: {

               49: context.ScheduleActivity(Body,
OnFaulted);

               50: }

               51: }

So lets look at the code: first the class derives from NativeActivity (we’ll come to the designer later). This means I want to do fancy things like have child activities or perform long running asynchronous work. Next we see the two InArguments that are passed to the Retry. The Delay is an implementation detail of how we will pause between retry attempts and the Body property is where the activity we are going to retry lives. Finally we have a Variable, CurrentRetry, where we store how many retry attempts we have made. That is the data in the class but remember we need to tell the workflow engine about what we need to store and why – this is the point of CacheMetadata (I read this method name as “here is the metadata for the cache” rather than “I am going to cache some metadata”)

In CacheMetadata the first thing we do is specify that the Body is our child activity. Next we tell the engine that we want to be able to get hold of the CurrentRetry but that its only there for our implementation – we’re not expecting the child activity to try to make use of it. The next 3 lines (17-19) seem a little strange but essentially we’re saying that the MaxRetries argument needs to be accessed over the whole lifetime of the ActivityInstance so we need a slot for that. We next configure out Delay activity passing the RetryDelay as its duration (this is how long we want to wait between retries). Finally we add the Delay, not as a normal child, but as an implementation detail.

OK, Execute is pretty simple – we initialize the CurrentRetry and then schedule the Body. But, because we want to retry on failure, we also pass in a fault handler (OnFaulted)

OnFaulted does the main work. It fires if the child fails. So it checks to see if we have exceeded the retry count and if not retries the Body activity. However, it doesn’t do this directly, first it tells the context that it has handled the error – it also, strangely has to cancel the current child (which is odd as its already faulted) – Maurice talks about this oddity here. Next it schedules the Delay as we have to wait for the retry delay and wires up a completion handler (OnDelayComplete) so we know when the delay is finished. Finally it updates the CurrentRetry.

OnDelayComplete simply reschedules the Body activity, remembering to pass the fault handler again in case the activity fails again.

Oh one thing I said I’d come back to – the designer. I have written a designer to go with this (designers in WF4 are WPF based). The XAML for this is here:

               1:
              <
              sap:ActivityDesigner
              x:Class
              ="WordActivities.ForEachFileDesigner"
            

               2:
              xmlns
              ="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
            

               3:
              xmlns:s
              ="clr-namespace:System;assembly=mscorlib"
            

               4:
              xmlns:x
              ="http://schemas.microsoft.com/winfx/2006/xaml"
            

               5:
              xmlns:sap
              ="clr-namespace:System.Activities.Presentation;assembly=System.Activities.Presentation"
            

               6:
              xmlns:sapv
              ="clr-namespace:System.Activities.Presentation.View;assembly=System.Activities.Presentation"
            

               7:
              xmlns:conv
              ="clr-namespace:System.Activities.Presentation.Converters;assembly=System.Activities.Presentation"
            

               8:
              mc:Ignorable
              ="d"
            

               9:
              xmlns:d
              ="http://schemas.microsoft.com/expression/blend/2008"
            

               10:
              xmlns:mc
              ="http://schemas.openxmlformats.org/markup-compatibility/2006"
              >
            

               11:
              <
              sap:ActivityDesigner.Resources
              >
            

               12:
              <
              conv:ArgumentToExpressionConverter
              x:Key
              ="expressionConverter"
              />
            

               13:
              </
              sap:ActivityDesigner.Resources
              >
            

               14:
              <
              Grid
              >
            

               15:
              <
              Grid.RowDefinitions
              >
            

               16:
              <
              RowDefinition
              Height
              ="Auto"
              />
            

               17:
              <
              RowDefinition
              Height
              ="Auto"
              />
            

               18:
              <
              RowDefinition
              Height
              ="*"
              />
            

               19:
              </
              Grid.RowDefinitions
              >
            

               20:
              <
              Grid.ColumnDefinitions
              >
            

               21:
              <
              ColumnDefinition
              Width
              ="Auto"
              />
            

               22:
              <
              ColumnDefinition
              Width
              ="*"
              />
            

               23:
              </
              Grid.ColumnDefinitions
              >
            

               24:  

               25:
              <
              TextBlock
              Grid.Row="0"Grid.Column="0"Margin="2">Max.
Retries:</TextBlock>

               26:
              <
              sapv:ExpressionTextBox
              Expression
              ="{Binding
Path=ModelItem.MaxRetries, Converter={StaticResource expressionConverter}}"
            

               27:
              ExpressionType
              ="s:Int32"
            

               28:
              OwnerActivity
              ="{Binding
ModelItem}"
            

               29:
              Grid.Row="0"Grid.Column="1"Margin="2"/>

               30:  

               31:
              <
              TextBlock
              Grid.Row="1"Grid.Column="0"Margin="2">Retry
Delay:</TextBlock>

               32:
              <
              sapv:ExpressionTextBox
              Expression
              ="{Binding
Path=ModelItem.RetryDelay, Converter={StaticResource expressionConverter}}"
            

               33:
              ExpressionType
              ="s:TimeSpan"
            

               34:
              OwnerActivity
              ="{Binding
ModelItem}"
            

               35:
              Grid.Row="1"Grid.Column="1"Margin="2"/>

               36:
            

               37:
              <
              sap:WorkflowItemPresenter
              Item
              ="{Binding
ModelItem.Body}"
            

               38:
              HintText
              ="Drop
Activity"
            

               39:
              Margin
              ="6"
            

               40:
              Grid.Row="2"

               41:
              Grid.Column="0"

               42:
              Grid.ColumnSpan="2"/>

               43:  

               44:
              </
              Grid
              >
            

               45:
              </
              sap:ActivityDesigner
              >
            

There is no special code behind, everything is done via databinding.

So as you can see, there are a lot of pieces that need to be put into place for something that seems fairly simple. The critical issue is getting the implementation of CacheMetadata correct – once you have identified all of the pieces of data you need stored the rest falls out nicely.

I’ve just realised that DevWeek 2010 is on the horizon. DevWeek is one of my favourite conferences  - lots of varied talks, vendor independence and I get to hang out with lots of friends for the week.

This year I’m doing a preconference talk and two sessions:

A Day of .NET 4.0
Mon 15th March 2010
WORKSHOP REF: M1
.NET 4.0 is a major release of .NET, including the first big changes to the .NET runtime since 2.0. In this series of talks we will look at the big changes in this release in C#, multithreading, data access and workflow.
The best-known change in C# is the introduction of dynamic typing. However, there have been other changes that may affect your lives as developers more, such as support for generic variance, named and optional parameters. There is a whole library for multithreading, PFx, that not only assists you in parallelizing algorithms but in fact replaces the existing libraries for multithreading with a unified, powerful single API.
Entity Framework has grown up – the initial release, although gaining some popularity, missed features that made it truly usable in large-scale systems. The new release, version 4.0, introduces a number of features, such as self-tracking objects, that assist using Entity Framework in n-tier applications.
Finally, workflow gets a total rewrite to allow the engine to be used far more widely, having overcome limitations in the WF 3.5 API.
This workshop will take you through all of these major changes, and we’ll also talk about some of the other smaller but important ones along the way.

An Introduction to Windows Workflow Foundation 4.0
Tues 16th March 2010
.NET 4.0 introduces a new version of Windows Workflow Foundation. This new version is a total rewrite of the version introduced with .NET 3.0. In this talk we look at what Microsoft are trying to achieve with WF 4.0, why they felt it necessary to rewrite rather than modify the codebase, and what new features are available in the new library. Along the way we will be looking at the new designer, declarative workflows, asynchronous processing, sequential and flowchart workflows and how workflow’s automated persistence works.

Creating Workflow-based WCF Services
Tues 16th March 2010
There are very good reasons for using a workflow to implement a WCF service: workflows can provide a clear platform for service composition (using a number of building block services to generate a functionally richer service); workflow can manage long running stateful services without having to write your own plumbing to achieve this. The latest version of Workflow, 4.0, introduces a declarative model for authoring workflows and new activities for message based interaction. In addition we have a framework for flexible message correlation that allows the contents of a message to determine which workflow the message is destined for. In this session we will look at how you can consume services from workflow and expose the resulting workflow itself as a service.

As well as these you may well see me popping up as a guest code-monkey in the other Rock Solid Knowledge sessions. Hope to see you there