Constraining Dropped Activities

In my last post I described making modifications to the standard FlowDecision activity to make it more usable, and mentioned there were a couple of modifications I needed to make to the code to make it more usable.

One is constraining the types of activity that can be dropped into the FlowDecision. Where I left off on that last post was something that looked as follows…

The problem here is at present I can drop anything into the FlowDecision – instead I need to constrain this to only activities that return a boolean result, i.e. something derived from Activity<Boolean>. I’m using the WorkflowItemPresenter in my designer and there’s a property on there named AllowedItemType which does just the job – however what I need to do is be able to pass a generic type into this type. A quick search around the web had something close, so here’s what I now have in the XAML…

    <sap:ActivityDesigner.Resources>
        <local:GenericType x:Key="mustReturnBool" BaseType="{x:Type sa:Activity`1}"
                           TypeParam="{x:Type sys:Boolean}" />
    </sap:ActivityDesigner.Resources>

    <sap:WorkflowItemPresenter Item="{Binding ModelItem.Condition}" 
        HintText="Drop a condition here" AllowedItemType="{StaticResource mustReturnBool}"/>

So here I have a markup extension (local:GenericType) and have referenced this in the workflow item presenter. The markup extension defines the class we’re deriving from which is a generic type taking one argument so is defined as Activity`1 (if this took 3 arguments you would define this as Activity`3). I’ve then defined the type parameter as an instance of Boolean, and so at runtime this will create a type which is Activity<Boolean>.

Note: If you happen to cut & paste the line from the XAML that includes sa:Activity`1 this will (most annoyingly) be pasted back in as sa:Activity’1 – i.e. the grave character has been replaced with a single quote. So, beware!

The markup extension is shown below…

/// <summary>
/// A markup extension allowing generic types to be used in XAML
/// </summary>
public class GenericType : MarkupExtension
{
    /// <summary>
    /// Defines the base type to derive from
    /// </summary>
    public Type BaseType { get; set; }

    /// <summary>
    /// Defines the collection of type parameters
    /// </summary>
    public Type[] TypeParams { get; set; }

    /// <summary>
    /// Defines the singular type parameter
    /// </summary>
    public Type TypeParam { get; set; }

    /// <summary>
    /// Default constructor
    /// </summary>
    public GenericType() { }

    /// <summary>
    /// Return the generic type constructed from the base Type and Type parameters
    /// </summary>
    /// <param name="serviceProvider"></param>
    /// <returns></returns>
    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        Type retVal = null;

        if (null != TypeParam)
            retVal = BaseType.MakeGenericType(TypeParam);
        else
            retVal = BaseType.MakeGenericType(TypeParams);
        return retVal;
    }
}

With this in place I can try dragging any old activity onto the FlowDecision and now it won’t permit me to drop anything other than activities that derive from the correct type.

The Code

I’ve updated the code from the last article to include this new capability. Click here to download a .zip.

Morphing Conditional Activities

I’m currently working on a workflow implementation which, like many, is going to be used by users who are not necessarily programmers. So the thought of giving them conditions to write in code is the kind of thing that keeps me up at night.

I’m using Flowchart as the root node as it provides the sort of UI that we need, however there are a few issues.

First off is the display of the FlowDecision node. The standard look and feel is as follows…

That’s all well and good, but I’m trying to keep this usable from non-programmers and so setting the Condition property (a) from the property grid and (b) in code is a step too far.

Re-Designing FlowDecision

So, the first step is to re-design this designer. It’s a simple job as with WF4 it’s a load easier to register a new designer. Here’s what I ended up with, the XAML and code is shown later…

That’s looking more user friendly already. The first step was to create a new designer, the XAML of which is shown below (I’ve taken some formatting liberties with the XAML to fit on the page)…

  <sap:ActivityDesigner x:Class="CustomActivities.CustomFlowDecisionDesigner"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:sap="clr-namespace:System.Activities.Presentation;
               assembly=System.Activities.Presentation"
    xmlns:sapv="clr-namespace:System.Activities.Presentation.View;
                assembly=System.Activities.Presentation">

    <sap:WorkflowItemPresenter Item="{Binding ModelItem.Condition}" 
      HintText="Drop a condition here"/>
    
  </sap:ActivityDesigner>

All I’ve done here is derive from ActivityDesigner and then create a WorkflowItemPresenter (there’s a bit more work to do on this but I’ll save that for another blog post).

So, now I want to have a ‘condition’ activity (that’s a naming convention I’ve come up with myself). A condition activity returns a boolean, so will fit nicely into the slot provided by FlowDecision. My first one is the “IsAPastyMuncher” activity (I’m from Cornwall in the UK, pasties are part of my heritage – for some great ones you can do a lot worse than order over the phone from Malcolm Barnecutts).

Anyhow, this activity returns True or False, and the default designer looks like this…

Now that’s OK when it’s on its own, but as this activity is designed to be dropped within the FlowDecision it doesn’t look as good in that instance…

Removing the ‘Chrome’

There’s a bit too much ‘chrome’ going on there for my liking – the reason being that a standard designer derives from ActivityDesigner which adds the adornments such as the border, name and so on. What I’d really like is ‘chrome-less’ experience in the designer, and to do that all you need to do is change the base class of your designer from ActivityDesigner to WorkflowViewElement. This is as simple as editing the XAML directly and altering the root element to the following…

<sap:WorkflowViewElement x:Class="CustomActivities.IsAPastyMuncherDesigner"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:sap="clr-namespace:System.Activities.Presentation;
               assembly=System.Activities.Presentation"
    xmlns:sapv="clr-namespace:System.Activities.Presentation.View;
                assembly=System.Activities.Presentation">

    <CheckBox Content="Munches Pasties" IsChecked="{Binding ModelItem.MunchesPasties}"/>

</sap:WorkflowViewElement>

Then you’ll have a much better experience within the designer…

That’s looking a load better – maybe still some room for improvement mind you (again another post I must get around to) but it’s getting there. But now to the main event…

Morphing Activities

There is however one major problem with the IsAPastyMuncher activity as now, when added to the toolbox & dropped outside of a decision I see just the following…

Now that’s a bit too minimal even for me! What I would ideally like to do is check if this activity has been dropped inside a FlowDecision, and if not automatically surround it with one. Your first thought might be to dive in with an activity that implements IActivityTemplateFactory, create a FlowDecision and within it create the IsAPastyMuncher activity. There’s one problem with that – FlowDecision doesn’t derive from Activity and cannot therefore be returned from the custom factory.

Never fear however, where there’s a will there’s a way, and instead I’ve overridden a method within the IsAPastyMuncher activity that is called when the activity is created (i.e. by the drag & drop operation) and in here I can do the switch. The code is shown below…

  protected override void OnModelItemChanged(object newItem)
  {
    ConditionHelper.MorphIntoDecision(newItem);
  }

I’ve created the ConditionHelper class which actually performs the swap…

internal class ConditionHelper
{
    /// <summary>
    /// Method that morphs a dropped activity inside a flow step into the same 
    /// activity but within a flow decision
    /// </summary>
    /// <param name="newItem"></param>
    public static void MorphIntoDecision(object newItem)
    {
        if (newItem is ModelItem)
        {
            ModelItem item = newItem as ModelItem;
            ModelItem parent = item.Parent;

            if (parent.ItemType == typeof(FlowStep))
            {
                // Morph the parent to a flow decision
                EditingContext context = item.GetEditingContext();
                ModelItem newModelItem = ModelFactory.CreateItem(context, new FlowDecision());

                using (ModelEditingScope scope = newModelItem.BeginEdit("Convert to Decision"))
                {
                    MorphHelper.MorphObject(parent, newModelItem);
                    MorphHelper.MorphProperties(parent, newModelItem);

                    // Now I need to set newModelItem.Condition = parent.Action, 
                    // so the MorphProperties helper is pretty useless in this instance!
                    ModelProperty conditionProp = newModelItem.Properties["Condition"];
                    ModelProperty actionProp = parent.Properties["Action"];
                    conditionProp.SetValue(actionProp.Value);
                    actionProp.SetValue(null);

                    scope.Complete();
                }
            }
        }
    }
}

When an activity other than FlowDecision is added to the flow chart activity it is surrounded with a FlowStep activity. I check if this is the case and if so construct a FlowDecision activity as the parent instead and morph the existing parent into the new activity (well, MorphHelper.MorphObject does this for me). Any properties on the original parent activity which match with property names on the new parent activity are copied across using the MorphHelper.MorphProperties call, but then I need to move the actual activity (i.e. the IsAPastyMuncher) from the FlowStep to the FlowDecision. On FlowStep the property holding the activity is Action, whereas on FlowDecision this is Condition, so I use the ModelProperty class to make this change.

Now I can drop on an IsAPastyMuncher activity and have it automatically surrounded with a FlowDecision, but also allow the user to drop one inside a FlowDecision that’s already on the design surface which is the best of both worlds.

The Code

If you would like to download a sample please click here. This is built on Visual Studio 2010.

In the example there are 2 custom activities on the toolbox – the IsAPastyMuncher which morphs inside a FlowDecision when dropped, and the LovesClottedCream activity which does not.

Hosting Dynamic Workflows

I’ve been working with WF for many years now (OK, just over 6 to be precise) and having recently left Microsoft I’m now actually using WF4 in anger.

One of the things I want to do (and judging by the number of posts I’ve found on this I’m not the only one) is the following…

• Host the Workflow Designer to allow users to create custom workflows
• Have these custom workflows exposed as services (i.e. .xamlx), hosted using the standard mechanisms inside an ASP.NET site
• Monitor the workflows using Windows Server AppFabric
• Do all of the above with the minimum of manual steps (ideally none)

There are a number of hurdles you’ll face when trying to do this, but the point of this post is to show how I have accomplished this with a minimal amount of custom code.

When I approach a problem I’ll often describe an ideal outcome – this helps me to concentrate on the important “must-haves” and also help me know when I’m finished. So, that ideal outcome for this would be…

The user creates a workflow in a custom designer. This workflow is saved in the database and can then be called by a client, using a well-known interface. The address of the workflow will be based on the workflow itself – i.e. the address will also be dynamic.

OK, sounds easy. First off we need to create an editor, I’ve done that in my example application but haven’t described it here as it’s already well documented on the web and in the WCF & Workflow samples. The workflow coming out of the back of the designer is just a piece of text, so if you can’t store that in the database then you’re reading the wrong blog.

So, we have a workflow sat in a database table and need to be able to call it. For sake of argument my database table is as follows…

This simply contains a GUID as the key, a textual workflow definition and a textual name. In my example I’ve created a simple EF model that uses this, and exposed that as a very crude but effective WCF service. So, I can get stuff into and out of the table.

There are actually two parts to hosting dynamic workflows, one being having ‘something’ listening on the server, the other is doing the correct thing when a message comes in.

Listening out for a XAMLX

In order to take advantage of the maximum amount of plumbing (i.e. reuse as much code as possible, as an old colleague of mine used to say “less code more smiles”) I wish to host my workflow as a .XAMLX file.

This normally requires that you stuff this file on disk – however, ASP.NET has had the concept of Virtual Path Providers (and by extension, Virtual File Providers) for some time (since ASP.NET 2 if I recall correctly). What a VPP allows me to do is intercept the incoming file request and inject my own code – I can then expose a .XAMLX file without it actually being on disk.

In my example code I’ve created a VirtualPathProvider that is instantiated in global.asax as shown in the code below.

protected void Application_Start(object sender, EventArgs e)
{
    // Create and register the virtual path provider
    HostingEnvironment.RegisterVirtualPathProvider
        (new WorkflowProvider());
}

This then looks for any request that contains the sequence {guid}.xamlx and if found strips off the GUID and looks this up in the Workflow table – the pertinent code is as follows…

private string GetWorkflow(string virtualPath)
{
    string definition = string.Empty;

    if (virtualPath.EndsWith(".xamlx", true, null))
    {
        string fileName = 
            Path.GetFileNameWithoutExtension(virtualPath);
        Guid id = Guid.Empty;

        if (Guid.TryParse(fileName, out id))
        {
            using (WorkflowDatabaseEntities context = 
                new WorkflowDatabaseEntities())
            {
                var row = context.Workflows.SingleOrDefault
                    (wf => wf.WorkflowId == id);

                if (null != row)
                    definition = row.WorkflowDefinition;
            }
        }
    }

    return definition;
}

OK, so that gets us part of the way but we’re not out of the woods just yet. What we need now is some way to communicate with the workflow. If you were hosting a regular .XAMLX your would define the service contract by dropping activities into the workflow.

That’s all fair and good, however what if you want to be able to communicate with the workflow using a standard, non-changing interface? I should ideally be able to communicate with the Workflow using an interface such as that shown below…

/// <summary>
/// Communicate with a dynamic workflow
/// </summary>
[ServiceContract]
public interface IDynamicWorkflow
{
    /// <summary>
    /// Creates a new workflow instance
    /// </summary>
    /// <param name="args">Parameters to pass to the workflow</param>
    /// <returns>The unique ID of the created workflow</returns>
    [OperationContract]
    Guid CreateWorkflow(IDictionary<string, object> args);

    /// <summary>
    /// Resume a bookmark
    /// </summary>
    /// <param name="workflowInstanceId"></param>
    /// <param name="bookmarkName"></param>
    /// <param name="state"></param>
    [OperationContract(Name = "ResumeBookmark", IsOneWay = true)]
    void ResumeBookmark(Guid workflowInstanceId, string bookmarkName, object state);
}

So, this interface allows me to communicate with the workflow – I can create a workflow instance and also resume bookmarks on that instance, much how I’d communicate with something in-process. But how does this interface get associated with the .xamlx workflow definition?

Voodoo Magic

Yes, it’s time to get out the grass skirts, dance around some poor sap tied to a tree and cast some spells. OK, not exactly, but welcome to the world of the WorkflowHostingEndpoint. This class has been created to support just this style of dynamic invocation – all you need to do is derive from it, override a few simple methods and you’re away. Well, nearly.

The most common usage of this endpoint is when you are hosting workflows yourself – i.e. by creating a WorkflowServiceHost instance and specifically adding on the endpoint. This is all documented to a certain extent on MSDN here. But that seems to state that you need to do all this heavy lifting yourself, which is all fair and good but my goal was to minimise the amount of code written – and doesn’t .xamlx activation already do most of this?

The answer is yes, the pipeline that gets invoked when you call a .xamlx will instantiate the WorkflowServiceHost and get all of the plumbing ready, but we need a way to inject our custom endpoint into the mix – and this is where the voodoo magic lies.

To cut a long story short, I’ve spent several hours with Reflector, decompiling the path that a request takes from initially getting to the server in the form of an HTTP request all the way down through the multitude of classes until it reaches some code that actually runs a workflow.

In my quest I was also lucky enough to stumble upon this post which showed me how I could add on a new endpoint within the .config file which was just the job. The configuration elements of interest are shown below…

  <system.serviceModel>

    <extensions>
      <endpointExtensions>
        <add name="dynamicWorkflow" 
            type="HostingDynamicWorkflows.DynamicHosting.CustomWorkflowEndpointCollection, 
                  HostingDynamicWorkflows" />
      </endpointExtensions>
    </extensions>

    <services>
      <service name="DynamicActivity">
        <endpoint kind="dynamicWorkflow" binding="basicHttpBinding" address="" />
      </service>
    </services>

The first element (an endpoint extension) defines the custom endpoint (well, actually a custom endpoint collection) called ‘dynamicWorkflow’. This is then associated with a dynamic workflow with the second element, the <service> declaration.

At runtime, the underlying workflow hosting code will pickup the <service> element, find the ‘kind’ attribute, and diligently wander off to the class defined in the endpoint extension and instantiate it. This class is the one that derives from WorkflowHostingEndpoint, and also the one that (somewhat indirectly) implements the IDynamicWorkflow interface.

Before I continue however there’s one critical element to all of this which needs to be explained.

When the workflow hosting code starts up your workflow it does the following (in pseudocode)…

string configName = RootActivity.Name;

If (RootActivity Is WorkflowService) && (IsNotNull(RootActivity.ConfigName))
  configName = RootActivity.ConfigName;

// Read configuration information for the workflow from the service element
// with name ‘configName’

With a regular .xamlx workflow you may have noticed there is a property on the root workflow element called ‘ConfigurationName’.

<WorkflowService mc:Ignorable="sap" ConfigurationName="WaitForAWhile" .../>

This maps to the service element…

    <services>
      <service name="WaitForAWhile">
        <endpoint kind="dynamicWorkflow" binding="basicHttpBinding" address="" />
      </service>
    </services>

This tells the workflow hosting code that the configuration for the workflow service is in a named element in the .config file. That’s all fairly easy to understand.

In my config file however this service name is ‘DynamicActivity’ – and this maps to the Name property of the root node of the workflow being executed. You might ask – why is the name “DynamicActivity”. Well, there’s another thing that I’ll describe in the following section.

Passing in dynamic parameters

When starting a workflow I’d obviously like to be able to pass in an arbitrary list of input arguments. In order to do this you need to use the ActivityBuilder class when designing your workflow (this allows you to create arguments, either in code before you display the designer to the user, and/or in the designer itself).

In my client application I have the following code when I’m creating the designer for editing a workflow…

_designer = new WorkflowDesigner();

ActivityBuilder builder = new ActivityBuilder();
_designer.Load(builder);

This then creates a workflow that is persisted as follows (this is one that also contains a message activity)…

<Activity x:Class="{x:Null}"> 
    <c:UIMessage Message="Hello from Workflow!" />
</Activity>

I have removed all namespaces from the above and other clobber, just to show the bits that are important. If I were to add an argument then the XAML would look something like the following…

<Activity x:Class="{x:Null}">
    <x:Members>
        <x:Property Name="DateOfBirth" Type="InArgument(s:DateTime)" />
    </x:Members>
    <c:UIMessage Message="Hello from Workflow!" />
</Activity>

Now, when this activity is loaded from the database I’m returning it as a file to the workflow hosting mechanism. That is then converting it into a workflow (most probably using ActivityXamlServices.Load(stream). And when this method is used to load a workflow such as the one I’ve defined above, guess what the root node is? It’s a DynamicActivity – and guess what the ‘Name’ property of this class returns – well, that too is ‘DynamicActivity’.

So, in order to load up the appropriate configuration data for my dynamic workflows, I must have a <Service> element within the config file with the name “DynamicActivity”. That then plugs in the endpoint extension, which then allows me to call the workflow using my custom IDynamicWorkflow interface, which then means I’m a happy camper as I can do exactly what I set out to do in the first place.

Example Solution

I’ve created a sample Visual Studio solution and have attached a link at the end of this post. The solution consists of 4 projects as outlined below…

• A WPF client that allows you to create workflows and then run them.
  
• A server project that hosts a WCF service that the client calls to save and edit workflows.
  
• A shared project that both client and server use that contains the service contracts and also client proxy classes (I prefer to create these proxies myself when I own both ends of the service, rather than use Add Service Reference).
  
• An assembly that contains some custom activities.

In the client application you can create workflows (using “New” on the File menu). Once saved (give the workflow a name in the text box next to the save button) you can then click on a workflow and start an instance. I’ve added two custom activities to the toolbox, a “Message” activity which will display a message on the client UI when the workflow is executed, and a “Wait For Input” activity that creates a bookmark, tells you it’s created it, and then waits for the bookmark to be resumed.

So, this allows you to test the workflow(s) you have created in a rudimentary manner. As an example I created the following workflow that would emit a message at the start, then wait in a loop for one of two bookmarks to be resumed and will complete only if the second branch is executed…

Here the workflow outputs a message and the waits for one of two bookmarks to be completed (“Continue” and “Done”). If the Done bookmark is resumed then the loop exits and a completed message is displayed to the user.

When this workflow is executed you’ll see a bunch of log messages in the client application as shown below…

This shows I started the workflow, then there are two log messages indicating that a bookmark was created, then a message indicating that Continue ‘completed’ (meaning I resumed the ‘Continue’ bookmark from the UI). This loops back again to re-create the bookmarks, and I finally resumed the ‘Done’ bookmark which completed the workflow.

If you’re wondering, the client application also exposes a WCF service that the Web site hosting the server portion uses to notify these changes. That’s just for this example, it’s probably not a good idea for a real server application!

The Code

Please click here to download the code. If it works it was written by me, if it doesn’t I don’t know who wrote it.