Monday, 10 September 2012

Selecting Hierarchical data with WCF Data Services

In this post I’ll describe how you can use hierarchical data with WCF Data Services as it’s not immediately obvious how to do this, and there’s also an issue (which I believe to be a bug) that needs to be addressed in order for it to work.

In this example I have a simple table shown below, with a hierarchical link between employees. The keys are integers, defined as IDENTITY columns in SQL server. All the code for this example is attached to this post if you should wish to look into it further.

image

I’ve also created a stored procedure that selects people in a hierarchical manner using a CTE. This is as follows…

-- Create an SP that selects a hierarchical set of data
CREATE PROCEDURE SelectPersonHierarchy(@personId int) AS
SET NOCOUNT ON
;
WITH PersonHierarchy AS
(
SELECT PersonId, Name, ManagerId
FROM Person
WHERE PersonId = @personId
UNION ALL
SELECT p.PersonId, p.Name, p.ManagerId
FROM Person p
INNER JOIN PersonHierarchy ph
ON p.ManagerId = ph.PersonId
)
SELECT PersonId, Name, ManagerId
FROM PersonHierarchy
GO

So far so good. Next I created an EF model that includes the table above and the stored procedure too. Then I created a simple WCF data service as shown below – the extra method is used to expose the hierarchical stored procedure, so that clients can call it directly.


public class PersonService : DataService<PersonEntities>
{
public static void InitializeService(DataServiceConfiguration config)
{
config.SetEntitySetAccessRule("*", EntitySetRights.All);
config.SetServiceOperationAccessRule("*", ServiceOperationRights.All);

// And set the protocol version used
config.DataServiceBehavior.MaxProtocolVersion =
DataServiceProtocolVersion
.V2;
}

[WebGet]
public IQueryable<Person> GetFullPerson(int personId)
{
return this.CurrentDataSource.
SelectPersonHierarchy(personId).AsQueryable();
}
}

Next I created the client for this service using Add Service Reference. Then I created a method that would call the GetFullPerson method on the server, the outline of which is shown below…


public Person GetFullPerson(int personId, bool makeItWork)
{
Person root = null;

this.CreateQuery<Person>("GetFullPerson")
.AddQueryOption("personId", personId).ToList().ForEach(
t =>
{
if (null == t.ManagerId)
root = t;
else
{
Person parent = this.FindManager(root, t.ManagerId.Value);
parent.Subordinates.Add(t);
}
});

return root;
}

This method converts the data returned from the WCF operation to a list, iterates through that list and builds the client Person hierarchy (using a small helper function FindManager which, given a tree of objects, looks for the manager of the current person).


So, with all that in place we can write some unit tests to test the service. In my tests I’ve just used Boss and Employee as my two people. First off we’ll insert a Boss and an Employee & link them together…


Uri geller = new Uri("http://localhost:11341/PersonService.svc");
ServerService.PersonEntities context =
new ServerService.PersonEntities(geller);

// Insert hierarchical data to test with
var boss = new ServerService.Person { Name = "Boss" };
context.AddToPeople(boss);

var employee = new ServerService.Person { Name = "Employee", Manager = boss };
context.AddToPeople(employee);

// Important to add this - otherwise EF won't record the parent/child
// link in the database
context.AddLink(boss, "Subordinates", employee);

// Now save this to the server
context.SaveChanges();

Apologies for the awful pun in the Uri variable, I just can’t help myself. Here I create a boss, add an employee and then save the changes to the database. The important thing to mention is that you must also call context.AddLink() to ensure that there is a link between the parent and child objects. Here “Subordinates” is the name of the EF navigation property that is mapped from the parent of the relationship to the child. After saving these changes in the database you’ll see the following in the DB (Id’s will differ)…


image


OK, so far so good, we can create and save data to the server.


The Problem


The next thing I wanted to do was to verify that I could reload a person (in a hierarchical manner). So, my unit test was basically as follows…



  • Create a Boss and an Employee

  • Save these to the database

  • Reload these and test that all data was correct, including the link between employee and boss. This is where it all started to go wrong.

The reload code wasn’t working properly, and I tracked it down to the ManagerId field (after a fair amount of time). First I used Fiddler to log what was coming down from the server. My request looked OK…


image


And the data coming back from the server also looked OK…


image


However in my code that was looping through the data that came from the server the ManagerId was always null, for each and every row returned from the server.


In another test however it was fine – what gives?


The Solution


My two unit tests were identical – well, nearly. One verified what it got inline, another called a method to do that verification and the crucial difference was that the one that worked used a new service context. So, if you create a hierarchy of Boss & Employee on the client, save changes and reload (using the same client proxy), the hierarchical link is broken. If however you create a new client proxy and call the server everything works as expected.


My solution to this was to include the following in the method that calls the server…


public Person GetFullPerson(int personId)
{
Person root = null;

var currentMergeOption = this.MergeOption;
this.MergeOption = MergeOption.OverwriteChanges;

this.CreateQuery<Person>("GetFullPerson")
.AddQueryOption("personId", personId).ToList().ForEach(
t =>
{
if (null == t.ManagerId)
root = t;
else
{
Person parent = this.FindManager(root, t.ManagerId.Value);
parent.Subordinates.Add(t);
}
});

this.MergeOption = currentMergeOption;

return root;
}

This ensures that the data read from the server overwrites the data on the client, and in this instance that’s enough for the ManagerId to be set correctly rather than being Null.


Example Code


The following is a link to a .zip file that contains the same code. You’ll find a database script in the EFHierarchyProblem project called SchemaAndLogic.sql. Run this against your database.


You should also update the database connection strings in each project to reference your database. There are 3 projects in the solution, a class library that contains the EF model and the service, a Web project that exposes that service, and a Test project that runs the unit tests. When you run the tests you should see the following in the test results window…


image


The Test_ServerService_WillFail should work but doesn’t, as the ManagerId is overwritten when reloading the data. The _WillWorkSameContext test uses the merge option to overwrite local data to ensure that the ManagerId isn’t overwritten, and the _WillWorkNewContext test inserts data but then requests it from a new client proxy which will always work.


The .zip can be downloaded from here.

Tuesday, 12 June 2012

Redesigning the Decision activity

In a couple of recent posts on Morphing Conditional Activities and Constraining Dropped Activities I’ve been steadily redesigning the Decision activity so that it is easier to use by non-programmers. There was one thing I left out which was re-styling the designer so that it looks and works a bit more like other activities. I’ll address that in this post.

Where I left off was an activity that looks like the following (I’ve added two red rectangles to indicate the parent and child activities here)…

image

That’s OK, however the title bar of the decision activity is looking a bit minimal. The issue here is that this name is, by default, not bound to the display name of the inner activity, and so it displays nothing. What would be preferable is to have the title bar look and work like the other standard activities, and for that there’s a fair bit of work to do.

There are two classes you can derive your activity designers from in .NET – most derive from ActivityDesigner which provides the standard look and feel as shown above, and if you wish to have more control over what is displayed (where more control == do it all yourself) then you can derive from WorkflowViewElement.

Having looked at the XAML for the inbuilt activity designer class (using Reflector) I felt it was not possible to use this, primarily because there was no way I could see to alter the binding on the caption bar. So, I created my own and along the way made some tweaks.

First off I started with a grid comprising 2 rows as follows…

image

The second row simply contained a WorkflowItemPresenter that will display the conditional activity dropped into place. The top row had to be further split into three columns, the left hand side for the decision icon, the middle for the display name of the child activity and the right for the validation error/warning icon.

Note: The inbuilt activity designer also includes UI for debugging, and also UI for expand/contract. I omitted the first part as the application I’m working on does not permit you to interactively debug a workflow, and I did not wish to expand or contract this activity so left this out of the designer.

So, my designer now looks something like this…

image

The icons for all of the standard activities are contained within the System.Activities.Presentation assembly as a resource, so I added in this and a couple other standard resource dictionaries to my activity XAML.

The validation icon needs to be displayed if the child activity has a validation warning or error. The activity we’re designing is the FlowDecision, and the Condition property is the one that holds the child activity, so we can use a binding syntax of ModelItem.Condition.ValidationState to check whether the child activity is (or is not) valid. Similarly, the ModelItem.Condition.ValidationMessage property path gets the error(s) associated with the child activity.

So, we have the Icons done, now for the name.

In the standard Activity designer, the name is actually formed using two controls, a textblock that displays the read-only name, and a textbox that is displayed when you click into the name, or when you tab into it using the keyboard. I wanted the same behaviour on my control so crufted up a couple of controls and hooked to a couple of events in order to get this working as expected. If you use the standard activity designer to rename an activity, you may notice that the textbox is not positioned exactly the same as the textblock, so when you enter edit mode the text will shift slightly. This annoys me something chronic, so I made sure that with my designer both items line up correctly, so there is no perceptible shift in the text when moving in and out of edit mode.

With that in place my activity is complete. Now I see the following on screen…

image

There’s some more going on in the XAML to ensure that the outline updates appropriately when selected, and this uses the standard colour resources so fits in with the colour scheme. Feel free to download the code and have a poke around.

Friday, 8 June 2012

ExpressionTextBox in .NET 4.5

The ExpressionTextBox allows you to databind to an argument on your activity and has, up until 4.5, had an optional OwnerActivity attribute which seemed to be optional. Whilst all activities in the framework used it, some custom activities might have omitted it as it worked in 4.0 without needing to be explicitly defined.

Now with .NET 4.5 this attribute is no longer optional – check out what I get if I forget to add it (the 3rd textbox is the one with the missing attribute, and I’m in a C# project)…

Capture

Not only do you get the horrific “Enter a VB expression” text, which sends a chill down my spine each time I see it, you’ll also find that the textbox is read-only if you omit the OwnerActivity attribute. It’s easy to fix though, the following highlighted XAML is all you need to change…

  <sapv:ExpressionTextBox 
Expression="{Binding ModelItem.Body, Converter={StaticResource conv}}"
OwnerActivity="{Binding ModelItem}" .../>

This change in behaviour might be a problem for anyone upgrading their solutions to 4.5, so hopefully someone will find this post useful.

Monday, 16 April 2012

Adding extensions to a hosted workflow

When hosting Workflows using WorkflowServiceHost or Windows Server AppFabric you may wish to add extensions to the runtime environment so that custom activities can access these extensions. Typically you’ll write custom activities to access some form of extension using a custom interface, and then provide an implementation of this interface at runtime.

When you are self hosting (using WorkflowInvoker or WorkflowApplication) it’s a simple matter of adding an object to the ‘host’, such as shown in the code below…

WorkflowInvoker invoker = new WorkflowInvoker(GetWorkflow());
invoker.Extensions.Add<IActivityLogger>(() => new ActivityLogger());

If you’re hosting using configuration using WorkflowServiceHost or AppFabric however it’s common to define everything in the web.config, however Workflow 4 doesn’t come with an out of the box mechanism to do this.


What I’d like to do is be able to configure up a bunch of extensions using the following in my web.config file…


<workflowExtensions>
<
extensions
>
<
add name="{something}"
extensionType="{Fully Qualifier Typename}"
{Optional Parameters}
/>
</
extensions
>
</
workflowExtensions
>

Now, if you’ve been using .NET for a while you might recognise this pattern – it’s very simple to the way you configure providers in ASP.NET, for things like membership, roles etc. I’ve done this deliberately – the provider model is a good pattern to use and fits this example well.


What I then need is something to read the set of extensions, and instantiate them for each hosted workflow. To do this you need a bit of WCF knowledge.


Behavior Extensions


A behavior extension allows us to inject some code into the WCF pipeline, and in this case I’m using one to instantiate objects defined in my <workflowExtensions> element. First up you need a class that derives from BehaviorExtensionElement as shown in the code below…


/// <summary>
///
Class which is used to define the configuration element for the
/// web.config, so we can add extensions to the workflow
/// </summary>
public class WorkflowExtensionsElement :
BehaviorExtensionElement
{
/// <summary>
///
Return the type of object that is created by this extension
/// </summary>
public override Type BehaviorType
{
get { return typeof(WorkflowExtensionsBehavior); }
}

/// <summary>
///
Construct the behavior
/// </summary>
/// <returns>
A behavior, created from the config in the web.config
</returns>
protected override object CreateBehavior()
{
List<WorkflowExtension> extensions = new List<WorkflowExtension>();

foreach (WorkflowExtensionConfigElement item in WorkflowExtensions)
extensions.Add(new WorkflowExtension(item.Name,
item.ExtensionType, item.Parameters));

return new WorkflowExtensionsBehavior(extensions);
}

///
Declare the extensions collection property.
[ConfigurationProperty("extensions", IsDefaultCollection = true)]
[ConfigurationCollection(typeof(WorkflowExtensionsCollection),
AddItemName = "add",
ClearItemsName = "clear",
RemoveItemName = "remove")]
public WorkflowExtensionsCollection WorkflowExtensions
{
get { return (WorkflowExtensionsCollection)base["extensions"]; }
}

}

This uses some other classes that are in the code download that read the appropriate information from the .config file. You then need to include some modifications to the .config file in order for this new behavior to be executed when reading the .config file…

  <system.serviceModel>

<
extensions
>
<behaviorExtensions
>
<
add name="workflowExtensions"
type="MSADC.Workflow.WorkflowExtensionsElement, MSADC.Workflow"
/>
</
behaviorExtensions
>
</
extensions>

This includes the extension such that we can then alter our behaviors element to include the list of extensions…

    <behaviors>
<
serviceBehaviors
>
<
behavior name=""
>
<
serviceMetadata httpGetEnabled="true"
/>
<
serviceDebug includeExceptionDetailInFaults="false"
/>
<
workflowExtensions
>
<
extensions
>
<
add name="logger"
extensionType="Demo.ActivityLogger, Demo"
/>
</
extensions
>
</
workflowExtensions
>

Extension Parameters


Now we have the ability to configure up an extension, how about additional parameters that the extension might need to use? Simple – the code that parses the <add> elements reads any additional attributes and pops these into a NameValueCollection, then during instantiation of the extension I check if the extension derives from the ProviderBase class. If so I simply call the Initialize() method, passing in the name of the provider and the NameValueCollection.


You could use this to pass in a database connection string name or other information – you just need to derive from ProviderBase and read the configuration parameters from the passed collection.


The Code


The download includes two projects, MSADC.Workflow and MSADC.Workflow.Common. I’ve refactored the code from my Hosting Dynamic Workflows example to move this into these libraries as there’s more to come and I need to keep this all in a sensible place. If you’re wondering about the name, MSADC is the shortened form of my company name (MS Application Development Consulting Ltd). I provide bespoke, deeply technical consulting on Windows Workflow 4 (and SIlverlight 4/5, WPF 4, WCF and lots of other parts of the .NET framework).


If you want some help from someone who knows what they’re talking about please get in touch!


The code is available as a NuGet package. Please click here to access the package. If you have any comments please contact me using the Contact Owners link from within NuGet.

Friday, 14 October 2011

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…

image

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.

Thursday, 13 October 2011

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…

image

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…

image

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…


image


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…


image


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…


image


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…


image


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.

Monday, 10 October 2011

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…

image

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…


image


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…


image


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. Smile