Creating Multiple Versions of Workflows
In the recent past, a question that has surfaced quite often is regarding the versioning of workflows and the errors that show up when trying to do so. It is quite natural to expect an extreme level of dynamism and out-of-box features from Microsoft, but one needs to take a pragmatic view of WF.
There is a clear distinction between a Workflow Definition and a Workflow Instance. A Workflow Definition is a Template and a Workflow Instance is a runtime representation of that template. We can closely relate to the Workflow Definition and a Workflow Instance to a Class and an object respectively.
A Workflow can be authored programmatically in C# or exclusively in XAML or using a combination of both. When a workflow instance is created and persisted, it is persisted with its state and also the type information of workflow and activities used. During this cycle of instance passivation, if the definition of the workflow (or the activity used in the workflow) is changed and the assembly with the old definition is removed, then the workflow runtime throws an error. This is an expected behavior since Binary Serialization is type dependent.
Workflow Foundation does have a solution to this problem in the form of Dynamic Workflow Updates using the WorkflowChanges API. The following is one of the possible ways of mitigate the problem of workflow versioning:
1. The assembly with the new workflow definition (or activity definition) is added to the GAC (or a location where you reference your assemblies from). This will sit beside the assembly (older version) that contained the older definition. The assembly with the older definition(s) MUST be present in the GAC (or a location where you reference your assemblies from).
2. When the workflow is to be rehydrated, identify the changes between the older definition and newer definition by getting hold of the corresponding definitions and apply changes to the workflow using the WorkflowChanges API. Once the changes are done, the workflow can be resumed. Two ways in which this can be done:
- This can be done on-demand or can be a background process. When we say on-demand, the applying of changes is done when the workflow is rehydrated by the user or application and it is resumed immediately.
- If it is a background process, the workflow instances corresponding to this workflow can be loaded into the memory; changes can be applied and the instances can be dehydrated back to the persistence store. So, when the workflow instance is next invoked by the application, it is loaded and resumed directly. This process can be accomplished using a windows service. However, the synchronization aspect should be taken care of here.
But the question definitely remains as to why there isn't a mechanism which can change the instances when there is a change to the definition of the workflow? Here is one possible reason:
A defintion is a "Stateless" entitiy while an instance has a "State". A workflow definition is either a .NET assembly or an XAML file which is used to create an instance. Any change to the definition means a change to the stateless entity and it happens at design-time. To get this reflected on to a run-time entity needs a program to do so. Moreover, the Workflow Persistence Service can be customized and this makes it an even greater challenge.
For a small set of workflows, the issue of versioning may not really be a show stopper. However, when planning a large scale use of WF, it is necessary to take an appropriate view of the versioning required and move ahead. It is important to set the expectations right before dealing with situations like these.
Comments
Hi Raghu,
The above article is fabulous. But my problem is not getting solved by this. My problem is something like.
I am facing a problem having multiple version of my activity library on the sharepoint server. Can anyone please let me know any article or any way out of this problem. I have done the following.
1. Created an activity library
2. Created a workflow using this activity library.
3. Deployed both of them in the sharepoint server.
4. I added some more activities in my activity library and increased its version.
5. Deployed it along with the old activity library on the sharepoint server (I tried replacing the old version also).
Problem starts here. The workflow that iIhave created in step 2 doesn't work anymore.
Do you have any clue as to what can be done for this?
Posted by: digvijay | March 25, 2008 07:51 PM
Hi Digvijay,
You may want to try these steps:
1. Create an activity library (lets say version 1.0)
2. Create a workflow using the activity library
3. Deploy both of them on SharePoint Server.
4. Add few more activities to the activity library (increase the version to 2.0)
*5. Update the reference of the activity library in Workflow assembly.
--> This step is important because your workflow will be referencing the previous version of the activity library
6. Update the version of the workflow assembly to v2.0 and build it.
7. You will now have v1.0 and 2.0 of workflow assembly and also for the activity library.
8. As you would have previously deployed the v1.0 of the Workflow assembly and activity library, deploy the new versions of the respective assemblies side-by-side.
This should most likely solve your problem.
Note: You'll have to take care of the instances of this workflow which are in passivated state (persisted state).
-Raghu
Posted by: Raghu Kishore Vempati | March 26, 2008 08:23 AM
Hi Raghu,
Thanks for the information. Actually, I have created my workflows using sharepoint designer. I have not created a separate assembly for that. Can I change the version of my activity library in an already deployed workflow (by loading them and recompiling them or any other thing of this sort)?
Posted by: Digvijay | April 2, 2008 03:28 PM