Saturday, January 12, 2013

Workflow Versioning - Part 1

Past 2 weeks ago, I fell sick and took me sometime to do research about Workflow Versioning and write up this post. I believe every workflow user would encounter such scenario whereby you have created a workflow application which were already deployed and running in production environment, and then you need to make some changes to the workflow definition in the production environment, you would want those existing instance continue to run with old workflow definition until it is complete, but the new instance will be run with the new workflow definition.

How?

You can use WorkflowIdentity class.

If you host your workflow with workflow application, it is easy to implement version control to your workflow definition by using WorkflowIdentity class.

But, before that, we need to sign the assembly first. The reason is later we will load the assembly with the same name but different version.



Then, build your workflow project, then identify the assembly public key token by opening the Visual Studio Tool command prompt, and then enter the following command:

sn -T "<assembly file path>"



Now, create a new folder in your bin folder or move your compiled dll to some where else, for example create a folder call v1.0.0.0, and then put your compiled dll into that folder. Then, we need to make sure the application know which folder to find the v1.0.0.0 assembly.

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="WorkflowVersioning.Workflows" publicKeyToken="c0f56e0617db9e22" />
      <codeBase version="1.0.0.0" href="v1.0.0.0/WorkflowVersioning.Workflows.dll"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>

Alright, now you can use the WorkflowIdentity to indicate the assembly version to run  in workflow application with following code:

SqlWorkflowInstanceStore instanceStore =
    new SqlWorkflowInstanceStore(@"Data Source=.\MSSQL2008;Initial Catalog=WorkflowInstanceStore;Integrated Security=True;");

WorkflowIdentity identityV1 = new WorkflowIdentity();
identityV1.Name = "VersionDemo v1";
identityV1.Version = new Version(1, 0, 0, 0);

WorkflowApplication wfApp = new WorkflowApplication(new VersionWF(), identityV1);
wfApp.InstanceStore = instanceStore;
wfApp.Run();

Do a test run and let's create an instance in persistence store. After that, make some changes to your workflow definition, then change the assembly version to 2.0.0.0, then rebuild your project. Now you have v2.0.0.0 dll in the bin folder, and v1.0.0.0 dll in the bin\v1.0.0.0 folder.

With the following code, the workflow application actually run with v2.0.0.0 assembly, while the existing instances in the persistence store will keep continue running with v1.0.0.0 assembly until the instance is completed.

Then, from now onward, you need to use new WorkflowIdentity for v2.0.0.0 assembly when you run your workflow application.

WorkflowIdentity identityV2 = new WorkflowIdentity();
identityV2.Name = "VersionDemo v2";
identityV2.Version = new Version(2, 0, 0, 0);

WorkflowApplication wfApp = new WorkflowApplication(new VersionWF(), identityV2);
wfApp.InstanceStore = instanceStore;
wfApp.Run();


Next research will be about how to make workflow versioning work with IIS/WAS. See Part 2.

No comments:

Post a Comment

Send Transactional SMS with API

This post cover how to send transactional SMS using the Alibaba Cloud Short Message Service API. Transactional SMS usually come with One Tim...