在WF4中从生产服务器复制实例存储数据库到开发服务器的正确方法是什么？我们在AppFabric和IIS上使用Windows Workflow Foundation 4有一个应用程序。我们有一台机器，SQL Server 2008 R2托管我们用于生产环境的实例存储数据库，还有一台单独的机器，也有SQL Server 2008 R2，托管我们用于开发环境的实例存储数据库。现在，我们需要将生产环境中的确切状态复制到开发环境中。对于简单的业务数据库，我只是要求我们的数据中心备份开发业务数据库（Oracle服务器），然后用生产数据库的副本（单独的机器）完全替换开发业务数据库。我想也许使用我们的WF4实例存储数据库可以使用相同的方法。
但事实证明它没有。在复制之后，在开发环境中运行应用程序，每当它尝试恢复实例书签或调用属于已启动工作流的实例操作时，我们就会在服务实例上获得带有标识符'的'Operation'[operation name]' [guid]'此时无法执行。请确保以正确的顺序执行操作，并确保使用中的绑定提供有序的传递保证“异常消息。
另一方面，如果我们开始一个新的工作流程，它可以正常工作，并可以毫无困难地继续到最后。通过简要查看System.Activities.DurableInstancing.InstancesTable，在我看来，在复制之后，无法正确识别以前的工作流实例，并且WF4尝试启动新的实例，这导致“操作顺序不正确”事情。例如，这些新创建的实例与从生产中复制的实例中的实例具有非常不同的ServiceDeploymentId ID。但我对WF4的经验非常少，对于发生的事情我几乎一无所知。 （在创建此帖子之前，我确实从StackExchange和其他来源搜索了答案。）
我们如何创建生产WF4实例存储的副本，一旦在我们的开发服务器中，它将与开发环境中的应用程序一起使用，因为它具有与生产相同的应用程序状态？感谢。
再次问好。我想知道为什么到目前为止这篇文章没有评论。事实上，使用来自生产环境的数据更新开发或QA环境中的数据是非常常见的事情。而且我几乎可以肯定，这也是通过WF4工作流程来定期完成的。这是将WF4工作流的状态从一个数据库服务器（生产）复制到另一个数据库服务器（QA或开发）的问题，这样在QA或开发环境中运行的应用程序可以“获得”与生产服务器相同的应用程序状态，从那里可以继续推进和使用从生产中复制的工作流程，但无缝地在自己的环境中工作。如果有人这样做，或者知道如何做到这一点，并且会非常友好地阐明这个主题，那将非常感激。谢谢和问候。
答案 0 :(得分：2)
Jesús López在MSDN thread给了我答案，我在这里问了与StackOverflow主题相同的问题。
首先，他问：“工作流服务（xalmx文件）的[IIS]路径在生产中是否与开发中相同？如果路径不同，因为虚拟目录不同，那么WorkflowHostType列也会有所不同，这可能会导致问题。“
让他知道IIS 站点名称在生产和开发环境中实际上是不同的，即使工作流服务的其他路径是相同的，他回答说：“两个[IIS站点] ] 必须具有相同的名称。我刚试过它。我在IIS中更改了站点名称，突然改变了WorkflowHostType。因此，闲置的持久化工作流程将不再加载。“然后他补充说：”请参阅此文章，它解释了如何生成WorkflowHostType：Broken WF4 workflow rehydration“。
这就是诀窍！在我的例子中，我只需要在开发环境中重命名IIS站点名称，使其与生产环境中的IIS站点名称完全匹配。一旦我们的数据中心使用生产数据库服务器中的实例存储副本更新了开发数据库服务器中的WF4实例存储，开发应用程序就会正确获取与生产应用程序相同的WF4状态，因为已正确识别并加载了复制的工作流。最后，我们可以将该系统的业务数据和WF4状态从生产环境复制到开发环境中，并在不触及生产数据的情况下调查生产问题。
正如Jesús帮助我理解的那样，原因是：托管WF4工作流服务（.xamlx文件）的IIS应用程序的完整路径必须完全相同，包括IIS站点名称，如果要在这些应用程序之间（在不同的环境中）复制WF4实例存储数据库，因为，显然，服务文件名，站点名称和路径都是 WorkflowHostType列的值计算。这样，应用程序查找的值作为每个空闲持久工作流的工作流主机类型将匹配System.Activities.DurableInstancing.InstancesTable的WorkflowHostType列中的相应值。在复制的实例存储数据库中，允许系统从复制的实例存储数据库中的数据中正确识别和重新激活这些工作流。
我希望这些信息可以帮助其他人解决我遇到的同样情况。如果您认为此答案需要进一步澄清，请告诉我。
最好的问候，大家。