Welcome to Windows Workflow Foundation (WF)
Top Tasks :

WF Community Bloggers

Browse by Tags

All Tags » .NET » DevCenter   (RSS)

  • Changing a Declarative Rule Condition at runtime

    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:

    image

     

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

    image

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

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

    Enjoy!

     

    www.TheProblemSolver.nl
    Wiki.WindowsWorkflowFoundation.eu

  • Using an IronPython runtime service from Windows Workflow Foundation

    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.

    image

    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

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

    Read more about this here.

     

    Enjoy!

     

    www.TheProblemSolver.nl
    Wiki.WindowsWorkflowFoundation.eu

  • Book review: Pro WF by Bruce Bukovics

    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.

  • Visual Studio 2008 Service Pack 1 available

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

     

    Get it while it is hot Smile

     

    Enjoy!

  • More on using a TransactionScopeActivity within a ReceiveActivity

    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.

     

    image

     

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

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

     

    Enjoy your workflow transactions!

  • SQL Server Compact 3.5 SP1 released

    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

    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:

    image

    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:

    image

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

  • CodeCamp 2008

    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 Server Compact Workflow Persistence Service updated

    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

    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 Sad

    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

  • Changing the ActivityDesignerTheme on an activity

    Using an ActivityDesignerTheme is a quick way to customize the appearance of an activity in the workflow designer. But there is a gotcha Sad Because once you applied the theme and have a workflow with the custom activity open in the designer no matter what you do changes will not be applied.

    I am not sure why this is but I suppose the designer caches the color scheme and doesn't see any changes made to it.

    Take the following activity:

    using System;
    using System.ComponentModel;
    using System.Drawing;
    using System.Workflow.ComponentModel;
    using System.Workflow.ComponentModel.Design;
    using System.Drawing.Drawing2D;
    
    namespace WorkflowConsoleApplication4
    {
        [Designer(typeof(MyActivity1ActivityDesigner))]
        public partial class MyActivity: Activity
        {
        }
    
    
        [ActivityDesignerTheme(typeof(MyActivity1ActivityDesignerTheme))]
        public class MyActivity1ActivityDesigner: ActivityDesigner
        {
        }
    
        public class MyActivity1ActivityDesignerTheme : ActivityDesignerTheme
        {
            /// <summary>
            /// Initializes a new instance of the MyActivity1ActivityDesignerTheme class.
            /// </summary>
            public MyActivity1ActivityDesignerTheme(WorkflowTheme theme)
                : base(theme)
            {
                BackColorStart = Color.LightBlue;
                BackColorEnd = Color.Blue;
                BackgroundStyle = LinearGradientMode.ForwardDiagonal;
            }
        }
    }
    

    Which look like this in the designer

    image

    Clearly the background has a blue gradient. Now if I change the theme code to the following:

    public class MyActivity1ActivityDesignerTheme : ActivityDesignerTheme
    {
        /// <summary>
        /// Initializes a new instance of the MyActivity1ActivityDesignerTheme class.
        /// </summary>
        public MyActivity1ActivityDesignerTheme(WorkflowTheme theme)
            : base(theme)
        {
            BackColorStart = Color.LightCyan;
            BackColorEnd = Color.Cyan;
            BackgroundStyle = LinearGradientMode.ForwardDiagonal;
        }
    }
    

    You might expect the activity to change its look to:

    image

    Unfortunately this doesn't happen Sad

    Now you can quit Visual Studio and restart it after which the new style will take affect but there is a quicker way. Right click the activity and select "Select Custom Theme..."

    image

    When the dialog shows just click OK and the designer reads the theme again Smile

     

    image

    Enjoy!

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

  • Using multiple SetState activities in a StateMachineWorkflow

    When working with state machine workflow's the SetStateActivity is one of the more important activities to use. The main reason is that is the one used to transition from one state to another. You can actually transition state in a different way as well using the StateMachineWorkflowInstance.SetState() function but the SetStateActivity is by far the most often used.

    One of the cool features of the SetStateActivity that may not be immediately obvious is the fact that it doesn't do the state switch immediately. Instead it saved the new target start in an internal property, named NextStateName on the StateMachineExecutionState type to be exact, and only does the state switch when the current EventDrivenActivity or StateInitializationActivity is finished. And just to be clear those are the only two activities where you can use a SetStateActivity.

    image

    So the cool part is that you don't need to have the SetStateActivity right at the bottom of the EventDrivenActivity but it can be anywhere in the execution flow. Something that might make the execution logic quite a bit easier.

    image

    And the second cool behavior is that you can actually execute multiple SetStateActivity objects with different TargetStateName definitions and only the last one will be executed. Again something that might make the logic quite a bit simple as you can set a default TargetStateName at the beginning of your and make changes to the target as exceptional cases arise.

    Both of these behaviors are especially important as the TargetStateName is a meta property, meaning it cannot be changed at runtime but only at design time. So the option of dynamically changing the SetStateActivity doesn't really exist.

    Enjoy!

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

  • Unit testing custom workflow activities

    Most people consider unit testing of custom workflow activities to pretty much impossible. Sure you can create a dummy test workflow containing your new activity, new up a WorkflowRuntime, create a WorkflowInstance and start it. But just think about all the dependencies here with the extra dummy workflow and the complete WorkflowRuntime with all its dependencies. Hardly a unit test for an activity but more like an integration test. Now there is nothing wrong with integration tests, they are very useful and necessary, but they do not give the speedy and dynamic test coverage you expect and need from a unit test.

    So is this really the case?

    Lets look at a few simple examples. This first example is really simple, in fact simple enough to say unrealistic but lets take a look anyway:

    public partial class WriteLineActivity1 : Activity
    {
        public WriteLineActivity1()
        {
            InitializeComponent();
        }
    
        public string Message { get; set; }
    
        protected override ActivityExecutionStatus Execute(
            ActivityExecutionContext executionContext)
        {
            if (!string.IsNullOrEmpty(Message))
                Console.WriteLine(Message);
    
            return ActivityExecutionStatus.Closed;
        }
    }
    

    This can easily be tested with a unit test like this.

    /// <summary>
    ///A test for Execute
    ///</summary>
    [TestMethod()]
    [DeploymentItem("WFUnitTest1.exe")]
    public void ExecuteTest()
    {
        WriteLineActivity1_Accessor target = 
            new WriteLineActivity1_Accessor();
        ActivityExecutionContext executionContext = null; 
        ActivityExecutionStatus expected = ActivityExecutionStatus.Closed;
        ActivityExecutionStatus actual;
        
        actual = target.Execute(executionContext);
    
        Assert.AreEqual(expected, actual);
    }
    

    So that at least proves some activities can be unit tested Smile

     

    But admittedly this is an oversimplification. In a more realistic activity the actual Console.WriteLine(), or whatever the activity needs done, would be implemented in a workflow runtime service so its implementation can be changed independently of the workflow. And that means using the ActivityExecutionContext to retrieve a reference to the service.

    Now this is where most people stop because the ActivityExecutionContext is a sealed type and sealed types cannot be mocked! But that isn't quite true because TypeMock can mock just about anything!

    So lets take look at slightly more realistic sample.

    public partial class WriteLineActivity2: Activity
    {
        public WriteLineActivity2()
        {
            InitializeComponent();
        }
    
        public string Message { get; set; }
    
        protected override ActivityExecutionStatus Execute(
            ActivityExecutionContext executionContext)
        {
            if (!string.IsNullOrEmpty(Message))
            {
                WriteLineService2 service = 
                    executionContext.GetService<WriteLineService2>();
    
                service.WriteLine(Message);
            }
    
            return ActivityExecutionStatus.Closed;
        }
    }
    

    This activity does the same job as the first one but delegates the actual work to this, simple, runtime service:

    public class WriteLineService2
    {
    
        public void WriteLine(string message)
        {
            Console.WriteLine(message);
        }
    }
    

    So lets create a few unit tests for this activity. The first test checks the behavior when the message is empty:

    /// <summary>
    ///A test for Execute
    ///</summary>
    [TestMethod()]
    [DeploymentItem("WFUnitTest1.exe")]
    [VerifyMocks()]
    public void ExecuteTestNoMessage()
    {
        WriteLineActivity2_Accessor target = new WriteLineActivity2_Accessor();
        ActivityExecutionContext executionContext = null; 
        ActivityExecutionStatus expected = ActivityExecutionStatus.Closed;
        ActivityExecutionStatus actual;
    
        actual = target.Execute(executionContext);
    
        Assert.AreEqual(expected, actual);
    }
    

    Still pretty simple because there is no interaction between the activity and the ActivityExecutionContext. But what happens the message is filled?

    /// <summary>
    ///A test for Execute
    ///</summary>
    [TestMethod()]
    [DeploymentItem("WFUnitTest1.exe")]
    [VerifyMocks()]
    public void ExecuteTestWithMessage()
    {
        WriteLineActivity2_Accessor target = new WriteLineActivity2_Accessor();
        ActivityExecutionStatus expected = ActivityExecutionStatus.Closed;
        ActivityExecutionStatus actual;
    
        ActivityExecutionContext executionContext = 
            RecorderManager.CreateMockedObject<ActivityExecutionContext>();
        WriteLineService2 service = 
            RecorderManager.CreateMockedObject<WriteLineService2>();
    
        using (RecordExpectations recorder = RecorderManager.StartRecording())
        {
            // Record methods here
            service.WriteLine(null);
    
            executionContext.GetService<WriteLineService2>();
            recorder.Return(service);
        }
    
        target.Message = "A message";
        actual = target.Execute(executionContext);
    
        Assert.AreEqual(expected, actual);
    }
    

    In this case we are mocking the ActivityExecutionContext using the RecorderManager.CreateMockedObject<ActivityExecutionContext>() statement. And this mock ActivityExecutionContext returns a mock WriteLineService2 when asked, pretty cool right? Big Smile

    Now I won't claim to know every mocking framework out there but as far as I know TypeMock is the only one that can to this and create proper unit test for a custom workflow activity.

    Enjoy!

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

  • Validating workflow activities at runtime

    As I mentioned in my previous blog post adding a custom ActivityValidator class to an activity validates it at runtime as well as at design time.

    So when is this runtime validation done and what happens when it fails?

    The when part is when the WorkflowInstance object is first created using one of the overloads of the WorkflowRuntime CreateWorkflow function. This means that the activity cannot really validate all properties as they are when it starts executing. After all when it depends on some data provided by another activity it needs to wait until this other activity has executed. And that will not happen at the CreateWorkflow moment but after it is started. So only use it to validate properties that need to be set at compile time. So what is the point of checking at runtime? Well suppose your existing activity changed and has extra requirements. The existing workflow's may not be recompiled so the first opportunity is to detect the error at runtime.

     

    image

     

    So what happens when the workflow is loaded and the runtime validation fails?

    In that case an exception of type WorkflowValidationFailedException is raised. The Errors collection contains all validation errors in the form of ValidationError objects. Check the ErrorText property so see what is wrong.

    Enjoy!

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

More Posts Next page »

<September 2008>
SuMoTuWeThFrSa
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us