Side by side versioning of workflow services
One of the really important new features in Windows Workflow Foundation 4.5 is the capability to version workflows and workflow instances. You get to choose what you want to do, either keep running existing instances with their original workflow definition or upgrade them to the latest workflow definition.
In the previous blog post I described how to upgrade existing workflow instances to run with the last version. However there are cases where that is not what you want, instead you want to deploy multiple version of the same workflow side by side and use the original version for each instance. For example if your business contract conditions change it makes sense to keep the older workflow instances with the original workflow definition and start new new workflows with the new definition.
The basic steps
- Create your initial workflow definition.
- Start one or more instances using this workflow definition.
- Save the original workflow definition so existing instances can keep using their original definition.
- Make some changes to the workflow definition.
- Start one or more instances using the new workflow definition.
Create your initial workflow definition
This is the simple step as anyone that has been using Windows Workflow Foundation 4 has already been doing this. For this example I am using a real simple workflow service that returns the workflow version. The workflow keeps on looping around so you can call the same instance as often as you want.
Just like before I am using a WorkflowIdentity with a version of 1.0, this time defined in the WorkflowService.
Start one or more instances using this workflow definition
Again no big deal here, just call the workflow service.
Save the original workflow definition so existing instances can keep using their original definition
This is the new part. In the previous post we upgraded the workflow instances, in this case we are going to keep the original workflow 1.0 definition available.
First create the special App_Code ASP.NET folder. Inside this folder create another folder with the same name as the workflow service, TheService in this case. Finally drop a copy of the original workflow definition in this folder. The actual XAMLX file name is not important, in this case I renamed it to TheService_v1.xamlx so I can keep multiple versions as needed.
Make some changes to the workflow definition
The change in this case is trivial but you can do whatever you want. First I updated the WorkflowIdentity to reflect a Version of 2.0. Next I updated the return from the WCF request to show that this is an instance of workflow version 2.
Start one or more instances using the new workflow definition
Now we can update the client to call the previously saved workflow instance with the original version as well as a new instance with the updated workflow definition.
The cool thing is that the WorkflowServicehost keeps track of which workflow definition to use based on the workflow version. So all we need to do is make sure each workflow definition has a unique version. In fact the WorkflowServicehost will enforce this. If you try and run with two workflow definition with the same identity you will see an InvalidOperationException with a message like:
WorkflowService with (TheWorkflow; Version=1.0) DefinitionIdentity already exists.