Version handling in Workflow Foundation 4
When comparing workflow engines, versionning is a key aspect to take into account. If you are going to implement a workflow based solution, before committing to a platform you need to know what level of support does the engine provide to manage changes throughout the lifecycle of a workflow, you need to know what's going to happen to all the active workflow instances deployed on live once you've made a change on the flow of activities. Will the running instances still run after the new deploy, will they take the changes into account or will they run according to the version of the flow they were deployed with? If not what will my migration strategy be then?
There's a new version due in March/April of the .NET Framework, and a new Workflow Foundation along with it, both already available in Beta 2 version. I'm working on a project based on WF 3.5, and this feature, or the lack of it, has been a major drawback in the current implementation, so when I heard a new version was coming I started to do some research on the topic.
If you google Workflow Foundation versionning some of the best WF4 links you come across are from the workflow forum threads were the versionning issue appears, in particular in this thread, the response seems to be (and I quote): "WF4 will not support upgrading existing workflow instances to new definitions. Those instances will need to complete before they can be replaced.".
On the other hand, in this thread a different and more verbose description is provided, where changes are classified as ok changes, and breaking changes.
Based on this threads we decided to do some testing with the beta 2 available to check the behavior of applying changes to a workflow with running instances stored in persistence. We started by modifying the existing persistence sample solution in the training kit (\WF_WCF_Samples\WF\Basic\Persistence\InstancePersistence).
Basically we started several workflow instances with a first basic workflow version, where they unloaded onidle on a bookmark in the middle of the execution. Then we modified the workflow, recompiled, and then loaded and resumed the execution of the persisted instances with a new version of the flow.
The original workflow was:
 |
 |
The results were the following:
The first change applied to the workflow (activities were added at the end of the sequence) did not break the running instances, but it was not taken into account by them either. Workflow instances started with the first version of the workflow completed according to the original logic, while new instances did take the change into account. Looking back at the threads, this change seems to be an ok change.
Change applied (2 new activities at the end of the sequence):
The second change (a conditional activity was added at the beginning of the workflow) did break the running instances, where the execution failed with the following exception message: "'WriteLine' is not of type 'Sequence'. When loading this instance you must ensure that the activity with name 'WriteLine' implements 'Sequence'".
Second change applied (a conditional activity was included before the existing sequence activity, no variables, arguments or bookmarks were added or modified though):
Conclusion
Bottom line, WF4 seems to behave according to what Amadeo Casas stated in the forum thread, WF4 does not seem to support upgrading existing workflow instances to new definitions, with the observation that some changes are ok, meaning they will not break the running instances, and will only be taken into account by new ones, while there are other changes that are not ok, but are breaking changes. In this cases and when in doubt imho the safe choice would be to deploy current workflow assembly to the GAC, and deploy the new one with a different, increased version number also in the GAC, pretty much as we had to do in WF 3.5.
The sources used in the test can be downloaded from here.