WF Community Bloggers

Versioning long running workflows part 4

The Problem Solver : Workflow — Mon, 22 Sep 2008 12:23:06 GMT

Part 1 Part 2 Part 3 Part 4 In the previous blog posts we made sure we could have multiple versions of the same workflow running side by side. This ability is one of the more powerful concepts of WF and a real must have for long running business applications. A quick recap. Always version your assemblies by giving them a strong name. Make sure the runtime can find each version of the assembly by pointing the CLR to the right version using the configuration\runtimeassemblyBinding\dependentAssembly\assemblyIdentity\codeBase in your App.Config (or Web.Config in the case of a web application). And make sure you use all types and interfaces from the same version as the workflow or, somewhat easier, stick to using basic CLR types when sending messages. Great, but what about fixing bugs? All the versioning is very nice but the simple fact is that sooner or later you are going to find a bug in your code and need to fix a specific assembly. In that case it would not be very nice if the workflow would keep on running with the buggy code. No in that case you would very much like to be able to dehydrate the worfklows and have them use the patched version of the assembly instead of the original one. Fortunately this is easy to do, and again due to the standard binary serialization format Windows Workflow Foundation uses, completely standard .NET. Again the trick is versioning the assembly and using the App.Config to redirect the runtime to the correct version. So just as I demonstrated in...(read more)

Versioning long running workfows part 3

The Problem Solver : Workflow — Tue, 16 Sep 2008 14:29:07 GMT

Part 1 Part 2 In the first article of this series I demonstrated how to get multiple versions of a workflow running side by side in the same workflow runtime. The most important thing was that you need to keep every version of the assembly around and use the assemblyBinding element in the app.config to let the runtime know where each version was on disk. Once done life was good In the second part I demonstrated how a HandleExternalEventActivity was version dependent and you needed to use the version specific service to send a message to the workflow. It worked but the as the code was not exactly pretty life was just ok . What is wrong with the HandleExternalEventActivity? Well there is nothing really wrong with the HandleExternalEventActivity but it is a very thin layer over the actual workflow structures it tries to hide. And these structures are the workflow queuing mechanism! Internally everything is turned into a message and send through a queue. So if this is only a thin abstraction layer why not use the original API in the first place. That is exactly what I advise, leave the external data exchange mechanism for what it is and just create a custom workflow activity. What does it take to implement the same behavior using a custom activity? Not a whole lot actually so lets take a look. Above is the new workflow with the custom activity. Because the custom activity is used as the first child in one of the branches of a ListenActivity it must implement the IEventActivity interface...(read more)

A bit more about using TransactionScopeActivity within a ReceiveActivity

The Problem Solver : Workflow — Tue, 16 Sep 2008 10:06:01 GMT

You may recall my previous posts about using the TransactionScopeActivity within a ReceiveActivity and all the nasty issues we ran into. Just in case you want to read them again: one , two and three . As it turn out this is an intentionally not supported scenario at the moment. If we read the docs for the ReceiveActivity we can find the following note: To ensure that persistence performs properly and does not persist transient messages, make sure that child activities of the ReceiveActivity do not persist by themselves. This can occur if the child activities go idle when a persistence provider was created with UnloadOnIdle set to true, for instance. The note uses the UnloadOnIdle as an example but the persistence part is just as much true for the TransactionScopeActivity as this persists the state. Of course there is no similar warning in the TransactionScopeActivity docs and the activity validation fails to warn us either so there is definitely some room for improvement here. But rumor has it that this improvement is coming The rumor says that not only will we be able use a TransactionScopeActivity inside of a ReceiveActivity but we can even go a step further in being able to flow a transaction from the client through the WCF request into the workflow and have the TransactionScopeActivity participate in the same transaction. Nice but I guess we will have to wait for the PDC before we get all the details. Enjoy! www.TheProblemSolver.nl Wiki.WindowsWorkflowFoundation.eu Read More.....(read more)

RESTful.NET Fundamentals

Jon Flanders' Blog — Mon, 15 Sep 2008 18:58:20 GMT

Besides working on my RESTful.NET book, I'm also working with Aaron to build a course on REST and WCF for Pluralsight. We're excited that the course is now up and will have its first run in November (the 19th-21st to be exact) at the Microsoft MTC in Boston - so sign up today! Everyone who attends will get a copy of my new book as well, so come and learn about REST! Check out my new book on REST . Read More......(read more)

Versioning long running workflows part 2

The Problem Solver : Workflow — Thu, 11 Sep 2008 18:53:11 GMT

Part 1 Part 2 In my previous post I demonstrated how to keep multiple versions of an assembly around and how to use the assemblyBinding element in the app.config to let the runtime load multiple versions of a worklfow. In the end we had both workflows, the first in assembly 1.0.0.0 and the second in assembly 2.0.0.0, running and life seemed to be good So is there more to write on the subject? Yes unfortunately there are still some potential problems that need to be addressed . The pitfalls of External Data Exchange Lets take a look at what happens if we add a HandleExternalEventActivity to the mix. This HandleExternalEventActivity can be used to have a workflow react to input from an external data exchange service, sometimes called local communication. Lets change the workflow to reflect the following: In this workflow I am waiting for either a DelayActivity to fire or an event to be raised from an external service. Like before the activities are emended in a permanent loop so the workflow is never finished. I have kept the external data exchange service real simple. The interface looks like this: using System; using System.Workflow.Activities; namespace WorkflowLibrary1 { [ ExternalDataExchange ] public interface IMyService { event EventHandler < MyEventArgs > TheEvent; } } The implementation like this: using System; namespace WorkflowLibrary1 { public class MyService : IMyService { public event EventHandler < MyEventArgs > TheEvent; public void OnTheEvent( Guid instanceId)...(read more)

Versioning long running workfows

The Problem Solver : Workflow — Wed, 10 Sep 2008 10:46:03 GMT

One of the cool features of Windows Workflow Foundation is that it allows long running processes. And not just long running as in a few minutes but really long running as in a few years . This is possible true the use of the SqlWorkflowPersistenceService, or in fact any derived class from WorkflowPersistenceService, which is going to save the state of a workflow to disk when it is not actually busy. So that is pretty cool but it is kind of unlikely that your programs are not going to change over a year so in all likelihood you are going to be deploying newer versions of your assemblies while there are multiple workflow's active. In order to allow multiple versions of a workflow to run we need to understand what is going on under the covers. To demonstrate the behavior I am going to use a small project with the following layout. The WorkflowConsoleApplication1 is the host and is configured to use SqlWorkflowPersistenceService. The WorkflowLibrary1 is the project containing the actual workflow and this is the project we are going to version. The main program is pretty simple and looks like this: static void Main( string [] args) { using ( WorkflowRuntime workflowRuntime = new WorkflowRuntime ()) { string connStr = @"Data Source=.\sqlexpress;Initial Catalog=WorkflowPersistence;Integrated Security=True" ; SqlWorkflowPersistenceService persistence = new SqlWorkflowPersistenceService (connStr, true , TimeSpan .FromSeconds(15), TimeSpan .FromMinutes(1)); workflowRuntime.AddService(persistence);...(read more)

Stockholm BizTalk User Group - thanks guys!

Jon Flanders' Blog — Tue, 09 Sep 2008 00:18:54 GMT

I just got back from two weeks in Denmark and Sweden. Had a great time, met a number of really interesting and smart people and all my host's hospitality was just incredible! For those of you that came to the talk I did on REST at the Stockholm BizTalk User Group meeting - here is the code and the slides stockholmbtug.zip (796.71 KB) Also - I just have to say, this group is one of the best User Groups I've ever spoken at. From the travel to the talk itself it was a great experience. Thanks again! Check out my new book on REST . Read More......(read more)

Hi-REST , Lo-REST didn't we already decide this?

Jon Flanders' Blog — Sun, 07 Sep 2008 22:55:18 GMT

I've seen a number of posts, videos, and now a conference talk abstract talking about Lo-REST versus Hi-REST I thought this was already a closed issue See Dare's post There isn't anything that is "Lo-REST", there are services that follow the constraints of the REST architectural style, and those that don't (sometimes those that don't have a good reason not to) Some of this seems to revolve around some clients not supporting all verbs, this is easily fixed with the X-HTTP-Method-Override HTTP header My next post hopefully will show how easy this is to implement using WCF extensibility. Check out my new book on REST . Read More......(read more)

Changing a Declarative Rule Condition at runtime

The Problem Solver : Workflow — 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 "...(read more)

Using an IronPython runtime service from Windows Workflow Foundation

The Problem Solver : Workflow — 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...(read more)

Slides and Code from UserGroup meeting

Jon Flanders' Blog — Thu, 21 Aug 2008 17:36:31 GMT

Had a really fun time at the San Gabriel Valley .NET User Group meeting last night, great crowd for a Wed night in August! As I promised to them - here are the slides: rest1.pdf (666.35 KB) and the code: SGVNUG.zip (11.18 KB) Thanks again to everyone there - its always a fun group to speak at. Check out my new book on REST . Read More......(read more)

Red Gate to continue development of .NET Reflector

The Problem Solver : Workflow — 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. Read more about this here . Enjoy! www.TheProblemSolver.nl Wiki.WindowsWorkflowFoundation.eu Read More......(read more)

Explaining Roy Fielding's Dissertation to my Wife - Roy is to REST as Dizzy is to Bebop (theoretically)

Jon Flanders' Blog — Tue, 19 Aug 2008 20:08:46 GMT

My lovely wife Shannon is helping to do proof-reading on my book , and today she was working on the preface. One of the things I talk about in the preface is about Roy Fielding, and how his dissertation is really a named codification of the architecture of the Web She said to me "This really bugs me, why does someone get credit for just naming and distilling something that already exists" I replied with "Well - naming things is important and he was part of the effort to create the thing (the Web) so he should get some of the credit" She said "Hmm - I still don't get it, can you give me an example from outside of the world of technology" I said "Imagine when bebop was being created as a genre of music. Think about Dizzy Gillespie , imagine he wrote a paper in about 1950 describing bebop, how it worked, and what went into creating it, and how to tell bebop from other forms of jazz based on chord structures, etc." That made sense to her, so I thought I would blog about it. :-) Check out my BizTalk R2 Training . Read More......(read more)

REST posts

Jon Flanders' Blog — Sun, 17 Aug 2008 05:11:35 GMT

Now that I'm done with the major writing portion of my book , I'm going to try to post more. Many of my posts will be about the technical details of using REST and WCF (the main thrust of my book). I'm going to also start some linking to other blogs, which in the past I've kind of stayed away from. The purpose of these links will be to try to bring some of the ideas of REST that exist outside of windows and .NET developers, to the .NET developer's space. The post I am linking to today is by Steve Vinoski . Steve is a pretty interesting person, having worked at a company that built RPC systems for many years, he is now building software for a company (I think we still don't know what the company is or what it does. The point of his post today is one that I have found to be pretty true. People that actually has built a system with REST versus SOAP/RPC aren't the ones out there saying that SOAP/RPC is superior to REST (or the typical "I just don't get why I'd care about REST"). Check out my BizTalk R2 Training . Read More......(read more)

Book review: Pro WF by Bruce Bukovics

The Problem Solver : Workflow — 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. Read More......(read more)