Workflow FoundationExternalDataExchange 消息已排队且具有事务性？

Question

我最近一直在 WF 中使用一些基于ExternalDataExchange 的通信。 我的理解是，当使用长期运行的（在本例中为状态机）工作流时，通信是排队的、持久的和事务性的。

我正在使用 SQL Persistence 和标记为“WaitForIdle = true”的 EventArgs。

我会假设当我做这样的事情时：

using(TransactionScope scope = new TransactionScope())
{
     IMyEDEService service = wfRuntime.GetService<IMyEDEService>()
     service.MyMethod(wfInstanceGuid, "Here's some data");
     DoSomeDatabaseWork();
} //Dispose causes scope to rollback

我希望我的事件不会在工作流程中触发。 不过，它似乎确实已交付，因此这让我相信这不是事务性的。 您可以看到在 DoSomeDatabaseWork() 中提交到数据库的数据如何回滚，但向前推进的工作流程可能会很糟糕。

任何人都可以确认这一点吗？如果是的话，您是否有解决方法使该消息成为事务性消息？

我真正想要的是这两件事之一：

1. 工作流不应该对我通过外部数据交换排队的消息做出反应，直到提交消息排队的事务（就像 SQL Server 中的服务代理所做的那样）。

--或者--

2. 如果工作流确实开始对我交付的事件起作用，它也应该回滚。 不过，我不明白使用默认调度程序如何会发生这种情况。 我希望工作流程执行保持异步，因此如果不需要，我不想切换调度程序。

Answer 1

这里有几个问题。 首先，当您使用 SQL 持久性时，通知事件工作流并让工作流发布事件是持久且异步的，并且工作流的底层管道是事务性的......但不是您想象的那样。

如果事件序列中的某个地方发生了可怕的事情，最终导致您的工作流程转换到新状态，那么工作流程将恢复到尝试该活动之前的状态 - 这使工作流程保持一致的状态，因为“国家之间”是个坏主意。

像上面那样使用事务作用域是可以的，但是您必须记住，事务作用域真正起作用的唯一时间是当 using 块中的类知道事务作用域时。

您可以做的是将“MyMethod”的调用包装在 try/catch 块中。 当出现问题时，您可以投票支持回滚...但这仍然不会“取消调用”您的 EDES 上的方法。

如果您可以提供一些关于您想要在更高级别上完成的任务的具体信息，那么 WF 固有的一些东西可能比试图将事务范围强加到组合中更适合您。

编辑

我做了一些挖掘，发现了几个不同的地方，我们被告知没有 API 来操作调度程序工作队列。 不幸的是，对我们来说，这意味着我们想要的任何类型的回滚行为都必须自己手动实现。

如果我更多地了解您为什么尝试回滚通过 EDES 排队的工作，我也许能够建议一些潜在的架构来完成您的任务，而无需重新发明轮子（事务）。

当我遇到这样的问题时，十分之九，看起来 WF 不支持我想要做的事情，问题是因为我在外部保留了太多代码工作流程或试图在其中放入太多代码，并且重构我的工作完成位置通常可以解决我的问题，而不需要我编写新的东西。