Reacquainting myself with Windows Workflow Foundation

Introduction


I have always found the Windows Workflow Foundation an intriguing technology because of the potential it has to truly separate business logic out of our code and into an easily maintainable, visually pleasing format.  Though it is used quite heavily in SharePoint to manage things like approval processes, unfortunately I haven’t seen it leveraged in very many custom built applications.  I think this is probably due to the lack of knowledge around the technology as well as the difficultly in building out the scaffolding to fully integrate it into a custom application.  There are dozens of articles on the Internet that show you how to build a simple “Hello World” workflow.  But it is a rather big jump to get it up and running in your application.  I’m speaking from personal experience.

It has been a while since I’ve worked with Workflow Foundation so I haven’t had the opportunity to explore the changes that came in version 4.0 of the .NET Framework.  I hope to reacquaint myself with WF the best way I know; by writing a series of articles on the topic.  So where do I start?  Well, as with most things in life, I Googled “Windows Workflow Foundation 4”.  The search yielded a rather disappointing result consisting of mostly forum posts asking for links to articles and learning material.  The first site in the result though was the official Microsoft site on Windows Workflow Foundation with has some good screencasts on how to build a simple workflow and run it from a console application.  And so begins the the series.

Comparing Versions


So what are some of the noticeable differences between Workflow Foundation 3.5 and 4.0? There are plenty because WF 4.0 is a complete rewrite.  I will cover a few of the major changes in the following sections.

Hey!  Where’s the “CodeActivity” activity?


The first and most notable difference is the lack of the ever popular custom code activity that was included in WF 3.5.  This was the activity you could drop on your workflow canvas and double click to implement custom .NET code that would execute when the workflow reached that activity.  The reason the custom code activity is missing goes much deeper than Microsoft simply removing it from the workflow toolbox.  It come down the the fundamental way that the workflow itself is created.  In WF 3.5, the workflow was actually .NET code that was generated from the workflow diagram at the time that the diagram was saved.  This meant that you could include custom code in the workflow’s code behind.  In WF 4.0, workflows are defined declaratively using XAML.  The workflows are now interpreted at runtime as opposed to being compiled.  So though the designer canvas hasn’t changed much, what is happening beneath the covers is quite different.  So how do you go about defining custom code to execute in your workflow?  By creating custom activities that you can drop onto your workflow canvas.

Note: This is not to say that you cannot manually create workflows using pure .NET code, it is just not the way in which the designer creates workflows for you.

Sequential vs. State Machine Workflows


The second difference I would like to point out appears when adding a new workflow project to your solution.  There is no longer an option to add a sequential or state machine workflow library.  Instead, you have the option to add an activity library which encompasses both types of workflows.

In WF 3.5, sequential and state machine workflows were fundamentally different in that they derived from different base classes (System.Workflow.Activities.SequentialWorkflowActivity and System.Workflow.Activities.StateMachineWorkflowActivity respectively).  This meant that you had to decide upfront whether to use one type or the other.  In WF 4.0 both workflow types derive from the System.Activities.Activity base class which means they operate in much the same manor.  The two workflow types are simply activities themselves found in the toolbox that you can drag onto your workflow canvas.  You no longer have to choose one workflow type or the other.  In fact, you can actually integrate the two types to create highly sophisticated workflows.

Flowchart Workflow


Sequential and state machine workflows were the only two types supported in WF 3.5.  Sequential workflows are good for straight through processing with little or no human interaction; whereas, state machine workflows are good for processes that tend to jump back and forth through a series of states based on user input (think wizard style user input).

WF 4.0 introduces a new type of workflow called the flowchart.  Flowchart workflows are similar to sequential workflows but easier to implement because you can drop activities on the designer canvas and literally connect them to define the workflow path.  This means you can build out complex workflows without having to use the control structure activities like “if” and “while” activates.

I really like the flowchart workflow because it resembles the flowcharts that developers and business analysts often create on a whiteboard during requirements gathering.

Conclusion


In conclusion, the 4.0 release of Windows Workflow Foundation brings about some major changes. In all I find the changes to be a large step in the right direction. The big change of course being the move away from generated .NET code and focus on XAML to define workflows. In my next article I will be demonstrating how to create your first workflow.

Links
http://msdn.microsoft.com/en-us/netframework/aa663328

Comments

Post a Comment

Popular posts from this blog

Tracking Authenticated User ID in Application Insights

After getting the basic out-of-the-box inplementation of Application Insights (AI) up and running, I decided to customize it to pass the ID of the current user along with the telemetry.  The first couple of articles I discovered recommended writing a custom Telemetry Initializer to populate the Telemetry.Context.AuthenticatedUserId property.  Since my website uses ASP.NET forms authentication, I was able to grab the ID of the current user from the HttpContext.Current.User property.  My initializer ended up looking something like this: public class MyTelemetryInitializer : ITelemetryInitializer { public void Initialize(ITelemetry telemetry) { var identity = HttpContext.Current?.User?.Identity; if (identity == null) return; telemetry.Context.User.AuthenticatedUserId = identity.Name; } } Then I register my initializer using the following line of code in the app_start function of my Global.asax.cs file. TelemetryConfi
Read more

Introduction to Reactive Extensions

Working in the field of technology means constantly learning new technologies and using them to build cool new software.  I think my desire to learn is what drove me to this industry.   My most recent endeavor was learning the Reactive Extensions (Rx) for the .NET framework.  I had no reason to believe that picking up Rx would be any different from any other technology.  Boy was I wrong!  In my 10 years of learning new technologies, the difficultly of learning Rx rated right up there with making the switch from procedural to object oriented programming.  It is a paradigm shift that requires you to completely rethink the way you develop.  Developing with Rx will probably come more naturally for those of you well versed in asynchronous programming, but I did not have much exposure to async programming prior to this undertaking (which is probably why I found it so difficult to pick up).   Another reason why I found it difficult to learn Rx was because of the pace at which it wa
Read more

Writing Your First Rx Statement

Image
Introduction In my first blog post on Reactive Extensions (Rx),  Introduction to Reactive Extensions , I mentioned that there are several ways in which you can create an IObservable<T>. The most fundamental way to create an IObservale<T> is be using the Observable.Create<TSource>() method.  At first glance this method is a bit confusing but once you know how to implement it, it becomes very powerful. You First Rx Statement  In this tutorial I will build a Windows console application that will make an asynchronous web call to the Twitter API using the WebClient.DownloadStringAsync() and Rx.  I begin by creating a new console application called SampleRxApp. Next, I add the appropriate Rx reference.  For this, I use Nuget to add a reference to Rx-Main. Once I have added necessary Rx library, I add the following using statement to the top of my Program.cs file.  using System; using System.Net; using System.Reactive.Linq; I n
Read more