The Problem Solver

Changing a Declarative Rule Condition at runtime

Maurice — Thu, 04 Sep 2008 19:27:39 GMT

One powerful feature of a workflow is that a workflow can be changed at runtime. Like other powerful features this is something that should be done with care but it can be a real life saver at times.

One of the things that you can change are Declarative Rule Conditions. However as these rules are really CodeDom objects it can be a bit tricky to find the right property to change. However once you know a little tick life is much easier.

The trick is in the .rules file created when you add a Declarative Rule Condition to the workflow and is best demonstrated using a small example. Take the following workflow:

The IfElseActivity has a Declarative Rule Condition which looks like this:

So I consider every amount larger that 100 large. Hmm not much, lets change that to 1000 instead of 100

The first step is we need to change the workflow instance so we need a WorkflowChanges object passing in the workflow root as the activity. No big deal but what now. Well lets open the Workflow1.Rules file and take a look at what is inside.

<RuleDefinitions xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
    <RuleDefinitions.Conditions>
        <RuleExpressionCondition Name="LargeAmountRule">
            <RuleExpressionCondition.Expression>
                <ns0:CodeBinaryOperatorExpression Operator="GreaterThan" xmlns:ns0="clr-namespace:System.CodeDom;Assembly=System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
                    <ns0:CodeBinaryOperatorExpression.Left>
                        <ns0:CodePropertyReferenceExpression PropertyName="Amount">
                            <ns0:CodePropertyReferenceExpression.TargetObject>
                                <ns0:CodeThisReferenceExpression />
                            </ns0:CodePropertyReferenceExpression.TargetObject>
                        </ns0:CodePropertyReferenceExpression>
                    </ns0:CodeBinaryOperatorExpression.Left>
                    <ns0:CodeBinaryOperatorExpression.Right>
                        <ns0:CodePrimitiveExpression>
                            <ns0:CodePrimitiveExpression.Value>
                                <ns1:Int32 xmlns:ns1="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">100</ns1:Int32>
                            </ns0:CodePrimitiveExpression.Value>
                        </ns0:CodePrimitiveExpression>
                    </ns0:CodeBinaryOperatorExpression.Right>
                </ns0:CodeBinaryOperatorExpression>
            </RuleExpressionCondition.Expression>
        </RuleExpressionCondition>
    </RuleDefinitions.Conditions>
</RuleDefinitions>

It turns out that the XML is a very literal representation of the objects that make up our rule and what we need to change. So we need to start with a RuleDefinitions.

RuleDefinitions rules =
    (RuleDefinitions)changes.TransientWorkflow.GetValue(RuleDefinitions.RuleDefinitionsProperty);

So getting our hand on it is easy, just use the GetValue function passing in the RuleDefinitionsProperty dependency property.

Once we have this things are even easier as it is just following the XML . It shows the RuleDefinitions object has a Conditions property and our rule is in there with a name LargeAmountRule and is of type RuleExpressionCondition. This rule in turn contains a left and right part with the right part pointing at the value of 100 we want to change. Again this value is of a type CodePrimitiveExpression, another easy cast. The code below is the complete code required to change the value from 100 to1000.

WorkflowChanges changes = new WorkflowChanges(this);

RuleDefinitions rules =
    (RuleDefinitions)changes.TransientWorkflow.GetValue(RuleDefinitions.RuleDefinitionsProperty);

RuleExpressionCondition rule = (RuleExpressionCondition)rules.Conditions
    .First(rc => rc.Name == "LargeAmountRule");
CodeBinaryOperatorExpression expression = (CodeBinaryOperatorExpression)rule.Expression;
CodePrimitiveExpression primitive = (CodePrimitiveExpression)expression.Right;
primitive.Value = 1000;

ApplyWorkflowChanges(changes);

Easy once you know where to look

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Calling WCF services from a Silverlight 2 app.

Maurice — Mon, 25 Aug 2008 22:11:00 GMT

As far as I am concerned Silverlight 2 is pretty cool and should have been developed years ago . Well guess that isn't the case but it is here now.

One thing I like about Silverlight is how easy it is to call a web service. I guess that is a must be because when developing a LOB application in Silverlight you are going to be calling your server to get and store data. So calling the back end is as easy as adding a new Silverlight-enabled WCF Service, implementing the ServiceContract and setting a service reference from your Silverlight project. Things will work immediately and you are all good to go.

Or maybe not

Well your service will work just fine in your development machine, no problems there. But when you move your project to another machine thing might just stop working and you will see a ProtocolException with message "The remote server returned an unexpected response: (404) Not Found.".

So what gives?

Well the problem is that the WCF stores the absolute Uri for the WCF service in its configuration file, the ServiceReferences.ClientConfig. In this case the configuration looks like this:

<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_Service" maxBufferSize="65536"
                    maxReceivedMessageSize="65536">
                    <security mode="None" />
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:4370/SilverlightApplication3Web/Service.svc"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_Service"
                contract="SilverlightApplication3.ServiceReference1.Service"
                name="BasicHttpBinding_Service." />
        </client>
    </system.serviceModel>
</configuration>

The problem here is the endpoint address that points to localhost port 4370. So as this service is part of the same website using a relative Uri sounds like the reasonable thing to do. Unfortunately this doesn't work and results in an UriFormatException with message: "Invalid URI: The format of the URI could not be determined.". Not good. So this means we have to change the address for every local endpoint when we move the Silverlight application, and its WCF services, to a different location. Not good, specially when we could have a long list of services used .

A partial solution

So fortunately there is a way around this as we can specify the service address when creating the WCF service proxy, all we need to do is insert the correct Uri based upon the location of the Silverlight application.

Normally the code I write looks something like this:

ServiceClient proxy = new ServiceClient();
proxy.DoWorkCompleted += proxy_DoWorkCompleted;
proxy.DoWorkAsync();

What I need to do is change this somewhat so that the ServiceClient is created through a factory method like this:

ServiceClient proxy = GetServiceClient();
proxy.DoWorkCompleted += proxy_DoWorkCompleted;
proxy.DoWorkAsync();

The interesting work occurs in the GetServiceClient() function:

private ServiceClient GetServiceClient()
{
    Uri uri = new Uri(HtmlPage.Document.DocumentUri, "Service.svc");
    EndpointAddress address = new EndpointAddress(uri);

    return new ServiceClient("*", address);
}

First I determine where the Silverlight application was loaded from in the first place through the HtmlPage.Document.DocumentUri. Next I create a new Uri with the relative address where the service should be located. And finally I create and return the WCF proxy object. The first parameter, the "*" indicated that the WCF runtime should use a wildcard match and the first endpoint found with the same contract, which is the same as when no parameters are passed in.

A better solution

Of course the solution above works but requires extra coding and care with every service we create. And being easy to forget, specially when you just get started with Silverlight, is not exactly an ideal solution. So the proper solution is that the WCF stack inside of Silverlight should accept relative Uri and understand that this Uri is relative to the current page. Now this is not exactly rocket science and exactly what browsers have been doing for years. So lets hope the Silverlight team adds this feature before the RTM (which I hope is real soon).

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Using an IronPython runtime service from Windows Workflow Foundation

Maurice — Mon, 25 Aug 2008 10:15:18 GMT

In this post I demonstrated how to create IronPython objects and call them from strongly typed .NET code. So suppose we want to do so with Windows Workflow Foundation where could we use this?

Well the most obvious place would be a runtime service. The example below uses a very simple message that needs to be displayed but it is easy to see how to same concept could be applied in other places.

But first the basics. I have created a very simple custom DisplayMessageActivity like this:

public partial class DisplayMessageActivity : System.Workflow.ComponentModel.Activity
{
    public DisplayMessageActivity()
    {
    }

    public string Message { get; set; }

    protected override ActivityExecutionStatus Execute(
        ActivityExecutionContext executionContext)
    {
        IDisplayMessageService service = executionContext.GetService<IDisplayMessageService>();
        service.Display(Message);

        return base.Execute(executionContext);
    }
}

Next I have created a very simple workflow with only the DisplayMessageActivity and set the Message property to: "This is the message to show.".

You might have noticed in the code above that I am looking for a service of type IDisplayMessageService. This is pretty simple as well and looks like this:

public interface IDisplayMessageService
{
    void Display(string message);
}

In this case I am using an interface but you could just as well use a concrete baseclass with virtual methods.

For the actual implementation I created two classes in IronPython, the first displays the message on the console while the second uses a MessageBox to display the same message. The IronPython source looks like this:

import clr

clr.AddReference('PythonWorkflowConsoleApplication1')
from PythonWorkflowConsoleApplication1 import IDisplayMessageService

clr.AddReference("System.Windows.Forms")
from System.Windows.Forms import MessageBox

# Display all messages in the console window
class ConsoleDisplayMessageService(IDisplayMessageService):
    def Display(self, message):
        print message

# Display all messages using a Windows.Forms.MessageBox
class MessageBoxDisplayMessageService(IDisplayMessageService):
    def Display(self, message):
        MessageBox.Show(message, 'IronPython')

Like in the previous example I first import the clr so I can set references to additional assemblies. Next add a reference to the PythonWorkflowConsoleApplication1 assembly. This is my sample application that contains the runtime service interface definition. With this reference set I can import the IDisplayMessageService interface so I can derive from it.

I included two implementations, lets first look at the ConsoleDisplayMessageService as this is the simpler of the two. All this does is use the Python print function to display the message on the console. The first parameter, self, is the current object, so this in C# or me in VB. We make sure this class derives from IDisplayMessageService by specifying this after the class name. BTW the lines starting with # are comments in Python.

The second class is MessageBoxDisplayMessageService and this actually uses a MessageBox to display the message from the workflow. First we need to add a reference to the System.Windows.Forms assembly and once that is done we need to import the MessageBox type. Once this is done we can use it like this:
MessageBox.Show(message, 'IronPython')

Simple enough right.

So now for the trick part, adding the IronPython runtime service to the workflow runtime.

The console main function is as follows:

static void Main(string[] args)
{
    using (WorkflowRuntime workflowRuntime = new WorkflowRuntime())
    {
        AddMessageService(workflowRuntime, DisplayMode.Windows);

        WorkflowInstance instance = workflowRuntime.CreateWorkflow(
            typeof(PythonWorkflowConsoleApplication1.Workflow1));
        instance.Start();

        Console.ReadLine();
    }
}

With the AddMessageService() doing the actual work. Note the second parameter specifies which IronPython class to load.

So the AddMessageService looks like this:

static void AddMessageService(WorkflowRuntime workflowRuntime, DisplayMode mode)
{
    string className;
    if (mode == DisplayMode.Console)
        className = "ConsoleDisplayMessageService";
    else
        className = "MessageBoxDisplayMessageService";

    ScriptRuntime runtime = PythonEngine.CurrentEngine.Runtime;
    ScriptScope scope = runtime.ExecuteFile("DisplayMessageService.py");

    PythonType pythonType = scope.GetVariable<PythonType>(className);
    object service = runtime.Operations.Call(pythonType);

    workflowRuntime.AddService(service);
}

The basics are the same as in my previous IronPython post. Depending on the display mode I make a choice of class to load and I use the same code as previous time to create the object. Finally I add it to the WorkflowRuntime as a runtime service. This last bit is easy as this accepts every object type as a valid service and only when we call the GetService do we check the actual type.

I used IronPython 2.0 Beta 4 for this example. More info about IronPython can be found here, the download of version 2 here.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Red Gate to continue development of .NET Reflector

Maurice — Wed, 20 Aug 2008 07:04:54 GMT

.NET Reflector, by Lutz Roeder, must be one of the most useful tools I have when developing .NET code. Usually it is the first thing I install right after Visual Studio not even waiting until I need it because I know I will.

So the big news is that Red Gate, makers of the Ants profiler and lots of other tools, are taking over from Lutz Roeder and will continue developing .NET Reflector. Interesting move and I hope this means a bright future for the .NET Reflector.

Two useful batch files when testing with Windows Workflow Foundation

Maurice — Tue, 19 Aug 2008 14:21:48 GMT

The following are two batch files I use a lot when working with WF persistence and or tracking as I find it desirable to clear the out often. Just drop them in the "C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\EN" directory with the four SQL scripts and recreating the required databases is just a few clicks away.

CreatePersistence.bat

osql -E -S .\sqlexpress -Q "Drop Database WorkflowPersistence"
osql -E -S .\sqlexpress -Q "Create Database WorkflowPersistence"
osql -E -S .\sqlexpress -d WorkflowPersistence -i SqlPersistenceService_Schema.sql
osql -E -S .\sqlexpress -d WorkflowPersistence -i SqlPersistenceService_Logic.sql

CreateTracking.bat

osql -E -S .\sqlexpress -Q "Drop Database WorkflowTracking"
osql -E -S .\sqlexpress -Q "Create Database WorkflowTracking"
osql -E -S .\sqlexpress -d WorkflowTracking -i Tracking_Schema.sql
osql -E -S .\sqlexpress -d WorkflowTracking -i Tracking_Logic.sql

Of course you could also use my SqlCeWFPersistence as the persistence service, download it from here. I never did create a TrackingService based upon SQL Compact but if enough people are interested I might just do so

Enjoy!

www.TheProblemSolver.nl
Wiki.windowsworkflowfoundation.eu

.NET Framework 3.5 Enhancements Training Kit

Maurice — Tue, 19 Aug 2008 10:32:52 GMT

Want to know what is new in the .NET 3.5 SP1 framework or Visual Studio 2008 SP1? Then check out the presentations and labs here: http://www.microsoft.com/downloads/details.aspx?FamilyID=355C80E9-FDE0-4812-98B5-8A03F5874E96&displaylang=en

Overview

The .NET Framework 3.5 Enhancements Training Kit includes presentations, hands-on labs, demos, and event materials. This content is designed to help you learn how to utilize the .NET 3.5 Enhancement features including: ASP.NET MVC, ASP.NET Dynamic Data, ASP.NET AJAX History, ASP.NET Routing, ADO.NET Data Services, ADO.NET Entity Framework, WCF 3.5 SP1, and the .NET Framework Client Profile.

Now this is nowhere near complete but a good place to start.

Enjoy!

Calling IronPython functions from .NET

Maurice — Thu, 14 Aug 2008 18:17:19 GMT

Having worked with Python in the past I find IronPython an interesting language to work with. However the story becomes really interesting if you can combine IronPython with regular strong typed code into one.

So I decided to take a look at what it would take to do so with the current IronPython version. I used IronPython 2 Beta 3, based upon the current version of the Dynamic Language Runtime, which is still evolving so the classes might have changed, take care! You can download the latest IronPython release here.

Lets take a look at what it takes to use an IronPython class from a Visual Basic Project.

The first thing we need is a base class we are actually going to derive from. This is because IronPython doesn't compile its code into a static type but VB requires its variables to be typed. This is the base class I am using:

Public Class HelloWorldVB
    Public Overridable Function HelloWorld(ByVal name As String) As String
        Return String.Format("Hello '{0}' from Visual Basic", name)
    End Function
End Class

And a main module to start thing off:

Sub Main()

    Dim helloWorld As New HelloWorldVB()
    Console.WriteLine(helloWorld.HelloWorld("Maurice"))

    Console.ReadLine()
End Sub

No big surprise here .

So how do we derive an IronPython class from our VB type?

The following code is the IronPython code I added to the file HelloWorld.py.

import clr
clr.AddReference('IronPythonTest2')
from IronPythonTest2 import HelloWorldVB

class HelloWorldIronPython(HelloWorldVB):
    def HelloWorld(self, name):
        return "Hello '" + name + "' from IronPython"

Basically this code adds a reference to the IronPythonTest2 assembly, this is my console application containing the previous VB code. Next it imports the HelloWorldVB type from the assembly. Now it know about the type we can go ahead and derive from that type and create a new one. This exactly what the line class HelloWorldIronPython(HelloWorldVB) does, it creates a new type called HelloWorldIronPython. Next we override the HelloWorld function and return a different welcome string. A few things to note here: Python uses indentation to specify blocks, so the function being indented from the class is a part of that and the line of code with the return is indented from the def that defines the function so it is part of the function body. Another interesting thing is the self parameter. Every function in Python is passed a reference to itself as the first parameter. Sort of like the implicit Me in VB except a bit more obvious.

If you want to know more about IronPython I suggest you get the book IronPython in Action from Michael Foord.

To make sure the HelloWorld.py file is available to the console application I have set the Copy to Output Directory to Copy always.

OK so far so good. We have an IronPython class with the code we need. Now we still need to create an object from it. This isn't hard it just takes a bit more doing than just using the New operator.

Instantiating the IronPython object

The first step is adding the required references. We need to add the following assemblies:

IronPython.dll
IronPython.Modules.dll
Microsoft.Scripting.dll
Microsoft.Scripting.Core.dll

We will only be using the 1st and 3rd ourselves but the others are needed as well.

Once we have the references set we can add the required Imports:

Imports Microsoft.Scripting.Hosting
Imports IronPython.Hosting
Imports IronPython.Runtime.Types

And now we can get really going with the code

We need to load the file with the Python source code using an IronPython ScriptRuntime. Once done we can get a reference to the IronPython type object using the GetVariable() function by passing in the class name. Once we have that we call the ScriptRuntime again to actually create the object. See the code below:

Dim runtime As ScriptRuntime = PythonEngine.CurrentEngine.Runtime
Dim scope As ScriptScope = runtime.ExecuteFile("HelloWorld.py")
Dim pythonType As PythonType = scope.GetVariable(Of PythonType)("HelloWorldIronPython")
helloWorld = CType(runtime.Operations.Call(pythonType), HelloWorldVB)
Console.WriteLine(helloWorld.HelloWorld("Maurice"))

And with this code we are good to go. Running the complete code will show the output below:

The complete code in the main module:

Option Explicit On
Option Strict On

Imports Microsoft.Scripting.Hosting
Imports IronPython.Hosting
Imports IronPython.Runtime.Types

Module Module1
    Sub Main()
        Dim helloWorld As New HelloWorldVB()
        Console.WriteLine(helloWorld.HelloWorld("Maurice"))

        Dim runtime As ScriptRuntime = PythonEngine.CurrentEngine.Runtime
        Dim scope As ScriptScope = runtime.ExecuteFile("HelloWorld.py")
        Dim pythonType As PythonType = scope.GetVariable(Of PythonType)("HelloWorldIronPython")
        helloWorld = CType(runtime.Operations.Call(pythonType), HelloWorldVB)
        Console.WriteLine(helloWorld.HelloWorld("Maurice"))

        Console.ReadLine()
    End Sub
End Module

Enjoy!

Book review: Pro WF by Bruce Bukovics

Maurice — Wed, 13 Aug 2008 19:16:24 GMT

Windows Workflow Foundation, WF for short, is one of the technologies I work a lot with and as a consequence I own several books about WF. Comparing this book with the others I can only say it is one of the best books you can get on the subject. It has a good coverage of almost all the subject you are going to need to know. Not only is there a good coverage but the explanation and examples are very clear. Now there are a few thing missing from the book. As it was written with the .NET framework 3.0 there is no coverage of the WCF integration that comes in the form of the SendActivity and the ReceiveActivity. While this is unfortunate it is also understandable and I can only hope that the author has the time to update the book with one more chapter.

For a book this size, about 700 pages, I was amazed at how little I could find that I didn't like. In fact one of few errors I could find is the statement that only a single instance of the WorkflowRuntime can be created per AppDomain. This is a myth that stems back to the first beta's where it was briefly the case but the restriction has been lifted long ago and has never been part of the released product. But given the size of the book and how few people ever need to create multiple WorkflowRuntime objects it is hardly a big objection.

So my advise: If you are getting into Windows Workflow Foundation make sure you buy this book!

Enjoy.

Using a TransactionScopeActivity within a ReceiveActivity in a state machine workflow

Maurice — Wed, 13 Aug 2008 10:31:45 GMT

In two previous blog posts, part one and part two, I covered the fact that the ReceiveActivity and the TransactionScopeActivity don't work together very well. I demonstrated this using a sequential workflow and did show a, clumsy and hacky, workaround to get at least the initial request working. So while the request that starts the sequential workflow could work the same is not true for any subsequent calls.

But what about a state workflow?

State workflow's are very different then sequential workflow's because they are completely event driven. With every state you need to add an EventDrivenActivity and the first child should implement the IEventActivity interface. Well the ReceiveActivity does just that so we can use it to initiate a state machine workflow and triggers its events. However as you might expect a TransactionScopeActivity is not an IEventActivity so it cannot be the first child of the EventDrivenActivity. And that means you cannot wrap the ReceiveActivity inside of an TransactionScopeActivity, something that sort of solved the problem with a sequential workflow. Of course nesting the TransactionScopeActivity inside of the ReceiveActivity won't work either for the reasons described in the first two post. So far so bad

So we need another workaround

Again there is no real good workaround . In fact the only one I can come up with is stop using the TransactionScopeActivity all together. So how to do transactions without using the TransactionScopeActivity?

Well the solution, ahem workaround, is to use the WorkflowEnvironment.WorkBatch object and add all pending work to it. The first parameter is an object of type IPendingWork and this is the one that is actually going to be called to do the work. The second parameter, the workItem, contains the data. Now when a workflow per persistence point is reached the IPendingWork object is called to do its work.

[Serializable()]
class Workflow1PendingWork : IPendingWork
{
    #region IPendingWork Members

    public void Commit(Transaction transaction, ICollection items)
    {
        foreach (var Workflow1PendingWork in items)
        {
            using (TransactionScope tx = new TransactionScope(transaction))
            {
                // Do my own transaction work
                tx.Complete();
            }
        }
    }

    public void Complete(bool succeeded, ICollection items)
    {
    }

    public bool MustCommit(ICollection items)
    {
        /// We want to commit!
        return true;
    }

    #endregion
}

The MustCommit function is called to check if the Commit needs to be called. The Commit itself is called as part of the workflow persistence point. Now you can use something like a CodeActivity and add your workItem to the batch like this:

WorkflowEnvironment.WorkBatch.Add(_pendingWork, myTransactionData);

When do we reach a persistence point?

This leaves us with the question of when these persistence point occur. The best way to think if these is when a workflow reaches a state that is final, no matter what happens. This includes the point where a workflow is done and when it is persisted to the persistence store. Using the SqlWorkflowPersistenceService with the PersistOnIdle option set to true will mean this will happen as soon as the event handler is done executing and the workflow is idle. However sometimes that just isn't good enough and you need to do so sooner. Well the easiest way is to create a custom activity, I call it the PersistStateActivity, and decorate it with the PersistOnClose attribute. No need to add any code, all we are interested in is the attribute.

[PersistOnClose()]
public partial class PersistStateActivity : Activity
{
    public PersistStateActivity()
    {
    }
}

Now drop the activity at any point where you want your transactional data to be committed and the workflow runtime will take care of things for you

Conclusion

Although these workarounds are possible they are all but intuitive and it took quite a bit of digging around and brainstorming with some people to get this to work. So be very careful when using the TransactionScopeActivity, or any form of transactions for that matter, and the WCF ReceiveActivity!

Enjoy!

Visual Studio 2008 Service Pack 1 available

Maurice — Mon, 11 Aug 2008 15:33:33 GMT

It is available from the subscriptions download at http://msdn.microsoft.com/en-us/subscriptions/default.aspx

Get it while it is hot

Enjoy!

More on using a TransactionScopeActivity within a ReceiveActivity

Maurice — Fri, 08 Aug 2008 12:01:09 GMT

In a previous blog post I write about what happens when you place a TransactionScopeActivity within a ReceiveActivity and an exception occurs that is supposed to roll back the transaction. In short the story was very bad and we could come up with only a partial workaround, not a pretty sight.

But there is more to it than just that little horror story. Suppose you do the obvious and place the a TransactionScopeActivity within a ReceiveActivity and no exception occurs. Say like the workflow below, please note that the codeActivity1 only sets the return value and causes no error.

Now the transaction is committed and the WCF call returns perfectly normally so everything is good right. Well not quite

The obvious first point is that the TransactionScopeActivity serves no real purpose. After all if it isn't allowed to fail under any circumstances why bother with it in the first place. Well ok there is the point of doing several updates as a single transaction so other users cannot see a partially committed order but that is about it.

But that is actually the least of my worries as there is a far bigger issue to worry about and that is called workflow persistence.

Yes that is right. After all when we are using a TransactionScopeActivity workflow persistence is mandatory. The TransactionScopeActivity is decorated with the PersistOnClose attribute so the state of the workflow will be persisted as soon as the transaction is complete. And normally that is a good thing but in this case it is the cause of the second problem because this is still inside the ReceiveActivity. So basically we are storing the workflow state as it is just before returning an answer to the client. Now if everything is running fine that won't matter because the workflow will continue until it is finished and everyone is happy. But suppose the workflow host terminates before the workflow is finished? In this test I added the DelayActivity, and set UnloadOnIdle to false so it doesn't persist the state, giving me the opportunity to kill the workflow runtime. Now if I restart the runtime It is going to reload the last state of the workflow and continue from there. And guess what it's going to do first? You guessed it: it is going to send the response to the client for a second time. Of course the client is no longer around and that action fails with an InvalidOperationException with message "Workflow unloaded between request & response."

I guess the message is not entirely correct as it should say "Workflow reloaded between request & response." but it's close enough.

The bottom line is the workflow terminates unless you specifically allow for this to happen and catch the error.

So basically we have a choice between putting the TransactionScopeActivity inside a ReceiveActivity, not being able to throw an error and having a restore problem, or putting the TransactionScopeActivity around the ReceiveActivity, something that only works with a sequential workflow and an initiating ReceiveActivity as I described in the previous post.

I guess these options make me pretty unhappy .

Enjoy your workflow transactions!

SQL Server Compact 3.5 SP1 released

Maurice — Thu, 07 Aug 2008 07:47:58 GMT

Steve Lasker just announced that SQL Server Compact 3.5 service pack 1 is released, read his announcement here.

They added support for the entity framework, great stuff. And another neat feature is native 64 bits support. No longer do you need to target X86 and use WoW [:0]. Great if you are using my SQL Server Compact Workflow Persistence Service.

Enjoy!

Using a TransactionScopeActivity with a WCF ReceiveActivity

Maurice — Wed, 06 Aug 2008 08:10:20 GMT

I got an email from a friend last week asking about using a ReceiveActivity and, while receiving, using a TransactionScopeActivity to transitionally save some data in a database. Seems like a common enough scenario right? Well he was having some problems. If everything worked and the transaction succeeded everything was fine and the answer came back. But if an exception occurred and the transaction was aborted be was receiving a real weird error:

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Workflow service unexpectedly unloaded from memory while executing a ReceiveActivity. Make sure that the the workflow does not contain any blocking activities within a ReceiveActivity. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.InvalidOperationException: Workflow service unexpectedly unloaded from memory while executing a ReceiveActivity. Make sure that the the workflow does not contain any blocking activities within a ReceiveActivity.).

If we where to believe the message there was a blocking call, something there most certainly was not!

And to make things more confusing, if we removed the TransactionScopeActivity and just let the exception occur it would bubble back to the client just as it was supposed to. So what gives?

Well a lot of people looked at this and in the end we declared this a pretty bad bug. Mind you our words not those from Microsoft. But we did find a workaround. So lets take a look at a repro and how to fix this. My original test workflow looked like this:

I receive a WCF request, start a transaction, determine the return value in a code activity, throw an exception and return. Seems reasonable right? Well I thought so but it produces the error claiming there is a blocking statement. While tracking this Marvin actually noticed that the workflow idle event was raised! Excuse me, a workflow is becoming idle to undo a transaction sounds kind of wrong. And of course when a TransactionScopeActivity is used in a regular workflow, ie non WCF call, there is no Idle event.

A partial solution

So the way to get this to work is create the following workflow:

So instead of creating a TransactionScopeActivity inside of my ReceiveActivity I am doing it the other way round. Sounds kind of weird right? Well I think so but it does do the right thing as it returns the correct fault information to the client and then undoes any transactional work done.

So why does this workaround work in this case?

The ReceiveActivity has its CanCreateInstance property set to true so this is the request that actually creates and starts the workflow. This means that the workflow is created and starts executing from the top. Yes that is right, it starts from the top, not from the ReceiveActivity so any activities before that are also executed. I suppose that potentially opens a can of worms but we will leave that be for the moment. In this case the WCF request is received, this starts the workflow, this in turn starts the transaction, the message is received and processed and the transaction either commits or, like in this case, rolls back.

How about a non creating ReceiveActivity?

Well I am afraid no luck there as this workaround isn't going to work then. The problem is that we start a transaction before we start waiting for the additional WCF calls and the TransactionScopeActivity has a a TimoutDuration. So in all likelihood the transaction timeout will occur before the message is received and this effectively cancels the ReceiveActivity meaning it cannot receive the message.

I think this is a pretty major problem with the way WF and WCF work together. After all transactions a an essential piece of business applications and not being able to use them inside of a WCF request is a deadly sin.

Enjoy with care

CodeCamp 2008

Maurice — Sat, 02 Aug 2008 08:39:22 GMT

Afgelopen jaar hebben we het eerste CodeCamp in Nederland georganiseerd en dat was een groot succes. De meeste deelnemers vroegen om meer, sommige zelfs om een CodeCamp per kwartaal of een heel weekend lang. Nou hebben we dat laatste nog niet gedaan maar we zijn wel aan de slag gegaan om een nieuw CodeCamp te organiseren. Als datum hebben we zaterdag 6 september gekozen. Gelukkig waren Microsoft en Class-a behulpzaam en kunnen we, net als vorig jaar, weer in het Microsoft Innovation Center in Barneveld terecht. Een mooie datum en locatie om uitgerust van de vakantie een hoop kennis uit te wisselen.

Het programma staat nog niet helemaal vast, hou daar de website voor in de gaten, maar je kan er ondermeer de bekende Nederlandse sprekers verwachten. Uiteraard kan je zelf ook nog een sessie voorstellen dus als je een idee hebt voor een leuke sessie laat het dan zo snel mogelijk weten.

Dus zet de datum vast in je agenda en meld je zo snel mogelijk aan op de website www.code-camp.nl.

Het CodeCamp is een gezamenlijk initiatief van de SDN, de stichting DotNed en VB Central.

SQL Compact 3.5 on a 64 bit Windows

Maurice — Mon, 28 Jul 2008 19:48:36 GMT

SQL Compact is a great little database and highly recommended. However it was designed for use on small compact, hence its name, devices and that has some drawbacks. One of these is that it doesn't run as a 64 bits application. And by default if you create a .NET application it is compile as "Any CPU" meaning it will run as a 64 bits application on a 64 bits version of Windows.

I, or I should say Ron Jacobs, ran into that using my SqlCeWorkflowPersistenceService because the sample/test application was set to the default of "Any CPU". The result is that the LINQ provider cannot load the runtime and a InvalidOperationException with message "Cannot open 'WorkflowPersistenceDatabase.sdf'. Provider 'System.Data.SqlServerCe.3.5' not installed." is the result. Now the fix is rather easy but it has to be done in the main program and that is to compile it for X86 instead of Any CPU.

Do this and any application using SQL Compact 3.5 will happily run on Windows 64bit as a WOW Application.

Enjoy!

Launching of the Tegelberg

Maurice — Sun, 27 Jul 2008 11:48:57 GMT

Martine made this picture of me launching of the Tegelberg in Germany.

A great place to fly with a nice view of Neuschwanstein Castle. Below a picture I took while flying.

SQL Server Compact Workflow Persistence Service updated

Maurice — Mon, 21 Jul 2008 11:47:21 GMT

I have just updated the SQL Server Compact Workflow Persistence Service to better handle deserialization issues when loading a workflow. The service now makes sure the WorkflowRuntime ServicesExceptionNotHandled is raised, something it should have done in the first place.

You can download the SQL Server Compact Workflow Persistence Service from here.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

FaultHandlerActivity and workflow persistence

Maurice — Mon, 21 Jul 2008 10:11:17 GMT

I was just working on an issue reported against the SQL Server Compact Workflow Persistence Service I released some time ago. It turns that if you are using workflow persistence your workflow will actually be persisted to the store when an exception is caught. Now in itself not a big problem as your whole workflow needs to be serializable anyway. Except this time where is an additional exception object and when the exception itself cannot be serialized this brings the whole workflow down. In fact it brings more that just the workflow as the whole workflow runtime crashes, not good

The culprit in this case was a SqlCeException which is not serializable! Don't worry about the more common SqlException because that is perfectly ok.

Still something to double check as these exceptions are, by their very nature, the exceptional case and therefor less likely to be tested.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

Congratulations! You have received the Microsoft MVP Award

Maurice — Mon, 07 Jul 2008 14:54:59 GMT

While on holiday I received the MVP award for another year

Now that is always a nice email to come home to!

Thanks, I appreciate it!

Unit testing asynchronous workflow activities

Maurice — Wed, 11 Jun 2008 08:56:24 GMT

In a previous blog post I demonstrated how TypeMock allowed us to mock out the workflow runtime infrastructure and create true unit tests for a workflow activity. Now this may not seems like a big deal but because most of the classes in the workflow runtime are sealed mocking them with another mocking framework is pretty much impossible. Now you can test custom activities by wrapping them in a test workflow, creating a workflow runtime, running the workflow and inspecting the result I can hardly call this a unit test as we have to create lots of, complex, depended objects. So TypeMock really opens up some new possibilities here.

But the previous examples where still pretty simple, although mocking the ActivityExecutionContext has always been considered impossible, so lets try something more complicated in the shape of an asynchronous activity. Basically an asynchronous activity is an activity that returns ActivityExecutionStatus.Executing from the Execute method indicating to the workflow runtime that it isn't done yet. The activity uses ActivityExecutionContext at a later point in time to indicate that it is done by calling the CloseActivity function.

Lets take a quick look at our new activity.

public partial class WriteLineActivity3 : Activity
{
    public WriteLineActivity3()
    {
        InitializeComponent();
    }

    public string Message { get; set; }

    protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
    {
        ActivityExecutionStatus result = ActivityExecutionStatus.Closed;

        if (!string.IsNullOrEmpty(Message))
        {
            IComparable queueName = Guid.NewGuid();
            WorkflowQueuingService wqs = executionContext.GetService<WorkflowQueuingService>();
            WorkflowQueue queue = wqs.CreateWorkflowQueue(queueName, true);
            queue.QueueItemAvailable += new EventHandler<QueueEventArgs>(queue_QueueItemAvailable);


            WriteLineService3 service = executionContext.GetService<WriteLineService3>();

            service.WriteLine(Message, queueName);
            result = ActivityExecutionStatus.Executing;
        }

        return result;
    }

    void queue_QueueItemAvailable(object sender, QueueEventArgs e)
    {
        ActivityExecutionContext executionContext = sender as ActivityExecutionContext;
        executionContext.CloseActivity();
    }
}

In this case the return value from the Execute depends on the Message property being filled or not so we need to test this. First a simple test for an activity with an empty message:

/// <summary>
///A test for Execute
///</summary>
[TestMethod()]
[DeploymentItem("WFUnitTest1.exe")]
[VerifyMocks()]
public void ExecuteTestEmpty()
{
    WriteLineActivity3_Accessor target = new WriteLineActivity3_Accessor();
    ActivityExecutionStatus expected = ActivityExecutionStatus.Closed;
    ActivityExecutionStatus actual;

    ActivityExecutionContext executionContext = 
        RecorderManager.CreateMockedObject<ActivityExecutionContext>();
    WorkflowQueuingService wqs = RecorderManager.CreateMockedObject<WorkflowQueuingService>();
    WorkflowQueue queue = RecorderManager.CreateMockedObject<WorkflowQueue>();
    WriteLineService3 service = RecorderManager.CreateMockedObject<WriteLineService3>();

    using (RecordExpectations recorder = RecorderManager.StartRecording())
    {
        executionContext.GetService<WriteLineService3>();
        recorder.FailWhenCalled();
    }

    target.Message = "";
    actual = target.Execute(executionContext);

    Assert.AreEqual(expected, actual);
}

In this test I actually check that the runtime service, called WriteLineService3 in this case, is never retrieved. This test is still pretty simple and no more complicated than the test we did previously.

Lets take a look at something more complicated. The following test has the Message property set so it is expected to call the runtime service. But being an asynchronous activity it is also required to create a WorkflowQueue and bind to its QueueItemAvailable event so we will check that has happened. Finally this time the Execute function should return a status of ActivityExecutionStatus.Executing as it isn't done yet. This test runs like this:

/// <summary>
///A test for Execute
///</summary>
[TestMethod()]
[DeploymentItem("WFUnitTest1.exe")]
[VerifyMocks()]
public void ExecuteTestStart()
{
    WriteLineActivity3_Accessor target = new WriteLineActivity3_Accessor();
    ActivityExecutionStatus expected = ActivityExecutionStatus.Executing;
    ActivityExecutionStatus actual;


    ActivityExecutionContext executionContext = 
        RecorderManager.CreateMockedObject<ActivityExecutionContext>();
    WorkflowQueuingService wqs = RecorderManager.CreateMockedObject<WorkflowQueuingService>();
    WorkflowQueue queue = RecorderManager.CreateMockedObject<WorkflowQueue>();
    WriteLineService3 service = RecorderManager.CreateMockedObject<WriteLineService3>();

    using (RecordExpectations recorder = RecorderManager.StartRecording())
    {
        // Record methods here
        executionContext.GetService<WorkflowQueuingService>();
        recorder.Return(wqs);
        wqs.CreateWorkflowQueue(null, true);
        recorder.Return(queue);
        queue.QueueItemAvailable += delegate(object sender, QueueEventArgs e) { };

        executionContext.GetService<WriteLineService3>();
        recorder.Return(service);
        service.WriteLine(null, null);
    }

    target.Message = "A message";
    actual = target.Execute(executionContext);

    Assert.AreEqual(expected, actual);

A little more complicated than the previous check but not bad at all

In this case we are binding to the QueueItemAvailable event so we need to add another test for the event handler and make sure it informs the workflow runtime we are done.

/// <summary>
///A test for queue_QueueItemAvailable
///</summary>
[TestMethod()]
[DeploymentItem("WFUnitTest1.exe")]
[VerifyMocks()]
public void queue_QueueItemAvailableTest()
{
    WriteLineActivity3_Accessor target = new WriteLineActivity3_Accessor();
    QueueEventArgs e = null; // TODO: Initialize to an appropriate value

    ActivityExecutionContext executionContext = 
        RecorderManager.CreateMockedObject<ActivityExecutionContext>();

    using (RecordExpectations recorder = RecorderManager.StartRecording())
    {
        executionContext.CloseActivity();
    }

    target.queue_QueueItemAvailable(executionContext, e);
}

Not bad at all

That leaves us with writing a unit test for the runtime service itself. This runtime service actually looks like this:

public class WriteLineService3: WorkflowRuntimeService
{
    public void WriteLine(string message, IComparable queueName)
    {
        Guid instanceId = WorkflowEnvironment.WorkflowInstanceId;

        ThreadPool.QueueUserWorkItem(state => WriteLineAsync(message, instanceId, queueName));
    }

    private void WriteLineAsync(string message, Guid instanceId, IComparable queueName)
    {
        Thread.Sleep(TimeSpan.FromSeconds(5));

        Console.WriteLine(message);

        WorkflowInstance instance = GetWorkflow(instanceId);
        instance.EnqueueItem(queueName, null, null, null);
    }

    private WorkflowInstance GetWorkflow(Guid instanceId)
    {
        WorkflowInstance result = Runtime.GetWorkflow(instanceId);
        return result;
    }
}

Not very complicated or realistic for that matter but still lets write a quick unit test for it like this:

/// <summary>
///A test for WriteLine
///</summary>
[TestMethod()]
[VerifyMocks(10000)]
public void WriteLineTest()
{
    WriteLineService3_Accessor target = new WriteLineService3_Accessor(); 
    
    string message = string.Empty; // TODO: Initialize to an appropriate value
    IComparable queueName = null; // TODO: Initialize to an appropriate value

    WorkflowInstance instance = RecorderManager.CreateMockedObject<WorkflowInstance>();

    using (RecordExpectations recorder = RecorderManager.StartRecording())
    {
        Guid instanceId = WorkflowEnvironment.WorkflowInstanceId;
        recorder.Return(Guid.NewGuid());

        target.GetWorkflow(instanceId);
        recorder.Return(instance);
        instance.EnqueueItem(null, null, null, null);
    }

    target.WriteLine(message, queueName);

}

The most important thing here is that we can mock the WorkflowInstance object just as easy as the ActivityExecutionContext in the previous tests. I am actually telling TypeMock to wait for 10 seconds with the [VerifyMocks(10000)] attribute. This allows the delay in the service to remain there and still check if the expected response was queued. One thing to note is that I had to create an extra GetWorkflow() function to wrap the real function on the WorkflowRuntime object. I was unable to mock the latter however I am unsure why this is the case and if mocking it is really impossible.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu