Category Archives: Windows Workflow Foundation

Windows Workflow Foundation Episode 3

Welcome to part 3 of Windows Workflow Foundation 4 for K2 developers. In part 1 I outlined the differences between how you should approach K2 and WF4, and in part 2 I spoke about the different designer options you have and mentioned a few best practices. There is 1 more topic I need to discuss before we can start building our workflow engine, and that is the topic of workflow persistance.

As I mentioned, WF4 is not a service – it’s baked into your application, so when your application thread stops running, so does your workflow. If we’re going to be turning this into a service then we’re going to need a way of maintaining workflow state. We’ll be doing this by serialising our workflows and persisting them in a database.

Step 1 – Creating the SQL Store

Microsoft have made this simple for us by providing us with the store to use. Assuming you have .Net 4 installed on your machine you should be able to navigate to [C:\Windows\Microsoft.NET\Framework\v4.0.30319\SQL\en] and you’ll see a bunch of SQL scripts. 2 of these are important to us:

  • SqlWorkflowInstanceStoreSchema.sql – This script will provide you with the schema you need to persist your workflow
  • SqlWorkflowInstanceStoreLogic.sql – This adds the logic to the schema

Start by creating a new database called WorkflowInstanceStore, then execute the above scripts against the database. That’s it – you’re done.

Step 2 – Set your workflows up to automatically persist

What we want to accomplish here is to get your workflows to automatically persist whenever the workflow is idle, such as when it’s waiting for a user to do something. We will also need a way of referencing this workflow again at a later stage (so you’ll need to save the workflow ID) and you’ll also need to be able to tell the workflow which activity you’re wanting to resume, and for this you need a Bookmark (a bookmark is just a string). I’ll show you how to get your workflow to automatically persist itself to the database by creating an activity which listens for the idle event. Here’s what you will do (we will implement this later – this is just pseudocode to get the idea across)

  1. Create a code activity which inherits from NativeActivity and call it WaitForSomething
  2. Add this method in:
  3. protected override bool CanInduceIdle
       get { return true; }
  4. Create a new workflow and somewhere in the workflow you should add your WaitForSomething activity. Now when you start your workflow, you’ll do it this way:
  5. WorkflowApplication wfApp = new WorkflowApplication(MyWorkflowDefinition);
    SqlWorkflowInstanceStore store = new SqlWorkflowInstanceStore(connectionString);
    wfApp.InstanceStore = store;
    wfApp.PersistableIdle = delegate(WorkflowApplicationIdleEventArgs e)
       // Instruct the runtime to persist and unload the workflow.
       return PersistableIdleAction.Unload;

I’ll stop here and recap what we’ve done. Firstly, we created an activity which raises a PersistableIdle event. Then we added this activity to a workflow and created a delegate to handle the PersistableIdle event. The event returns Unload’ which tells WF4 to unload the process from memory and persist it to the sql store referenced by the connection string we provided.

Right – I think I’ll stop there because if we go any further without doing some examples we’re going to get lost. In the next post we will start building our project and I’ll include the project for you to download so you can follow along.

As always, please send any and all questions my way.

Leave a comment

Posted by on December 15, 2011 in Windows Workflow Foundation


Windows Workflow Foundation Episode 2

[Yes – I know I only published episode 1 a few minutes ago, but I wrote these 2 posts on a 14 hour plane trip]

Welcome back to WF4 for K2 developers. In my earlier post I spoke about the differences between K2 and WF4. In this post I’ll speak about the workflow designer options you have and some best practices.

There are a number of ways you can build your workflows, each with pros and cons

  1. Firstly there’s the graphical designer. All you K2 gurus will leap straight into this one, but keep in mind that there are no line rules – you have to use decision points to build in your business logic. Also, there are several options for the graphical designer – you could use a sequence, a flow chart, a state machine, or any combination of these. Again, each of these have their pros and cons, but if you’re looking for something similar to the K2 canvas then try a flow chart. True to style, the graphical designer is purely a front end to generate XAML, which leads me to the second option…
  2. XAML. If you’re happy coding in XAML then you can do it all in XAML. Personally I don’t see the point…
  3. Code. Anything you can do from the designer you can do in code, and I have to say that it’s very well thought out – designing a workflow in code is simple, quick and easy to follow (to a point).

So which should you use? The answer is, of course, that it depends on the workflow you’re designing. Here are some guidelines which should help you choose…

  • For small workflows, use code. There is a VERY tiny performance improvement, it’s easy to edit the functionality, but the biggest advantage is the ability to use the built-in refactoring functionality. If you’re using XAML or the designer, you’re refactoring manually. Of course if your workflow is coded then you can step through it in the debugger as well.
  • For all other workflows, use the visual designer. As nice as the code is, it quickly becomes difficult to follow the business logic and you get lost in a sea of confusion.
  • For those of you in the real world, you will use both. When I am building a WF4 app I create a project to hold commonly-used custom activities which I have written. Some of these are in code, some are in XAML, but when I build the actual workflow it’s always in the designer. The only thing I would say is that there’s no point in writing a workflow in XAML from scratch. It’s like coding C# in notepad. Yes, you can do it, but why would you?
  • We have an approach in Dynamyx which is “everything is a framework”. Try make your approach to your workflows as generic as possible. Look for reusable sections and turn those into separate custom activities. Build up a library of generic activities for use in other projects. When we start building our workflow engine you’ll see what I mean.

Finally, if you’re using code activities you will be writing classes which will inherit from one of several base classes. By default you should either use CodeActivity or it’s asynchronous counterpart since these are lightweight. If you need more advanced features (like automatic persistence when your activity is idle) then you need to inherit from NativeActivity. There are others, but these cover 99% of the cases you will see.

In the next post I’ll speak about workflow persistence and events since we’ll need a good understanding of how this works before we you can dive into developing the workflow engine.

1 Comment

Posted by on November 30, 2011 in Windows Workflow Foundation


Windows Workflow Foundation Episode 1

A wise man once said that if all you have is a hammer then everything you see is a nail. A wiser man (Scott Adams) pointed out that if all you have is a hammer then you’re not going to be thinking about nails because you’ll be using your hammer to hide your naughty bits on account of you being naked (seeing as all you have is a hammer). I reckon they were both right. The point is that even as a K2 consultant it’s worth knowing what the other workflow vendors are doing in the workflow world.

I have been working on a workflow project where K2 wasn’t an option. I dutifully looked at other workflow options (there are a few open source options out there) but none of them ticked enough boxes. Eventually I decided that my best option was to write my own workflow engine using windows workflow foundation.

Since you’re reading this blog I’ll assume that you are either a K2 developer, or you have no life at all and need to get out more. I’ll give you the benefit of the doubt. I’m going to be writing a series of blogs here describing windows workflow foundation from the point of view of a K2 developer. Windows workflow foundation 4 is not difficult, but if you approach it like a less-featured K2 (which is what I did) you’re going to get nowhere. Hopefully this will make it easier.

In this blog I’ll be outlining the differences between WF4 and K2 and how you should approach them differently. In later posts I’ll walk you through the process of wrapping WF4 up into a workable workflow engine.

So if you’re a K2 developer looking at WF4 for the first time, these are the things you need to keep in mind or you will get totally lost:

  1. In WF4 there is no difference between an activity and a workflow. When you start a workflow you are actually starting a new activity. You can create complex activities (similarly to how you can create a usercontrol which contains other controls) but they all become part of the same workflow. So there’s no concept of an IPC call here. In fact, you can create 2 complex workflows and add those workflows as child activities in a parent workflow, and all the workflows will have the same instance GUID assigned to them. So when I speak about a workflow I could be speaking about an activity or a group of activities as well.
  2. In WF4 there’s no concept of tasks being assigned to people. There’s no AD integration. Basically there are server tasks and that’s it.
  3. In WF4 the workflow is baked into the application. This means that when your application is running, your workflow is alive and accessible. When your app is closed, the workflow is closed as well. This is a biggie. There’s no concept of making a call to a workflow engine. You can persist your workflow to a database in order to save state but if you close your application and hope that an escalation rule will fire in the background you’reout of luck. Of course you can create a WCF service to host your workflow app, or you could use AppFabric. We will obviously do something along these lines.

Those are the main differences – if you can get your head around these points you’re well on your way to understanding WF4. The next post will speak about the workflow designer and mention some best practices. If you have any questions during the series, please feel free to ask…