工作流程基础：从未完成延迟活动

让我们有一个工作流程，包括接收活动和延迟活动。接收活动有CanCreateInstance = true 并且还提供了查询（消息）关联。工作流托管在工作流服务中，并在闲置时立即保存到数据库中。工作流程基础：从未完成延迟活动

WorkflowService service = new WorkflowService 
{ 
    Name = "MyWorkflow", 
    Body = new MyWorkflow(), 
    Endpoints = 
    { 
    new Endpoint 
    { 
     ServiceContractName = "IMyWorkflow", 
     AddressUri = new Uri("http://localhost:1234/MyWorkflow"), 
     Binding = new BasicHttpBinding() 
    } 
    } 
}; 

WorkflowServiceHost host = new WorkflowServiceHost(service); 
string conn = "Data Source=...;Initial Catalog=..."; 
host.DurableInstancingOptions.InstanceStore = new SqlWorkflowInstanceStore(conn); 
host.Open();

现在我将消息发送到工作流和运行时创建的第一个工作流实例。相关密钥当然包含在消息中。工作流继续延迟活动并保存到数据库并卸载。

我们假设延迟时间足够长，然后我将发送下一条消息，并使用完全相同的相关密钥。怎么了？这两种工作流程都不会从延迟中醒来，也从未完成。

我该怎么做？为什么工作流运行时不能保护我免受此影响？有什么办法可以拯救这两个工作流程实例吗？

感谢您的帮助！

来源

2010-06-04 Petr Felzmann

如果使用消息关联，消息中的键值必须与单个活动工作流匹配。如果您尝试使用相同的密钥启动第二个工作流程，您将在尝试启动新实例时收到异常。现在，如果您仅使用没有SendReply的接收，则您正在创建单向消息传送方案，并且无法将SOAP错误发送回客户端。所以客户可能不知道这个错误。如果您在服务中启用跟踪并检查日志文件，仍然可以看到这一点。然而，更简单的选择是包含一个SendReply，即使你没有正常的响应，因为这会产生一个可以包含错误消息的响应消息。

来源

2010-06-04 08:10:16 Maurice

好的，明白，谢谢！目前还不清楚我该如何拯救这些工作流程。我可以看到这两个工作流都保存在数据库中。有没有什么办法可以从代码中访问这些工作流程并做些事情，例如删除它们能否再次正确使用相关键？ – 2010-06-04 10:13:05

或者，也许我的解决方案是不立即设置工作流程持久性，但延迟活动启动时。然后，工作流向我发送异常，但不会自行保留。你能确认我说得对吗？ – 2010-06-04 10:27:16

消息关联与持久性无关。第一种是将消息路由到特定的工作流实例，第二种是关于保存状态并能够从内存中删除工作流。消息关联将与内存中的工作流实例完全一样。 – Maurice 2010-06-04 11:45:14

工作流程基础：从未完成延迟活动

回答

相关问题