What happens to running workflows when the workflow is changed?

What happens to running workflows when the workflow is changed?

• MSBassSinger

  Hi Urs__Eichmann,

  Please look at this post, it maybe contains a solution for our problems:
  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=708524&SiteID=1&mode=1

  Next week, I am going to test it within my project. I will report the result.

  Update (13/09): I just tested the posted solution and works perfectly!!!

  
  

• DOSrelic

  I see a big problem coming towards us in the future. After all, changing the workflow to incorporate new features is daily business. If I tell my customers that every change to a workflow with persisted instances is a major issue, involving programming dynamic updates of "old" workflows, extensive testing how all the persited instances will behave, and so on, they will be quite embarassed. Especially compared to the fact that, in traditional programming (implementing the workflow with C#), I usually can change the workflow implementation without any problems.
  
  What's more, I must tell to the people which use my embedded workflow designer that they can't just change their workflows, once they have perstisted instances anywhere, anymore - otherwise everything would probably stop working.
  
  I think a paper or statement of MS addressing this very issue should be published ASAP, before the first WF applications go into production.
  
  Best regards,
  Urs
  
  

• jiriw

  Could you please give an example how I can dynamic update the existing instances

  Thank you in advance!

  
  

• Whoisit

  Matt Winkler -- MSFT wrote:

  You are correct though, this does require some foresight in the design and planning stages of workflows, and I will find out where we are at with guidance around this issue.

  Matt, did you find any guidance in any form on preventing and handling versioning issues with workflows (and their state) already

  
  

• nzmike

  Where can I find good examples of how to use side by side versioning for ASP.NEt apps. I have been trying to get this to work for a long time. The issue that I have is that I am creating a State Machine workflow for a form that gets processed. The data from the form is stored in SQL and I did setup the SQL Persistence Service. Everything works fine until I need to change the workflow. Once a change is done to the workflow and I try to load the instance using:

  WorkflowInstance workflowInstance = workflowRuntime.GetWorkflow(instanceId);

  I get an INdex out of bounds of the array error message.

  Please Help.

  
  

• arogan

  Never mind, I found some samples myself at the following location:
  http://windowssdk.msdn.microsoft.com/en-us/library/ms742040.aspx

  
  

• shruti.makwana

  I cannot believe that's true.

  You mean I cannot update my workflow (to expand it or when it contains a bug) if there are any running instances of that workflow That is not a workable situation.

  The only time there are no running instances is when my application is just deployed. But shortly after that the workflow instances are created and the number keeps growing.

  Could anybody please tell me how to deal with this situation

  
  

• Little_Dice

  Side by side versioning is neat way to change new WF running along with old definition WF's. Whenever you are persisting and saving your WF, along with WF instanceid you can store the version of WF also, for e.g. WF1,WF2 etc in app specific DB.

  For all new WF instanciation use WF2 and while loading from persistence store, dynamically instantiate instance based on version of WF stored in app specific datastore. It's like having CreateWorkflow("version_from_Db"), very much like a switch case.

  
  

• DrDeath

  The entire workflow instance is serialized. If you have a running workflow, say v1.0.1 with some activitites, and then you blow away this assembly and replace it with v1.0.2 which has new activities, new instances will be created using v1.0.2 but v1.0.1 workflows will have problems.

  When the runtime loads an instance from the database the first thing it tries to do is create an instance of the assembly, if it cannot find v1.0.1 youre in trouble.

  
  

• evaleah

  Couple of options here. If you just need to fix a bug in some logic (like in a code handler) you can try recompiling without changing the version. There are no guarantees here though. You should take a backup of your production database and attempt to deserialize your stored instances and continue running them with the recompiled assembly. If you encounter issues while testing or if you need to alter the activity tree (remove/add activities) then you'll need to look at deploying a new version of the type. For existing instances you can do a dynamic update on each instance and modify them with the changes.

  Thanks,

  Joel West

  MSFTE - SDE in WF runtime and hosting

  This posting is provided "AS IS" with no warranties, and confers no rights

  
  

• rolandpish

  Urs,

  This is not the behavior for every change to a workflow with persisted instances. There are a couple of "it depends" involved in the issue of versioning, but the first one is "Do you want to change all instances, future and persisted, or do you only want to change future instances " Of the customers I have talked to, most have scenarios for both cases. So, in the case where you only want to change future instances, and you are dealing with compiled workflows, you need to use side by side versioning, as you would with .NET objects. In the case where you are using XAML activation (which I would encourage you to look at, especially if you are changing processes frequently), you just need to grab the new XAML when you create workflows at some point in the future. Using XAML activation may also let you have more flexibilty for customizing workflows without needing to compile the workflows (special customer x is treated in a certain way).

  In the case where you need to change all instances of the workflow, including persisted ones, and you have compiled you have two choices, which Joel was referring to above. You can just swap out the assemblies if you made a small change (internal logic to a method), but you will need to test it to see if it works, just as you would if you upgraded an assembly and deployed it to machines, you would want to test the calling apps. That's the "it might work" approach. If you need to make large process changes (add a new approval step) to persisted instances, you will need to use Dynamic Update to update the individual instances.

  The problem with allowing a broad sweeping change to all persisted instances of a workflow is that there are a lot of questions that come up. What if I am past the point of where I need to insert my new changes, how do I handle that What if I change rules early on in the process that would affect where I am at, do I rollback those activities What if I have already dynamically altered an individual instance, what happens to those changes The answers to these questions are determined by the nature and rules of the process, and there isn't a "right" answer, it's what's right for your scenario. Using Dynamic Update, you can specify the behavior to suit your business needs. You are correct though, this does require some foresight in the design and planning stages of workflows, and I will find out where we are at with guidance around this issue.

  See the Workflow Manager Application (available here, screencast here) for an example of applying dynamic updates from the designer to a persisted instance.

  
  
  
• What happens to running workflows when the workflow is changed?