If I had Workflow Foundation, would I have finished this column on time?

03
Jun
2009

Fred Yeomans

So this time I am going to talk about Windows Workflow Foundation (WF) as I promised quite a long time ago. After setting a definition, I will talk about what WF is, and as importantly, what it is not. In addition, I will talk about how WF fits in to the SharePoint world. I will then talk about some of the things I like about WF under SharePoint, and some of the things I do not like (hey, no technology is perfect!)

What is Workflow?

Yeah I know, we all “know” what workflow is – unfortunately it is different things to different people. In fact, it does not seem to be a word – at least not according to the Miriam-Webster Online Dictionary, but this is a definition I found at BusinessDictionary.com:

Progression of steps (tasks, events, interactions) that comprise a work process, involve two or more persons, and create or add value to the organization's activities. In a sequential workflow, each step is dependent on occurrence of the previous step; in a parallel workflow, two or more steps can occur concurrently.

I would tend to simplify this a little. For me, the meaningful part of the definition is:

A workflow is a progression of steps (tasks, events, interactions) that comprise a process and create or add value to the organization’s activities.

Note that this does not necessarily involve computers or software in anyway. If you are performing a sequence of steps to get you from A to B, you have a workflow. It may not be a good workflow, it may not be documented, and it may not be consistent – but it is a workflow. I am not even completely convinced about the “create or add value” part – I have seen a fair number of workflows that seem almost purposely designed to decrease value.

What is Workflow Foundation?

So now that we all agree on the definition of workflow (and we do all agree, right?), what exactly is Workflow Foundation? Workflow Foundation is a set of libraries introduced in .NET 3.0 intended to serve as a framework for the development of workflow-enabled software. It includes runtime classes which support the loading of workflow templates, initiation of instances based on those templates, managing the state of the workflow, managing persistence, monitoring, tracking, and many other things. Also provided are classes for defining the workflow template itself, including sequential and parallel activities, etc. There is also support for defining a workflow template declaratively in an XML file. The Workflow Foundation is also extremely extensible, allowing the addition of custom activities, persistence providers, etc. Not only is it extensible, you pretty much have to extend it in order to do anything useful.

Note that Workflow Foundation is not a server. It is just a set of libraries, a framework, a toolkit. On its own, it does not really do anything. The Workflow Runtime must be hosted inside another application in order to be useful. This application can take a number of forms. In fact, almost any .NET application can be a WF host. A custom application you write yourself is one approach, if you want to spend a lot of time building, testing, and maintaining an enterprise-class application, with all that entails. There are also third-party applications which host the WF runtime, but generally only for the specific purposes of that application. You can also host a WF workflow in a worker process provided by Internet Information Server (IIS), though this approach is extremely limited. Finally, WF is hosted in MOSS 2007, enabling you to develop workflow solutions within the context of your SharePoint environment. In addition, there are add-in tools available for Visual Studio which provide direct support for developing workflow templates which integrate with SharePoint.

Microsoft is also working on a technology code-named “Dublin”. Dublin is implemented as a set of extensions to IIS and the Windows Process Activation Service (WAS), and is intended to make IIS and WAS more attractive as a host for workflow services.

For a more detailed overview of Workflow Foundation, take a look here.  

Workflow Foundation and MOSS

As stated above, one option for hosting your Workflow Foundation workflows is to use your existing SharePoint infrastructure (everyone is planning to use SharePoint, right?). MOSS 2007 hosts the WF runtime, and allows you to connect a workflow to any SharePoint list, library, or content type. This connection is called an “association” in SharePoint. You can also associate multiple workflow templates with a given list, library, or content type. Once these associations are created, instances of the workflow can be initiated on items in the list or library, or on instances of the content type. You can even set a workflow to be initiated automatically when a new item is created. Part of creating the workflow association is the specification of a Task List for the workflow to use to create tasks for the users, as well as the specification of a History List, to which the workflow can log events.

So, how do we implement a workflow template and use it in SharePoint? Three ways to do this, in increasing order of functionality, complexity, and effort (funny how these all go up together) are:

• Use one of the (very simple, very basic) workflows built into MOSS.
• Use SharePoint Designer to design a custom workflow using the built-in activities available in MOSS. This might be appropriate for simple things like a vacation approval workflow.
• Use Visual Studio to develop a custom workflow template, complete with custom forms (using ASP.NET or InfoPath) for Association, Instantiation, Tasks, and Modification, potentially custom activities, and the potential to customize almost anything else.

In the real world, pretty much any realistic workflow you would care to implement will require the third approach. This makes it more of a development effort than just a “draw a workflow” process.

That being said, a considerable (maybe even a majority) of the effort expended in your projects will be consumed on the business side of the problem (eliciting and capturing your processes, defining the data and it sources and destinations, etc.) as opposed to the technical. Isn’t this always the case?

The Good, the Bad, and the Ugly

Like most technologies, there a good many things I like about Workflow Foundation and many I do not like.

I really like the tools for working with WF inside Visual Studio. Then again, I am coder at heart, and so I like working inside development tools.

The tools inside SharePoint Designer, on the other hand, I find clunky and cumbersome. The idea is good, but the implementation really does not live up to Microsoft’s usual standards.

I also like the architecture of the Workflow Foundation. The extensibility is good, as is the ability to plug in your own implementations for various services.

Microsoft has done a pretty good job of hosting WF inside MOSS. But why do all that work and do such a fine job, but then leave out support for the Tracking Service (from the Microsoft web site “as workflows execute, the tracking service can be configured to automatically emit information about the flow of control within the workflow, and this information can be stored in an external store, such as a SQL Server database, for querying. This allows various applications, from custom applications to business analytic tools, effectively to "look inside" workflows and query their status, or determine which are blocking on specific external events. This surfacing of tracking information is essential in creating the transparency that workflow solutions require”)?

I also find the mechanics of implementing custom forms to be cumbersome. Especially, in the situation where the workflow is being performed on an InfoPath form instance, accessing the data in the original form instance from the workflow forms themselves can be painful. In fact, I find the whole model of walking an InfoPath form instance through a workflow a little counter-intuitive – though this may just because it is significantly different from the model I used to architect a workflow platform in the past.

All in all, I like using WF inside SharePoint. In an ideal world, I would love a workflow platform where everything is point and click, drag and drop. WF is not there yet, and a considerable amount of custom code is still required. But it is extremely flexible, and as you implement more workflows you should be able to reuse considerable amounts of the custom code (if it is well architected).

I am also looking forward to working with “Dublin”, especially since it gives those who have not bought into SharePoint another option for deploying WF solutions. It may even be an alternative for those who are using SharePoint, as well.  

In a future column (though probably not the next one), I will walk through some of the best practices we have discovered while implementing solutions such as Prebill and New Business Intake using Workflow Foundation within MOSS. Next time, I will...well, I have not decided yet. You will just have wait and find out when I do!