Search results for 'app:weblogs' matching tag 'WF4'

Workflow 4 and Visual Basic expressions

Maurice — Mon, 26 Oct 2009 05:00:00 GMT

When using Windows Workflow Foundation 4 you often need to enter expression in some activity property. The new thing is these expressions are all in the Visual Basic dialect regardless of what language you project is in. So when developing a project in C# the expressions are sill in Visual Basic.

Weird right?

Well not really when you think about it!

After all power business users are expected to be able to modify workflows. And guess what their favorite tools are. That would be Microsoft Excel and Word. And what do they use to create macros? Right Visual Basic for Applications is their language of choice.

So if they use VBA letting them enter VB into expression dialogs is a far more natural fit than having them use C#.

A case for the Delay activity

So lets take a look at the delay activity. This activity takes 1 input property Duration of type Time Span. So I guess that means our VBA power users are going to have to enter something like if they want to wait 5 seconds:

Now for some reason I suspect that is not the first thing they are going to type. In fact they are more likely to time something like “0:0:05” instead. Not very VB like right?

Well it turns out workflow is smart enough to realize it can convert the string literal to a Time Span and use this. So when our power users does the following it just works

Nice, I like this!

Enjoy WF4!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Workflow parameters in Window Workflow Foundation 4

Maurice — Fri, 23 Oct 2009 05:00:00 GMT

Creating parameters for a workflow is quite easy to do in WF 4. Just open the arguments tab in the workflow and add each input or output parameter you need and the required type.

Now in WF 3 passing data to a workflow was done using a Dictionary<string, object> to specify the input. This is very flexible but also very brittle as it is all magic of key names matching property names. This approach still works as the following code demonstrates.

var input = new Dictionary<string, object>();

input["FirstName"] = "Maurice";

input["LastName"] = "de Beijer";

var result = WorkflowInvoker.Invoke(new Workflow1(), input);

Console.WriteLine(result["Greeting"]);

However WF4 has a new approach that includes full type safety. Every time you create an in or out argument the workflow will also get a corresponding public property. These properties are of type InArgument<T> but they contain an implicit cast from T so the code is quite easy as shown below.

var workflow = new Workflow1();

workflow.FirstName = "Maurice";

workflow.LastName = "de Beijer";

var result = WorkflowInvoker.Invoke(workflow);

Console.WriteLine(result["Greeting"]);

Much cleaner!

Unfortunately the OutArgument Greeting is there but printing it’s contents to the console only results in the type being printed. There is also a Get() method but this requires an ActivityContext to be passed. So in the case of output we are still restricted to using the Dictionary<string, object>.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

WF4&WCF and message correlation

Maurice — Wed, 02 Sep 2009 05:00:00 GMT

In the previous blog posts, here, here and here, I demonstrated how to use WCF from WF4. This same some more about sending multiple messages to the same workflow, AKA Workflow Correlation.

One of the ugly parts of Windows Workflow Foundation 3 was the message correlation part when you used WCF to send multiple messages to the same workflow.

When using WF3 you where forced to use one of the context bindings like BasicHttpContextBinding or WSHttpContextBinding. Not only that but you also had to retrieve and set the correlation context using the IContextManager and set it to some arcane guid. This guid was the workflow instance ID but having to use that on the client means the client had to be very aware of the server technology used, something that goes against the principals of WCF. Using something in the message itself as to route the message to the correct workflow was just not possible with the build-in activities.

Fortunately the WF4 story is much better. No longer do we need to use the “context” bindings but the standard WCF bindings will do just fine. And the client doesn’t have to work with the workflow instance id but can pass some more logical data, like an invoice number, that will be mapped to the correct workflow. Much better!

To demonstrate this we first need to expand the workflow so it can receive multiple messages for the same workflow. The input for both Receive activities will still be the same person class from the previous example and we will use the persons ID to route the messages.

The new workflow definition looks like this:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    var input = new Variable<Person>();

    result.Variables.Add(input);

    XNamespace ns = "http://tempuri.org";

    var handle1 = new Variable<CorrelationHandle>();

    result.Variables.Add(handle1);

    var handle2 = new Variable<CorrelationHandle>();

    result.Variables.Add(handle2);

    var receive1 = new Receive()

        OperationName = "Operation1",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle1)}

},

        CorrelationQuery = CreateCorrelationQuery(),

        CanCreateInstance = true

};

    result.Activities.Add(receive1);

    var write1 = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write1);

    var reply1 = new SendReply()

        Request = receive1,

        Value = new InArgument<string>("The result")

};

    result.Activities.Add(reply1);

    var receive2 = new Receive()

        OperationName = "Operation2",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle2)}

},

        CorrelationQuery = CreateCorrelationQuery()

};

    result.Activities.Add(receive2);

    var write2 = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called again with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write2);

    var reply2 = new SendReply()

        Request = receive2,

        Value = new InArgument<string>("The second result")

};

    result.Activities.Add(reply2);

    return result;

This is very similar to the previous workflow except we have two Receive activities and only the first is configured to allow the message to create a new instance.

The trick in getting the second message routed to the same workflow is by setting the CorrelationQuery on the two Receive activities. This is done in the CreateCorrelationQuery() function as follows:

private static CorrelationQuery CreateCorrelationQuery()

    var result = new CorrelationQuery();

    var xpath = new XPathMessageQuery()

        Namespaces = new XmlNamespaceManager(new NameTable()),

        Expression = "//sample:Person/sample:Id"

};

    xpath.Namespaces.AddNamespace("sample", "urn:WF4Sample:person");

    var messageQuerySet = new MessageQuerySet()

        Name = "RequestCorrelation"

};

    messageQuerySet.Add("PersonId", xpath);

    result.Select = messageQuerySet;

    return result;

The important part here is that the MessageQuerySet key value and the related Expression XPath must produce the same result for both request. Something that is easy here as I am sending in the same person object twice.

So the regular client has hardly any changes. All that is needed is the addition of the second operation to the ServiceContract like this:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Person request);

    [OperationContract]

    Operation1Response Operation2(Person request);

And calling the second operation like this.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Person()

        Id = 23,

        FirstName = "Joe",

        LastName = "Regular",

        BirthDate = new DateTime(1975, 7, 1)

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    //request.Id = 99;

    request.FirstName = "Maurice";

    request.LastName = "Chevalier";

    request.BirthDate = new DateTime(1888, 9, 12);

    result = proxy.Operation2(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

Note that I cam completely free to change the person object as long as I use the same Id. Should I change the Id the WorkflowServiceHost would try and find an existing workflow with the changed person Id, fail and throw a FaultException with message “The requested operation could not complete because instance key '4d7e998a-4cff-4743-3dd4-2afd5578383c' could not be found.”. Not quite sure where the Guid comes from but there is no workflow with that instanceId.

The good thing here is that the client doesn’t need to be aware of the workflow implementation on the server and the server can use “regular” message data to determine the correct workflow to send the message to.

The Workflow client has about the same change. In this case the Send activity is duplicated but other that that there is very little change and certainly no code that makes the client workflow aware of the service workflow.

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    XNamespace ns = "http://tempuri.org";

    var endpoint = new Endpoint()

        Uri = new Uri("http://localhost:8090/Sequence1/Operation1"),

        Binding = new BasicHttpBinding()

};

    var response = new Variable<string>();

    result.Variables.Add(response);

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var person = new Person()

        Id = 7,

        FirstName = "Maurice",

        LastName = "de Beijer",

        BirthDate = new DateTime(1962, 8, 24)

};

    var request = new Send()

        OperationName = "Operation1",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request);

    var reply = new ReceiveReply()

        Request = request,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply);

    var write = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write);

    var delay = new Delay()

        Duration = TimeSpan.FromSeconds(5)

};

    result.Activities.Add(delay);

    var request2 = new Send()

        OperationName = "Operation2",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request2);

    var reply2 = new ReceiveReply()

        Request = request2,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply2);

    var write2 = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write2);

    return result;

Conclusion.

The WF3/WCF marriage in Wf3.5 left quite a bit to be desired and fortunately live has become a lot simpler with WF4.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Sending your own objects to a WF4 workflow

Maurice — Thu, 20 Aug 2009 05:00:00 GMT

In the previous two blog posts (here and here) I showed how to create and expose a Windows Workflow Foundation 4 workflow via WCF and have both a workflow and a regular C# client work with it. But the parameter and return value where real simple with just a string each. So how about passing some more complex data.

To show how to do so I will replace the singe string with a person object. Admittedly not the most complex person with only an id, first and last name and their birth date but enough to demonstrate the principal.

The main of the service, which uses a WorkflowServiceHost, stays exactly the same so see the first blog post for that part. The CreateWorkflow() function will change now reflecting the fact that the service will no longer expect a string but a person object.

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    var input = new Variable<Person>();

    result.Variables.Add(input);

    XNamespace ns = "http://tempuri.org";

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var receive = new Receive()

        OperationName = "Operation1",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        CanCreateInstance = true

};

    result.Activities.Add(receive);

    var write = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write);

    var reply = new SendReply()

        Request = receive,

        Value = new InArgument<string>("The result")

};

    result.Activities.Add(reply);

    return result;

Not a big change really as we only have to change the input variable from Variable<string> to Variable<Person> and do the same with the Value property of the Receive activity which goes from new OutArgument<string>(input) to new OutArgument<Person>(input).

That leaves the Person class and this is just straightforward WCF work by turning the basic class into a data contract.

[DataContract(Namespace = "urn:WF4Sample:person")]

public class Person

    [DataMember]

    public int Id { get; set; }

    [DataMember]

    public string FirstName { get; set; }

    [DataMember]

    public string LastName { get; set; }

    [DataMember]

    public DateTime BirthDate { get; set; }

    public override string ToString()

        return string.Format("{0} {1} was born on {2} (ID: {3})", FirstName, LastName, BirthDate, Id);

Again no big deal

So with the service done we need to make the same changes to the two client applications. First the workflow client using the Send activity.

The Person class is exactly the same as on the server so just copy the code as is. Again the main in the workflow client doesn’t change, see the first blog post for that part. The part that does change a little is the CreateWorkflow() function so it creates and sends a Person instead of a string. The code goes as follows:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    XNamespace ns = "http://tempuri.org";

    var endpoint = new Endpoint()

        Uri = new Uri("http://localhost:8090/Sequence1/Operation1"),

        Binding = new BasicHttpBinding()

};

    var response = new Variable<string>();

    result.Variables.Add(response);

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var person = new Person()

        Id = 7,

        FirstName = "Maurice",

        LastName = "de Beijer",

        BirthDate = new DateTime(1962, 8, 24)

};

    var request = new Send()

        OperationName = "Operation1",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request);

    var reply = new ReceiveReply()

        Request = request,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply);

    var write = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write);

    return result;

Again a very minor change.

So how about the C# console client from the second blog post?

The service contract changes a little and is now:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Person request);

The person class is very different from the service though and looks like this:

[MessageContract(WrapperNamespace = "urn:WF4Sample:person")]

internal class Person

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public int Id { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public string FirstName { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public string LastName { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public DateTime BirthDate { get; set; }

But besides the difference from using a message contract as opposed to a data contract this isn’t a big deal.

The main program changes a bit but not a whole lot. Again the only changes are due to the fact we are passing in a Person instead of a string.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Person()

        Id = 23,

        FirstName = "Joe",

        LastName = "Regular",

        BirthDate = new DateTime(1975, 7, 1)

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

All together not bad.

But so far we have only used a very simple workflow with a single message send to it. Suppose you want to send multiple messages to the same workflow? Well in that case we need to use message correlation as we will see next time.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Using Windows Workflow Foundation 4 Receive from an non WF client

Maurice — Wed, 19 Aug 2009 05:00:00 GMT

In a previous blog post I described how to use the WorkflowServiceHost and host a workflow with a Receive activity that waits for WCF messages. I also added a WF4 client that called the service and received a response. However a lot of clients out there are not going to be workflows but “regular” code that calls into out workflow. So what does it take to have a simple console application talk to our WF4 service?

The first thing we need is an service contract describing the operation we can call. In our workflow the operation is named “Operation1” and our service contact name was “MyService” with the default namespace of “http://tempuri.org”. So our service contract looks like this:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Operation1Request request);

Next up are the request and response objects. In this case I am using just two strings so they are pretty simple as well.

[MessageContract(IsWrapped = false)]

public class Operation1Request

    [MessageBodyMember(

        Namespace = "http://schemas.microsoft.com/2003/10/Serialization/",

        Name = "string")]

    public string Value { get; set; }

[MessageContract(IsWrapped = false)]

public class Operation1Response

    [MessageBodyMember(

        Namespace = "http://schemas.microsoft.com/2003/10/Serialization/",

        Name = "string")]

    public string Value { get; set; }

The interesting to note here is that I have to use a MessageContact instead of a DataContract and I have to make sure the data isn’t wrapped in an extra element. Also interesting is the fact that the data is send across using the name “string”, not the easiest C# identifier to work with so I called them “Value” instead.

Using these WCF definitions creating a simple console app that calls the workflow is a breeze.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Operation1Request()

        Value = "Test from a console."

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Combining WCF and WF4

Maurice — Wed, 05 Aug 2009 05:00:00 GMT

There are several ways to use WCF in combination with Windows Workflow Foundation 4. The two can be combined inside of a XAMLX file as Ron Jacobs describes here.

Another option is using the WF4 Receive and SendReply activities and hosting the workflow yourself using a WorkflowServiceHost. This is quite a useful option but, at least at the moment, not quite straightforward. When I was trying to get things working using a declarative workflow and the designer Visual Studio 2010 would keep in locking up so all workflows in this example will be coded using C#. Not quite the way things are supposed to be done but it does give some useful insight.

Creating a workflow to handle requests

The basic activity we need on the service side is the Receive activity. This allows us to wait for incoming requests and process them, either by using a new workflow or an existing one. If we want to send a response we need to use a SendReply activity as well, if not we are creating a one way contract.

Note that there is not going to be a formal contract as we normally have in WCF. Instead we configure the Receive and SendReply and a contract is derived from that. Not quite sure if I like that as a service contract is supposed to be very much locked down.

The code for the service workflow looks like this:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    var input = new Variable<string>();

    result.Variables.Add(input);

    XNamespace ns = "http://tempuri.org";

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var receive = new Receive()

        OperationName = "Operation1",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<string>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        CanCreateInstance = true

};

    result.Activities.Add(receive);

    var write = new WriteLine()

        Text = new InArgument<string>(env => string.Format("The workflow was called with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write);

    var reply = new SendReply()

        Request = receive,

        Value = new InArgument<string>("The result")

};

    result.Activities.Add(reply);

    return result;

For the most part quite straightforward. We receive a message as defined by the Receive activity Value property, in this case just a string. The message is printed and we return another string through the Value property of the SendReply. Using C# code really shows where we need to use arguments and variables, something that is somewhat hidden when using XAML.

One thing I don’t like is having to create and add the CorrelationHandle. It might be needed internally but I don’t really want to be bothered. Setting the Request property on the SendReply to hook the two together should be enough. Lets hope this disappears before WF4 ships.

Hosting the service workflow

With the service workflow in place we need to create a WorkflowServiceHost and actually make the workflow available. The WorkflowServiceHost is configured using a Service definition which in turn contains a WorkflowServiceImplementation containing the actual workflow and a WCF endpoint. The hosting code looks like this:

XNamespace ns = "http://tempuri.org";

var service = new Service();

service.Implementation = new WorkflowServiceImplementation()

    Name = ns + "MyService",

    Body = CreateWorkflow()

};

service.Endpoints.Add(new Endpoint()

    Uri = new Uri("Operation1", UriKind.Relative),

    Binding = new BasicHttpBinding(),

    ServiceContractName = ns + "MyService"

});

var host = new WorkflowServiceHost(

    service,

    new Uri("http://localhost:8090/Sequence1"));

host.Open();

Console.WriteLine("Press enter to stop");

Console.ReadLine();

host.Close();

The main point here is making sure the Name and ServiceContractName, both for the Endpoint and Receive, are configured correctly or the WorkflowServiceHost will not be able to start and you will get a System.InvalidOperationException with a message something like “Cannot add endpoint because ContractDescription with Name='MyService' and Namespace='http://tempuri.org' can not be found.”.

Creating a calling workflow

With the service side in place we now need to create a client workflow to call into our service. In this case the main activity to use is the Send which sends the request to the WCF service and the ReceiveReply which waits for the response to arrive. The whole is very similar to the service workflow and again we need to use the annoying CorrelationHandle. The workflow code looks like this:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    XNamespace ns = "http://tempuri.org";

    var endpoint = new Endpoint()

        Uri = new Uri("http://localhost:8090/Sequence1/Operation1"),

        Binding = new BasicHttpBinding()

};

    var response = new Variable<string>();

    result.Variables.Add(response);

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var request = new Send()

        OperationName = "Operation1",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<string>("Test")

};

    result.Activities.Add(request);

    var reply = new ReceiveReply()

        Request = request,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply);

    var write = new WriteLine()

        Text=new InArgument<string>(response)

};

    result.Activities.Add(write);

    return result;

Just like any other WCF service the main point is to make sure that the service contract names, namespaces and data types match or message will not be processed correctly (or at all). Running this workflow has no special hosting requirements so using the WorkflowInvoker will do just fine.

var workflow = CreateWorkflow();

WorkflowInvoker.Invoke(workflow);

Console.WriteLine("Client Done.");

Console.ReadLine();

Conclusion

Using WCF and WF4 together is not hard. Unfortunately the designer seems to be letting me down but fortunately everything we can do using the designer can also be done using code.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Data and Windows Workflow Foundation 4

Maurice — Mon, 20 Jul 2009 05:00:00 GMT

One thing that has completely changed in Windows Workflow Foundation is the way we work with data in a workflow. In WF 3 we used properties to store data. We could use regular .NET properties but most of the time dependency properties where the smarter choice. Dependency properties left the way data was stored to be handled by the workflow runtime but in our program we could use them just like any other property. And the big bonus was we could use property binding to tie different properties on different activities together in any way we saw fit. These dependency properties where much like the dependency properties found in WPF although there was no common base class or interface used.

In WF 4 this has all changed!

We are no longer using properties to store data. Most of the time we will need to use variables, represented by types deriving from Variable, or arguments, types deriving from Argument, to work with data. These arguments and variables don’t actually store the data, they just describe the data and let you get at it. The actual data is stored somewhere inside of the workflow using a LocationEnvironment. To store some data inside of your workflow we need to add a Variable to the workflow or one of the nested activities. The basic rule is to move it as close as possible to the activities that need it at a place there all activities that need access to the data can find the value in the path to the root activity.

The root path is a big difference from WF3 where any activity could get to any other piece of data anywhere in the workflow. This makes for some hard to maintain workflows and means that persistence always has to store everything. With the new model you are much restricted in where you can store data but it makes for a much cleaner, and therefore faster, persistence model.

Take the following class:

public class Customer

    public Customer(string name, CreditRating creditRating)

        Name = name;

        CreditRating = creditRating;

    public string Name { get; set; }

    public CreditRating CreditRating { get; set; }

public enum CreditRating

    Good,

    Average,

    Poor

Now I want to create a workflow that prints the customer with its credit rating, updates the credit rating and prints the data gain. Not very complex but enough to display the steps.

The workflow looks like this:

Because all three activities need to use the same customer object we need to store it at a shared parent. In this case the workflow is very simple and the shared parent is the root Sequence itself.

Adding new variable is done using the variables menu at the left bottom of the designer.

The Name is used throughout the workflow to store and retrieve the data. The Default can be left empty but in this case I create a new Customer object my entering the following expression:

New WorkflowConsoleApplication4.Customer("Maurice", WorkflowConsoleApplication4.CreditRating.Average)

Selecting the data type is done using the .NET type selector dialog shown below. Personally I find the type selector not the easiest to work with but it gets the job done.

The text to print in the WriteLine activities is quite straightforward and you get full IntelliSense, even on our own types. The same is true for the Assign activity.

String.Format("Customer '{0}' has a credit rating of {1}.", theCustomer.Name, theCustomer.CreditRating)

Not bad and easy enough to do.

Creating the workflow using code

Every workflow you create using the designer you can also create using code so what would this same workflow look like when done using pure code?

var theCustomer = new Variable<Customer>()

    Default = new Customer("Maurice de Beijer", CreditRating.Average)

};

var result = new Sequence();

result.Variables.Add(theCustomer);

result.Activities.Add(new WriteLine()

    Text = new InArgument<string>(env => string.Format("Customer '{0}' has a credit rating of {1}.",

        theCustomer.Get(env).Name,

        theCustomer.Get(env).CreditRating))

});

result.Activities.Add(new Assign<CreditRating>()

    To = new OutArgument<CreditRating>(env => theCustomer.Get(env).CreditRating),

    Value = CreditRating.Good

});

result.Activities.Add(new WriteLine()

    Text = new InArgument<string>(env => string.Format("Customer '{0}' has a credit rating of {1}.",

        theCustomer.Get(env).Name,

        theCustomer.Get(env).CreditRating))

});

The same WriteLine activity with the simple String.Format() expression now looks quite a bit different. And not different in a good sort of way

Instead of using “theCustomer.Name” as we could in the designer now we have to use the expression “theCustomer.Get(env).Name” and instead of just typing the complete expression we have to wrap it in an InArgument<string>. Not very pretty but it does show is what is going on under the covers so lets take a closer look.

The WriteLine activity needs something to print and this is input for the activity as it never modifies it. So we need to use an InArgument. In the case of the Assign activity it needs change some data so it needs to use an OutArgument. The third option, not used here, is an InOutArgument which lets an activity read and modify some data.

The InArgument has several constructors, in the case I am using one that takes an expression with a LocationEnvironment which we can use to retrieve the actual customer object.

So where is this customer stored?

Just like in the designer we need to create a variable. This is done at the top using this code:

var result = new Sequence();

var theCustomer = new Variable<Customer>()

    Default = new Customer("Maurice de Beijer", CreditRating.Average)

};

result.Variables.Add(theCustomer);

So all in all this is very different in WF4 as compared to WF3. The code use to create a workflow doesn’t look very pretty, but then again the code use to create and link dependency properties didn’t either. Fortunately the designer hides most of the complexity for us by just letting us enter the expression we want and not bother us with the way data is actually handled inside of a workflow.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

More asynchronous work in Windows Workflow Foundation 4

Maurice — Wed, 15 Jul 2009 05:00:00 GMT

In my previous post I showed how to use an AsyncOperationBlock to do some basic asynchronous work in WF 4. As I mentioned this was for relatively short lived asynchronous operations as the workflow could not be persisted and unloaded while this asynchronous work was executing.

So how about real long running work, the kind you run into with real business application like waiting for an invoice to be paid?

With these king of jobs an AsyncOperationBlock will not work because you don’t want to keep the workflow in memory all the time.

So what do we need to use here?

Well the basic building block is called a Bookmark.

A bookmark is just a way of saying to the workflow: give a pointer to where you are and I will tell you later to resume from this pointer.

Creating a bookmark is easy. In the execute method of our activity we call the CreateNamedBookmark() function of the ActivityExecutionContext passed to us with the name of the bookmark. The bookmark name is no longer an IComparable but just a regular string.

Whenever we are done with our job we can use the WorkflowInstance to call ResumeBookmark() passing in the name of the bookmark and some data. The activity will be signaled as closed and we are ready to go.

One big difference is the activity base class. In the previous sample I was using the CodeActivity as the baseclass for my custom activity while in this case I am using the more powerful NativeActivity<T>.

A word of warning here, these are the names in WF4 Beta 1 and they are likely to change before WF4 is release!

So what does my activity look like?

class AsyncWorker : NativeActivity<String>

    protected override void Execute(ActivityExecutionContext context)

        Console.WriteLine("CreateNamedBookmark on thread\t{0}", Thread.CurrentThread.ManagedThreadId);

        context.CreateNamedBookmark("bm");

It prints a bit of status info and most importantly it creates a new named bookmark called “bm”.

The main program looks like this:

var workflow = CreateWorkflow();

var instance = new WorkflowInstance(workflow);

instance.OnIdle = () =>

    Console.WriteLine("Idle on thread\t\t\t{0}", Thread.CurrentThread.ManagedThreadId);

    return IdleAction.Nothing;

};

instance.OnCompleted = (e) => { Console.WriteLine("Completed on thread\t\t{0}", Thread.CurrentThread.ManagedThreadId); };

instance.Run();

Console.WriteLine("Sleep on thread\t\t\t{0}", Thread.CurrentThread.ManagedThreadId);

Thread.Sleep(1000);

Console.WriteLine("ResumeBookmark on thread\t{0}", Thread.CurrentThread.ManagedThreadId);

instance.ResumeBookmark("bm", null);

Console.WriteLine("Sleep on thread\t\t\t{0}", Thread.CurrentThread.ManagedThreadId);

Thread.Sleep(1000);

Console.WriteLine("Done on thread\t\t\t{0}", Thread.CurrentThread.ManagedThreadId);

Console.ReadLine();

If you strip out the printing of the status info you are basically left with:

var workflow = CreateWorkflow();

var instance = new WorkflowInstance(workflow);

instance.Run();

instance.ResumeBookmark("bm", null);

One interesting thing I noted is that is appears to be ok to resume a bookmark before it is created.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Basic asynchronous work in Windows Workflow Foundation 4

Maurice — Tue, 14 Jul 2009 05:00:00 GMT

The whole asynchronous execution model in WF 4 has changed quite a bit from WF 3. Not really a surprise as this one of the areas where WF 3 was really hard to work with.

Below is a very simple example. It does nothing useful, it’s only task is to show how to get started with asynchronous work in WF 4.

class AsyncWorker : CodeActivity

    protected override void Execute(CodeActivityContext context)

        var asyncContext = context.SetupAsyncOperationBlock();

        var task = new Task(DoAsyncWork, asyncContext);

        task.Start();

    private static void DoAsyncWork(object state)

        var asyncContext = (AsyncOperationContext)state;

        Console.WriteLine("Doing some work.");

        Thread.Sleep(5000);

        asyncContext.CompleteOperation((ctx, bm, s) => { }, null);

The important parts here are:

CodeActivityContext.SetupAsyncOperationBlock()
This basically tells the runtime that the activity is going to do something asynchronously and that the runtime should not continue with the next activity when the Execute() is finished. It also means that the workflow cannot be persisted until this operation is complete.
AsyncOperationContext.CompleteOperation()
This tells the workflow runtime that the operation is complete and that the next activity can be scheduled or the workflow may be persisted.

Because the workflow can’t be persisted this is designed for relatively short running operations. So something like saving some data via a WCF service. If you need the sort of asynchronous work where you might be waiting for day’s on an end user this is not the way to go. In that case you should be looking at bookmarks instead.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

What does Windows Workflow Foundation 4 mean for existing workflow developers?

Maurice — Fri, 03 Jul 2009 05:00:00 GMT

The question of what Windows Workflow Foundation version 4 means for developers currently developing using WF recently came up. As I mentioned before WF 4 is a complete rewrite and doesn’t use any of the existing WF 3 classes. The design of WF 4 is even quite different from the design of WF 3.

So are WF 3 developers completely left in the dark and have to start from scratch? And what about their existing applications, will they still run on .NET 4 or are they stuck in .NET 3.5 until the end of times?

Fist of all let me address why I believe Microsoft could make such a radical change. Keep i mind this is just my personal opinion and I might be completely wrong .

WF 3 was never widely adopted so I believe the team felt they could do this and not create to much of a problem. Personally I don't think the low adoption of WF 3 had anything to do with the technology. Sure it has its problems but most people never got to the point that they ran into real technical issues. Instead most people looked, didn't understand and quit. So IMHO the main problem was far more a question if evangelism that technology.

So what is the big issue with a migration from WF 3 to WF 4?

One big issue with WF 4 is that Microsoft decided not to release a state machine implementation. In WF 3 there was a choice between state machine and sequential workflows. In WF 4 there is a choice between sequential and flow chart. And in WF 3 a state machine turned out to be far more flexible and useful and quite a few cases are not really covered by the WF 4 model. There are a few workarounds to do something like a state machine in WF 4 but they are not pretty. That said, a number of state machine workflows could very well be done using a flow chart.

As far as backward compatibility the story is a bit more complicated. WF 4 ships with an interop activity you can use to host custom WF 3 activities in a WF 4 workflow. How good or bad this is? I really don't know yet but given how different the two are I fear it is very limited.

But WF 3 developers need not worry about their existing projects!

There is however a second side to the compatibility story. .NET 4 will ship both with the WF 3 and the WF 4 runtimes. The WF 3 runtime will not be prominent but it will still be there so all existing WF 3 applications will continue to run as is. And because it is part of the current .NET framework I suspect this is a legal requirement (but then I am no lawyer so could be wrong here). So there is no reason for your clients to panic just yet .

So existing workflow developers should start learning WF 4 for future projects but can continue to keep using their existing WF 3 solutions for the foreseeable future.

Enjoy!