Internet Architect by day, environmentalist by night: Jim Schwartz @ imason.
Home » What We're Thinking » Jim @ imason
Photo courtesy of Neatorama
2 weeks ago I had a seemingly crazy idea. I challenged my colleagues at imason in a contest to see who could last the longest without taking the elevator. Considering we’re on the 8th floor of our building, I figured there wouldn’t be a myriad of people lined up to enter the contest.
Boy was I wrong.
15 people entered the contest, and in the last 2 weeks, imason employees have walked up and down approximately 47,250 stairs.
imason’s employees are so dedicated that some are even riding their bikes to work and carrying their bikes up 8 floors.
Not only is this challenge good for the environment, but it’s also great for everybody’s health. I’ve long been an advocate for active, healthy living and I believe strongly in treating the earth well. This is one simple thing that we can do to help make a small difference.
One thing I don’t know is how long this contest will last. But I can honestly say that I hope it continues for many months to come.
I’m in it for the long haul.
Could this be the latest Service Pack for Vista??
At first glance, Windows Workflow does a good job of persisting workflows to the database for long-running State Machine Workflows.
However, what happens when you update your workflow assembly? Windows Workflow will try to retrieve the workflow from the SQL Persistence store and de-serialize the object, but it will throw an exception (You’ll see a SerializationException or IndexOutOfRangeException).
There are different ways to handle this situation. The first (and most obvious way) is to set versions on your DLLs so that the workflow will de-serialize into a previous version of a workflow and continue running in the older version. But what if the change you made to the workflow fixes an important bug in the previous version? In this case, you may want your previously persisted workflows to use the new version of the code.
A few quick Google searches will lead you to a few different options in handling this situation:
None of these options are particularly appealing to me, so I had to find a better way to handle updates to the workflow code but still allow my long-running workflows to operate.
My “outside the box” solution: Workflow Rehydration
To achieve Workflow Rehydration, I’m keeping track of the current state in a SQL database and if the current workflow can’t be de-serialized (because the workflow has been updated), I instantiate a new workflow and I set the state to the state it was previously in.
The obvious concern that comes up using this approach is “how do I avoid executing the code inside my StateInitializationActivity?”
To get around this issue, I’m passing in a boolean parameter into my State Machine workflow that indicates whether or not the workflow is being rehydrated. I then use an IfElseActivity to execute my State Initialization code only if the workflow is not being rehydrated.
The end result is that the workflow goes back into its previous state, but it’s now running inside the new updated workflow code. You might call this a “Utopia State” (Apologies for the lame pun).
The end user has no idea that the workflow has gone through this transformation from an old version of the workflow code to the new version; and it only took a little bit of code along with some IF conditions.
References:
[1] http://msdn.microsoft.com/en-us/library/aa349375(VS.85).aspx
[2] http://community.bartdesmet.net/blogs/bart/archive/2006/08/28/4322.aspx
[3] http://www.sitechno.com/Blog/WorkflowVersioningOfLongRunningProcessesSucksHereIsMyTakeOnIt.aspx