PeteGoo

Code and slides for Dev208 at Tech Ed NZ

2010-09-01T09:48:39Z

Here are the slides and demos for the Tech Ed NZ talk Stef and I did on Intro to Workflow 4. It includes the Approval Sample we didn’t manage to fit in.

P.S. I know this blog sucks in IE, working on a fix when I get some time.

DEV208-GettingStartedWithWorkflow.pptx

Intro To WF Demos.zip

Workflow 4: Human based workflows with an Email Approval Sample

2010-08-22T22:13:17Z

One of the questions that a lot of people ask about workflow 4 is how to integrate manual tasks into the workflow process so that humans can be involved and interact with the workflow process. After all, what use is a stateful, long running service if no humans are involved? All of the activities that ship with workflow 4 and many of the samples provided only really cover programmatic activities but what about user interaction, I mean WF4 does not even ship with an email activity.

The purpose of this post is to introduce the concept of a manual task into a workflow process and show how correlation can be used to help route service calls back to the originating workflow instance.

Scenario

The problem we will try to solve is that we have a textual statement that needs to be sent to a number of people (approvers) who must approve or decline, indicating their acceptance of the statement. Once all the approvers have completed their tasks a report of the number of approvals is sent to the requestor. We are going to use emails to send the manual tasks to our approvers. The emails will have “Approve” and “Decline” links in them, clicking these links will update the status of the task in the workflow.

The Workflow

We start our workflow by creating a Workflow Service Library project and adding the parameters to our Receive activity to take the list of approver emails, the message which will be the statement that should be accepted or declined and the email of the requestor so that the report can be sent back to them. These parameters will be assigned to variables within our workflow.

Next we have to process each of the approval emails and handle the corresponding responses. The rest of the workflow is shown below.

So lets walk through it.

ParallelForEach<string>

The first thing we need to consider is that we are going to process each of the approvals in parallel so that we are not dependent on the order of the responses. To do this we use a ParallelForEach<T> activity, this is essentially a parallel activity which will create a branch for each item in the source collection. The source collection in our case is the array of approver email addresses.

Send Approval and Wait for Response

This sequence will contain all our processing for a single approver branch. The most important things here which can’t be seen from the above image are the variables that belong to this sequence.

- approverId :This is a unique Guid initialised here to a new random guid. This will be used as a unique identifier for this approver.

- ApprovalCorrelationHandle: A correlation handle is a special type in workflow which holds information about how an incoming information can find our instance More on this later.

Send Approver Email

First we construct and send an email using a custom SendEmail activity included in the source. The implementation of this activity is not important, for our purposes all we care about is that it has four arguments, ToAddress, FromAddress, Subject and Body. The body contains an HTML message with Accept an Decline links to the web site we will create later.

"<html>" & _
"  <body>" & _
"    <p>Please approve or decline the following statement:</p>" & _
"    <h2>" & messageToApprove & "</h2>" & _
"    <a href=""http://localhost/TechEdNZ/Approval.Web/Approval/Approve/" & approverId.ToString() & """>Approve</a><br/>" & _
"    <a href=""http://localhost/TechEdNZ/Approval.Web/Approval/Decline/" & approverId.ToString() & """>Decline</a><br/>" & _
"  </body>" & _
"</html>"

As you can see it contains a bunch of not so pretty VB string concatenation. Not ideal but fit for our purposes.

InitializeCorrelation

The initialize correlation activity is used to setup our CorrelationHandle we declared earlier, We simply set the name of a correlation key “approverId” to the value of our guid variable “approverId.ToString()”. This means that we now have a correlation handle which can be used later on our Receive activity to allow the runtime to find this specific instance when the Receive endpoint is called with a compatible correlation parameter.

Pick

A pick is a very useful activity which basically says, perform each of my branches’ “trigger” sections in parallel and when the first one of them completes, cancel the other branched and run the completed branches’ “action” section. This is especially useful if you want to setup a number of Receive activities, essentially presenting a choice, and continue the workflow when a choice is made. In our case these triggers will be our Accept and Decline Receive activities.

Receive and SendReply

The two receive activities are simply operations on the same endpoint named “Accept” and “Decline”, they both have a single parameter called approverId which correlates to our unique guid via our CorrelationHandle, for more on how to setup correlation, see my previous post on the subject.

Assign

The assign simply increments an approval counter if the approver selected Approve

Send Result Email

The send result sends the approval count to the original requestor.

The Web App

Unfortunately, WF4 does not easily support REST as a communication mechanism for its Receive activities so we needed the links in our email to present a confirmation to the approver and at the same time call our workflow. This was most easily accomplished via an ASP.Net MVC2 web application with an ApprovalController as follows:

public class ApprovalController : Controller {

    public ActionResult Approve(string id) {
        ApprovalWorkflowService.ServiceClient serviceClient = new ApprovalWorkflowService.ServiceClient();
        serviceClient.Approve(id);
        return View();
    }

    public ActionResult Decline(string id) {
        ApprovalWorkflowService.ServiceClient serviceClient = new ApprovalWorkflowService.ServiceClient();
        serviceClient.Decline(id);
        return View();
    }

}

The RouteMapping in ASP.Net MVC will automatically turn our email link into the above method call which in turn will call our workflow with the appropriate approverId.

The Client

The client app here is just a console app with the following code:

ApprovalWorkflowService.ServiceClient client = new ApprovalWorkflowService.ServiceClient();
client.BeginApprovalProcess(new[] {
                                      "approver1@foo.com", 
                                      "approver2@foo.com", 
                                      "approver3@foo.com"
                                  }, 
                                  "Holiday approval for Joe Bloggs from 2nd December to 12th January?", 
                                  "joe.bloggs@foo.com");

Summary

And that’s about it. Correlation comes to the rescue enabling us to send the 3 emails to the above addresses and, when they all click the links in their emails, the MVC app sends a message to our workflow definition. That message is routed to the correct workflow instance because the Receive activity told the runtime to wait for a call to “Accept” with one of 3 approver ids and to route that call to our instance. After they have all responded the workflow will continue past the ParallelForEach and the result is sent.

This application is fully compliant with pretty much any platform that has email and a browser and that’s as as simple as it gets.

What Next

This is just the beginning of how manual tasks can work in workflow. You could start to expand on this concept by mapping more data into your emails so that the approver is doing something more useful. Another option is to implement a threshold using a simple “If” so that e.g. 2 out of 3 approvers must approve and the workflow could subsequently decide whether to make a call to an HR service or something similar.

I hope you found this post helpful, code below.

PeteGooApprovalSample.zip

Unit Test Workflow 4 Activities : Dependency Injection

2010-08-16T15:04:53Z

At first glance unit testing workflow activities with dependency injection seems like a no-brainer. For example consider the following activity using constructor-based dependency injection.

public class SendEmail : CodeActivity {
    private readonly IEmailClient emailClient;

    public SendEmail() : this(new EmailClient()) {}

    public SendEmail(IEmailClient emailClient) {
        this.emailClient = emailClient;
    }

    public InArgument<string> To { get; set; }

    public InArgument<string> From { get; set; }

    public InArgument<string> Subject { get; set; }

    public InArgument<string> Message { get; set; }

    protected override void Execute(CodeActivityContext context) {
        emailClient.SendEmail(
            To.Get(context),
            From.Get(context),
            Subject.Get(context),
            Message.Get(context)
            );
    }
}

public interface IEmailClient {
    void SendEmail(string to, string from, string subject, string message);
}

public class EmailClient : IEmailClient {
    public void SendEmail(string to, string from, string subject, string message) {
        throw new NotImplementedException();
    }
}

I have an email client but I choose to write my tests so that I can replace the implementation of IEmailClient such that I can stub or mock the implementation out as below. This is absolutely necessary for unit testing as we cannot have our real implementation of the Email Client sending emails when we run our unit tests. Therefore we swap out with a stub implementation that simply logs the fact that we have called SendEmail.

[TestMethod]
public void ExecuteCallsSendEmailOnClient() {
    StubEmailClient stubEmailClient = new StubEmailClient();
    WorkflowInvoker.Invoke(
        new SendEmail(
            stubEmailClient) {
                                       From = "foo@foo.com",
                                       To = "bar@bar.com",
                                       Subject = "The Subject",
                                       Message = "The Message"
                                   });

    Assert.AreEqual(1, stubEmailClient.SentEmails);
}

private class StubEmailClient : IEmailClient {
    private int sentEmails;
    public int SentEmails {
        get { return sentEmails; }
    }
    public void SendEmail(string to, string from, string subject, string message) {
        sentEmails++;
    }
}

So great! Now we have unit tested our activity and all is good with the world, no different from any other unit testing, right? But what if I have a workflow activity written in XAML that uses my SendEmail activity.

<Activity mc:Ignorable="sap"
          x:Class="PeteGoo.TimeService.Activities.SendMultipleEmails"
          xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities"
          xmlns:local="clr-namespace:PeteGoo.TimeService.Activities"
          xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
          xmlns:mva="clr-namespace:Microsoft.VisualBasic.Activities;assembly=System.Activities" 
          xmlns:sad="clr-namespace:System.Activities.Debugger;assembly=System.Activities"
          xmlns:sap="http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation" 
          xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <x:Members>
    <x:Property Name="FromAddress"
                Type="InArgument(x:String)" />
    <x:Property Name="Subject"
                Type="InArgument(x:String)" />
    <x:Property Name="Message"
                Type="InArgument(x:String)" />
    <x:Property Name="ToAddresses"
                Type="InArgument(s:String[])" />
  </x:Members>
  <ForEach x:TypeArguments="x:String"
           DisplayName="ForEach&lt;String&gt;"
           sad:XamlDebuggerXmlReader.FileName="E:\Code\Blog\UnitTestingActivities\PeteGoo.TimeService.Activities\SendMultipleEmails.xaml"
           sap:VirtualizedContainerService.HintSize="287,206"
           Values="[ToAddresses]">
    <ActivityAction x:TypeArguments="x:String">
      <ActivityAction.Argument>
        <DelegateInArgument x:TypeArguments="x:String"
                            Name="toAddress" />
      </ActivityAction.Argument>
      <local:SendEmail From="[FromAddress]"
                       sap:VirtualizedContainerService.HintSize="257,100"
                       Message="[Message]"
                       Subject="[Subject]"
                       To="[toAddress]" />
    </ActivityAction>
  </ForEach>
</Activity>

Now suppose I want to test my XAML activity, how can I use dependency injection? XAML is now in control of the construction, so I cannot use constructor based Dependency Injection. This is a big problem as we really want to use the composition model that WF4 provides us and the declarative programming model of XAML but that stops us from using familiar unit testing techniques. Yes, there are other types of dependency injection but maybe workflow extensions can be useful here.Workflow Extensions allow us to provide common services in a Service Locator pattern built into the execution context. Typically they are used for Tracking Participants and Persistence Participants which are recognised as they implement a well known contract, in this case however we are going to take advantage of the fact that workflow extensions can be any arbitrary type. Consider the following workflow extension and the associated Extension method.

public class DependencyInjectionExtension {

    private readonly Dictionary<Type, object> dependencies = new Dictionary<Type, object>();
    public void AddDependency<T>(T instance) {
        dependencies.Add(typeof(T), instance);
    }

    public T GetDependency<T>(Func<T> defaultFunc) where T : class {
        if (dependencies.ContainsKey(typeof(T))) {
            return dependencies[typeof (T)] as T;
        }

        return defaultFunc();
    }
}

public static class ActivityContextExtensions {
    public static T GetDependency<T>(this ActivityContext context, Func<T> defaultFunc) where T : class {
        DependencyInjectionExtension extension = context.GetExtension<DependencyInjectionExtension>();
        
        return extension == null ? defaultFunc() : extension.GetDependency<T>(defaultFunc);
        
    }
}

Now we can use this extension and the extension method to change our Execute implementation to the following.

protected override void Execute(CodeActivityContext context) {
    IEmailClient client = context.GetDependency<IEmailClient>(() => new EmailClient());

    client.SendEmail(
        To.Get(context),
        From.Get(context),
        Subject.Get(context),
        Message.Get(context)
        );
}

This shows that we will ask the GetDependency extension method for a certain service (IEmailClient) and if it has not been specified simply use a new EmailClient instance. The extension method in turn, checks whether the extension has been added and if so asks it for the dependency. If the extension is not present or it does not contain a dependency for our type then the supplied func is called which will return that EmailClient instance. And our test is as follows:

[TestMethod]
public void ExecuteCallsSendEmailOnClient() {
    StubEmailClient stubEmailClient = new StubEmailClient();

    WorkflowInvoker invoker = new WorkflowInvoker(
        new SendEmail {
                                       From = "foo@foo.com",
                                       To = "bar@bar.com",
                                       Subject = "The Subject",
                                       Message = "The Message"
                                   
        });

    DependencyInjectionExtension dependencyInjectionExtension = new DependencyInjectionExtension();
    dependencyInjectionExtension.AddDependency<IEmailClient>(stubEmailClient);

    invoker.Extensions.Add(dependencyInjectionExtension);

    invoker.Invoke();

    Assert.AreEqual(1, stubEmailClient.SentEmails);
}

So now we have implemented a dependency injection pattern explicitly for workflow activities. We can now test composite XAML or code-based activities as well as ordinary code activities without requiring that we stay in control of the construction of our object instances.

UnitTestingActivities.zip

Unit Testing Workflow 4 Activities : The TestContext Tracking Participant

2010-08-16T13:48:52Z

I’m a big believer in using TestContext in MSTest or Console.WriteLine, Debug.WriteLine etc in your favourite Unit Testing framework to give context to passed or failed tests. Especially if you do CI and have only the test results to look at from the build server to try to understand why a build went wrong.

Taking this into account I use a TestContext Tracking Participant to get more visibility into my workflow unit tests. This enables me to see what tracking records have been raised against my invoked workflows. In only a few lines of code you can quickly enable extra logging.

public class TestContextTrackingParticipant : TrackingParticipant {
    private readonly TestContext testContext;

    public TestContextTrackingParticipant(TestContext testContext) {
        this.testContext = testContext;
    }

    protected override void Track(TrackingRecord record, TimeSpan timeout) {
        testContext.WriteLine(string.Format("- {0}", 
            record.ToString()
            .Replace("{", "{{")
            .Replace("}", "}}")));
    }
}

The only issue is that our invoker code from the previous post is a little more verbose.

[TestMethod]
public void ExecuteConvertsTimeToTargetCity() {

    DateTime currentLocalTime = DateTime.Now;
    string cityName = "London";

    TimeZoneInfo timeZoneInfo =
        TimeZoneInfo.GetSystemTimeZones().Where(
            timeZone => timeZone.DisplayName.ToUpperInvariant().Contains(cityName.ToUpperInvariant())).First();

    GetCityTime activity = new GetCityTime() {
                                                    City = cityName,
                                                    LocalTime = new InArgument<DateTime>(currentLocalTime)
                                                };
    WorkflowInvoker invoker = new WorkflowInvoker(activity);

    invoker.Extensions.Add(new TestContextTrackingParticipant(TestContext));

    DateTime result = (DateTime)invoker.Invoke()["Result"];

    Assert.AreEqual(TimeZoneInfo.ConvertTime(currentLocalTime, timeZoneInfo), result);
}

Unit Testing Workflow 4 Activities : Basics

2010-08-16T13:22:42Z

Unit testing workflows became a lot easier in WF4. The basic approach is the same as for normal code classes except for a few differences which we will cover in the posts in this series.

Lets start off with a simple code activity which will return the time in a given city.

public class GetCityTime : CodeActivity<DateTime>{

    [RequiredArgument]
    public InArgument<string> City { get; set; }

    public InArgument<DateTime> LocalTime { get; set; }

    protected override DateTime Execute(CodeActivityContext context) {
        string city = City.Get(context);

        TimeZoneInfo timeZoneInfo = GetTimeZoneForCity(city);
        if (timeZoneInfo == null) {
            throw new ArgumentOutOfRangeException(string.Format("Could not find timezone matching city '{0}'", city));
        }

        return TimeZoneInfo.ConvertTime(LocalTime == null ? DateTime.Now : LocalTime.Get(context), timeZoneInfo);
    }

    private TimeZoneInfo GetTimeZoneForCity(string city) {
        return TimeZoneInfo.GetSystemTimeZones()
            .Where(
                timezone => timezone.DisplayName.ToUpperInvariant().Contains(city.ToUpperInvariant()))
            .FirstOrDefault();

    }
}

So lets start to build our first test. The WorkflowInvoker class allows us to execute a workflow activity in a blocking manner, meaning that it will execute the activity and wait for completion before continuing. We begin by testing that the City argument in indeed a required argument. This is always a good place to start and will make you think about the validations in your activity.

[ExpectedException(typeof(ArgumentException))]
[TestMethod]
public void CityIsARequiredArgument() {
    WorkflowInvoker.Invoke(new GetCityTime());
}

Next we are going to check that providing an invalid value for City will indeed throw an exception.

[ExpectedException(typeof(ArgumentOutOfRangeException))]
[TestMethod]
public void InvalidCityThrowsArgumentException() {
    WorkflowInvoker.Invoke(new GetCityTime() {City = "BlaBlaBla"});
}

The last test is to check the actual execution. A handy feature of the WorkflowInvoker generic static methods are that you can execute an Activity<T> and the return signature of the WorkflowInvoker.Invoke method will be the Result type of our Activity (T).

[TestMethod]
public void ExecuteConvertsTimeToTargetCity() {
    DateTime currentLocalTime = DateTime.Now;
    string cityName = "London";

    TimeZoneInfo timeZoneInfo =
        TimeZoneInfo.GetSystemTimeZones().Where(
            timeZone => timeZone.DisplayName.ToUpperInvariant().Contains(cityName.ToUpperInvariant())).First();

    DateTime result = WorkflowInvoker.Invoke(new GetCityTime() {
                                                          City = cityName,
                                                          LocalTime = new InArgument<DateTime>(currentLocalTime)
                                                      });
    Assert.AreEqual(TimeZoneInfo.ConvertTime(currentLocalTime, timeZoneInfo), result);
}

UnitTestingActivities.zip

WF4 Services Part 2 – Correlation

2010-06-27T11:13:19Z

Continuing on from Part 1 now we are going to add the Calculation operations to our stateful workflow service. First we need to look back and understand our previous operation “Start”.

If you look at the Receive activity for the Start operation you will see that it has a property in the properties panel (F4) called CanCreateInstance and it is set to true. This property means that a call to this operation will start a new instance of our workflow. Up to now our service has simply started when we called the “Start” method and ended after the response was sent. This is all well and good but as I stated above we want a stateful service that will track the current value of our operations and let us perform further operations in a chaining manner. To do this our Add, Subtract, Divide and Multiply operations are not going to create new instances but simply act upon the previous return value.

This poses a problem, if we can call the start operation multiple times and create multiple instance how are we going to know which instance we want when we make the subsequent calculation operations? This is where correlation comes in. Correlation is simply the method by which we direct incoming messages to the correct workflow instance. In our example we are going to use a parameter on each operation called session name. This will allow us to tag the session with a name so that we can bring up the right instance when we make subsequent calls. First we are going to need a CorrelationHandle. This is a special type provided by workflow which allows us to create this token so that the runtime can correlate properly.

1. At the root sequence (Sequential Service), add a variable of type System.ServiceModel.Activities.CorrelationHandle called “SessionNameCorrelationHandle”. You do not need to default this variable, any type that derives from System.Activities.Handle will be constructed automatically by the runtime.

2. Also at the root sequence add another variable called “SessionName” of type string. This is going to hold the actual session name specified on the Start operation.

3. Edit the Content for the ReceiveRequest activity and add a parameter called “sessionName” of type string and assign it to the variable “SessionName”.

Now we need to initialize our correlation handle on the Start operation.

4. On the send reply activity add another return parameter called “SessionReturn” which returns our SessionName variable.

5. Also on the send reply activity, from the properties panel choose CorrelationInitializers, add the initializer to our SessionNameCorrelationHandle on the left. On the right make sure you have “Query Correlation Initializer” selected which will allow us to choose a value from the result to initialize the correlation handle.From the drop down under XPath Queries choose our SessionReturn parameter.

You do not have to use this method to initialize the correlation handle. You could also use the InitializeCorrelation activity and place it after the SendReply activity, initializing from the “SessionName” variable rather than the return parameter.

Next we need to add our calculation operations which can be performed as many times as we want until we choose to end the session. To do this we are going to use a Pick activity to host 4 Receive and SendReply pairs (Add, Subtract, Divide, Multiply). The Pick activity is kind of like a parallel which contains multiple Pick Branches. Each Branch has a trigger and an action. Once the trigger in a branch has been satisfied the other branches are all cancelled and the action for the triggered branch is executed. We are going to use the Trigger part of each branch to host an infinite loop of the Receive/SendReply pairs so that they continue to accept subsequent calls.A final Pick branch will contain the End operation which will Stop the Calculator session and free up the correlation handle.

6. Add a Pick activity at the end of our current workflow. Rename Branch1 to “Add Branch” by changing the title.Drag a While activity into the Trigger of "Add Branch”, set the condition to True so that it repeats indefinitely.

7. Drag a ReceiveAndSendReply from the toolbox into the While activity’s Body, change the operation name to “Add”. In the sequence created by the ReceiveAndSendReply add an Int32 variable called X. Change the content of the Receive(Add)to Parameters with an Int32 parameter called X and a string parameter called SessionName. Assign the X parameter to our X variable.

8. To setup the correlation click on the CorrelatesOn property in the properties panel (F4) of the Receive(Add) activity. Change the CorrelatesWith to point to our SessionNameCorrelationHandle. Choose the property SessionName. Make sure the Key matches the key used in step 5.

9. In between the Receive(Add) and it’s SendReply activity drag an Assign activity. In the To section enter the Value variable and in the right hand side enter the expression “Value + X”.

10. On the SendReplyToReceive of the Add pair change the content to return parameters with a single parameter Result with a value of our Value variable.

11. Delete Branch2 from the pick and lets test what we have with CTRL+F5. Open the Start operation and enter an integer value and a string session name then invoke. Open the Add method and repeat the same name with another integer.

12. Now Copy and paste the Add branch to create a Subtract, Divide and Multiply branches changing the operation names and assign activities as necessary. Note that you will need to go into each branch and change the CorrelatesOn property of each Receive activity so that the XPath is correct and not pointing to the Add method. Also remember to keep the Key the same as step 5. You will need to use the “\” integer divide operator of VB to do the divide assign statement.

13. Finally we need to add a branch for our end activity. This will be another Pick branch but this time there will be no While loop so that when it gets called, the other branches will get cancelled and the workflow will complete. Drag on a new PickBranch, Drag a ReceiveAndSendReply into the trigger, change the operation name, add the SessionName parameter to the content and set the correlation like the others.

So now we have created our stateful service with correlation on a session name. You should note that you cannot use the session name after calling End just like you could not use a random new session name on any operation but Start.

In the next part we will look at what happens in the service host to enable these services endpoints to be created.

Code for this post is attached below.

CalculatorWorkflowService.zip

WF4 Services Part 1–The simple WF Service

2010-06-27T08:56:42Z

I thought I’d do a series of posts on workflow services. There are plenty of resources out there already on how to build workflows and activities although not a huge amount has been said about workflow services. In my opinion this is the real power of workflow and its where WF4 really comes into its own. In fact I’m going to presume that you’ve played a little with workflow and understand what an activity is, that’s about it.

Over the series we’re going to be building a calculator service which performs integer operations in a stateful way so that subsequent operations build on the previous output.

1. Open Visual Studio 2010

2. Create a New Project of Type Visual C#/Workflow/WCF Workflow Service Application

3. The project template should create the following workflow for you.

So what are these activities? Well if you’ve read any other intros to workflow you will know that the outer activity is a Sequence. Simply put, the child activities enclosed in a sequence are executed sequentially, of course. The activities labelled ReceiveRequest and SendResponse are Receive and SendReply activities. Typically found together these activities are the basis of creating any workflow service. Each pair represents an operation on a service contract. The operation name as shown here is GetData and the “Content” on each of the activities is the definition of the Request or Response message.

4. Next we’re going to change the operation name and the message contents so that we get an Start operation for our Calculator service which accepts and integer.

The Start operation is going to take an integer value and begin our calculator service. From this integer we can then perform as many operations as we like acting on the current state. To store the current state we need to first create a “Value” variable. Click on the Variables button at the bottom of the designer and add a new Int32 variable called “Value”. You can delete the data variable as we will not need it.

On the ReceiveRequest activity change the OperationName to “Start”. Click View Message next to the Content of the ReceiveRequest activity, change the mode to “Parameters” and add a new parameter called value of type integer and assign it to our “Value” variable.

On the “SendResponse” activity change the message content to “Parameters” and add a “Result “ parameter with the value as below:

5. Run the service by hitting CTRL+F5, this will start the WCF Test Client. Double click the Start method on the left hand pane and enter an integer value then Invoke. You should see the result of our service operation as below;

You can notice that we have created a service with the contract name “IService” which has a single operation “Start” accepting an integer value and returning a string. This is really no different than creating a normal WCF service with a contract interface and an implementation class that returns a string like the following:

public class Service1 : IService1 {
    public string Start(int value) {
        return string.Format("Calculation session started with value {0}", value);
    }
}

[ServiceContract]
public interface IService1 {

    [OperationContract]
    string Start(int value);
}

So how do we change the contract name? Click the Receive activity and then on the Properties panel (F4) change the ServiceContractName property to another namespace and name combination.

So that was how to quickly create a WF4 service. Next we’ll add the calculation operations and do some correlation.

The source for the steps in this post is attached below.

CalculatorWorkflowService.zip

Hello again

2010-06-27T07:11:20Z

So, I’ve been pretty bad at updating my blog recently, and answering comments / deleting spam.

I’ve been spending most of my time in Workflow 4 recently so I think I’ll do a series or 2 of posts on that. Hopefully someone finds it interesting / useful.

Using JSON.Net to eval json into a dynamic variable in C#

2009-10-27T10:22:13Z

So I thought this would be possible and finally decided to give it a shot in 2010 Beta 2. It turns a bunch of JSON into an ExpandoObject using JSON.Net.

Needs cleaning up but not too bad.

[TestMethod]

public void DeserializeTestObjectToDynamic(){

TestObject testObject = new TestObject() {

FirstName = "Peter",

LastName = "Goodman",

DateOfBirth = new DateTime(1979, 2, 3),

Child = new TestChildObject {

Line1 = "child line 1",

Line2 = "child line 2",

Line3 = "child line 3",

City = "child city"

Children = new Collection<TestChildObject>() {

new TestChildObject() {

Line1 = "children 1 line 1",

Line2 = "children 1 line 2",

Line3 = "children 1 line 3",

City = "children 1 city"

new TestChildObject() {

Line1 = "children 2 line 1",

Line2 = "children 2 line 2",

Line3 = "children 2 line 3",

City = "children 2 city"

}

};

// Get our json string

string json = JsonConvert.SerializeObject(testObject);

// Create the json.Net Linq object for our json string

JObject jsonObject = JObject.Parse(json);

// eval into an expando

dynamic dynObject = ConvertJTokenToObject(jsonObject);

Assert.IsNotNull(dynObject);

Assert.IsNotInstanceOfType(dynObject, typeof(TestObject));

Assert.IsInstanceOfType(dynObject, typeof(ExpandoObject));

Assert.AreEqual(testObject.FirstName, dynObject.FirstName);

Assert.AreEqual(testObject.LastName, dynObject.LastName);

Assert.AreEqual(testObject.DateOfBirth, dynObject.DateOfBirth);

Assert.IsNotNull(dynObject.Child);

Assert.AreEqual(testObject.Child.Line1, dynObject.Child.Line1);

Assert.AreEqual(testObject.Child.Line2, dynObject.Child.Line2);

Assert.AreEqual(testObject.Child.Line3, dynObject.Child.Line3);

Assert.IsNotNull(dynObject.Children);

Assert.AreEqual(testObject.Children.Count, dynObject.Children.Length);

for (int i = 0; i < testObject.Children.Count; i++) {

Assert.AreEqual(testObject.Children[i].Line1, dynObject.Children[i].Line1);

Assert.AreEqual(testObject.Children[i].Line2, dynObject.Children[i].Line2);

Assert.AreEqual(testObject.Children[i].Line3, dynObject.Children[i].Line3);

}

public object ConvertJTokenToObject(JToken token) {

if (token is JValue) {

return ((JValue)token).Value;

}

if (token is JObject) {

ExpandoObject expando = new ExpandoObject();

(from childToken in ((JToken)token) where childToken is JProperty select childToken as JProperty).ToList().ForEach(property => {

((IDictionary<string, object>)expando).Add(property.Name, ConvertJTokenToObject(property.Value));

});

return expando;

}

if(token is JArray){

object[] array = new object[((JArray)token).Count];

int index = 0;

foreach (JToken arrayItem in ((JArray)token)) {

array[index] = ConvertJTokenToObject(arrayItem);

index++;

}

return array;

}

throw new ArgumentException(string.Format("Unknown token type '{0}'", token.GetType()), "token");

}

Unit Testing Visual Studio DSL Tools

2009-09-15T01:18:17Z

I’ve been meaning to post this entry for a while now so while I wait for a 2010 beta install to complete….

For a long time I thought it wasn’t possible to unit test DSL Tools projects easily. Due to the nature of the environment it is sometimes difficult to see how unit testing is possible. The model elements are put in a partition in a store and all the partial classes, rules etc are very tightly coupled.

It wasn’t until I wanted to write a use-case oriented management layer on top of our multiple DSLs that I first thought of how it was possible. I wanted to a find way to test that the abstracted co-ordination methods on the management layer would create the expected model elements and what I got was an accidental pattern for testing DSL tools.

The main trick lies in creating a model context that will hold your store, model root and handle transactions.

The ModelingTestContext class:

public class ModelingTestContext : IDisposable {
    private Transaction tx;
    private Store store;
    public ModelingTestContext() {
        store = new Store();
 
        Type domainModelType = typeof(MyCompany.DomainModelDslDomainModel);
 
        // Create a new store to deserialize the instance to. 
 
        Type[] metaTypes = new Type[]
                               {
                                   typeof (CoreDesignSurfaceDomainModel),
                                   domainModelType 
                               };
        // Load these types into the store, so that it knows about them for deserialization 
        store.LoadDomainModels(metaTypes);
 
        tx = store.TransactionManager.BeginTransaction("Domain Modeling Test Context");
        domainModelRoot = new MyModelRoot(store);
    }
 
 
    public MyModelRoot DomainModelRoot {
        get { return domainModelRoot; }
    }
 
    public Store Store {
        get { return store; }
    }
 
    public void CommitChanges() {
        tx.Commit();
        tx = store.TransactionManager.BeginTransaction("Domain Modeling Test Context");
    }
 
    public void Dispose() {
        if(tx != null && tx.IsActive) {
            tx.Rollback();
        }
    }
}

This class will create the model root inside the store and manage transactions for us. We next need to start writing a test.

[TestMethod]
public void CreateAssociationSingleMultiplicity() {
    using (ModelingTestContext domainContext = new ModelingTestContext()) {
        domainContext.DomainModelRoot.Namespace = "Aderant.Test.DomainFoo";
 
        DomainComponent clientDc = domainContext.CreateDomainComponent("Client");
 
        DomainComponent addressDc = domainContext.CreateDomainComponent("Address");
 
        AssociationLink link = clientDc.AssociateWith(addressDc, Multiplicity.One);
 
 
        domainContext.CommitChanges();
        Assert.AreEqual(addressDc.Name, link.TargetRoleName);
 
    }
}

We create a context inside a using block so that we can clean up the transaction when the test completes. In this test I have added extension methods to the domain context and the DomainComponent class to support the common scenarios I used in testing like CreateDomainComponent and AssociationWith, allowing me to encapsulate common behavior. These extension methods can then be moved to become behavior of the model or the management API. Therefore over time you provide better API functionality which is tested.

Now some people would call this integration testing instead of unit testing…..fair enough. Also some would say that the extension methods and the test context for that matter are making the tests brittle as DRY does not apply to unit testing, I would disagree as otherwise these tests would become unmanageable.

I hope you find this useful.

Pete