What’s the proper way to replicate an instance store database in WF4, from a production server to a development server? We have an application using Windows Workflow Foundation 4 on AppFabric and IIS. We have a machine with SQL Server 2008 R2 hosting our instance store database for production environment, and a separate machine, also with SQL Server 2008 R2, hosting our instance store database for development environment. Now, we need to replicate the exact state of what we have in the production environment, into the development environment. For the business database that was easy, I just asked our datacenter to backup the development business database (Oracle server), then entirely replace the development business database with a copy of the production database (separate machines too). I thought maybe the same approach could work just as easy with our WF4 instance store databases.
But it turns out it didn’t. After the copy, running the application in development environment, whenever it tries to resume an instance bookmark or call an instance operation that is part of an already started workflow, we get the “Operation '[operation name]' on service instance with identifier '[guid]' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees” exception message.
On the other hand, if we start a new workflow, it works fine and can continue to the end with no trouble. By briefly looking into the System.Activities.DurableInstancing.InstancesTable, it seems to me that, after the copy, previous instances of workflows cannot be properly identified, and WF4 tries to start new ones, which leads to the “operations in incorrect order” thing. For example, these newly created instances have very different ServiceDeploymentId ids than the ones in the instances copied from production. But I really have very little experience with WF4 and am pretty much clueless as to what is going on. (I did search for an answer, from StackExchange and other sources, before creating this post.)
How can we create a duplicate of the production WF4 instance store that, once in our development server, will work with our application in development environment as having the same application state that production has? Thanks.
Hello again. I am wondering why there have been no comments on this post so far. It’s a fact that updating data in a development or QA environment with data from a production environment is a very common thing. And I am almost sure that this is being done out there with WF4 workflows too, on a regular basis, somehow. It’s a matter of replicating WF4 workflows’ status from one database server (production) to another database server (QA or development), so that an application running on QA or development environments can “get” the same application status as the production server has, and from there can continue advancing and working with the workflows copied from production, but on its own environment, seamlessly. Please, if anyone has done that, or knows how to do it, and would be so kind to shed light on the subject, it would be greatly appreciated. Thanks and regards.
Jesús López gave me the answer at this MSDN thread, where I asked exactly the same question as in this StackOverflow’s thread.
First, he asked: “Is the [IIS] path to the workflow service (the xalmx file) the same in production than in development? If the path is different because the virtual directory is different then is also different the WorkflowHostType column and that might cause problems.”
After letting him know that IIS site names were actually different in production and in development environment, even though the rest of the paths to workflow services were the same, he replied: “Both [IIS sites] must have the same name. I've just tested it. I changed the site name in IIS and suddenly WorkflowHostType changed. So idle persisted workflows won't load any more.” Then he added: "Please see this post, it explains how WorkflowHostType is generated: Broken WF4 workflow rehydration".
And that did the trick! In my case, I only had to rename the IIS site name in development environment to exactly match the name of the IIS site name in production environment. Once our datacenter updated the WF4 instance store in the development database server with a copy of the instance store in the production database server, the development application correctly acquired the same WF4 state as the production application, because the copied workflows were correctly identified and loaded. At last, we can duplicate this system’s business data and WF4 state from production environment into development environment and investigate production issues without touching production data.
As Jesús helped me understand, the reason is: The full path of the IIS applications hosting WF4 workflow services (.xamlx files) must be exactly the same, including the IIS site name, if WF4 instance store databases are going to be copied between those applications (in different environments), because, apparently, the service filename, the site name and the path are all part of the WorkflowHostType column’s value calculation. That way, the value that the application looks for as the workflow host type for each idle persisted workflow will match the corresponding value in the WorkflowHostType column of the System.Activities.DurableInstancing.InstancesTable in the copied instance store database, allowing the system to correctly identify and reactivate those workflows from the data in the copied instance store database.
I hope this information can help some others going through the same situation I went. And if you believe this answer needs further clarification, please let me know.
Best regards, everyone.