RSS

Monthly Archives: November 2011

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.

 
Leave a 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…

 

Moving K2 databases?

My first Making Flow Work post! Feels like I’m cheating on the Naked Programmer.

Sometimes you need to move K2’s databases from one SQL server to another. Various reasons might force you to do it, specifically when you realised you should probably not have put the K2 databases on the same SQL Server as SharePoint 2010.

It’s a straight forward process and includes two parts:
1. Backup and restore all the K2 databases to a new SQL Server
2. Recreate the SCSSOKey symmetric keys and SCHostServerCert certificates

The following two articles explain the whole processes step by step:
http://help.k2.com/en/KB000591.aspx
http://help.k2.com/helppages/k2blackpearl1370/Backing_up_Keys_and_Certificates.html

I did however discover that, even after running the K2 Setup Manager to reconfigure K2 to point to the new SQL server, the out of the box K2 reports stopped working and that users could no longer create custom worklist filters (and I assume various other user specific configuration features must have been broken). Users trying to run OOB report got this error: An error occurred loading the report. Service: K2Generic Settings Service Guid: ffffffff-ffff-ffff-ffff-fffffffffffff Severity: Informational Error Message: Cannot open database “K2HostServer”. Users trying to create worklist filters got: “Could not save user data. Check error logs for more information”.

It seems that there is a service broker instance called the Generic Settings Service that contains a link the K2HostServer database and the link is not updated by the K2 Setup Manager. After manually updating the link, everything worked fine.

 
Leave a comment

Posted by on November 16, 2011 in K2 Workflows