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.