BizTalk Zombies - 从 BizTalk 编排中显式删除订阅的任何方式

Question

背景:

我们使用了很多聚合、单例和多例编排，类似于 Seroter's Round Robin此处描述的技术(BizTalk 2009)。

所有这些编排类型都有相当任意的退出或延续点(用于聚合)，通常由计时器定义 - 即如果 Orch 在 X 分钟内没有收到更多消息，则继续批处理，如果在 Y 分钟后继续已经过去，没有更多消息然后退出。 (由于担心 degraded performance after large numbers of messages 在一段时间内订阅了单件，我们也退出了我们的单件/N-Tons)。

尽管我们试图减轻僵尸的影响，例如通过在异步重构的编排中启动任何延续处理，总是存在一个弱点，即“及时”的消息可能导致僵尸。 (即接收更多与编排的“已完成”形状相关的传入消息)，

如果消息在其中一个订阅上导致僵尸，则该消息似乎也不会传播给其他订阅者(即 orchs 与“僵尸导致”编排完全分离)，即不会处理导致僵尸的消息。

问题

所以我很想知道是否有人有另一种方式，以编程方式或其他方式，一旦编排已经“进展”到超出它对该相关消息感兴趣的程度，就可以从正在运行的编排中明确删除相关订阅。 (然后，此新消息通常会使用自己的相关性等开始新的编排)

在这一点上，我们甚至会考虑一个黑客解决方案，例如反射的 BizTalk API 调用或针对 MsgBoxDB 的直接 SQL 删除。

Answer 1

不，您不能在业务流程中明确删除订阅。

当 Orchestration 自行拆除时，订阅将被删除，但到达该确切实例的消息将被路由到 Orchestration，但 Orchestration 将结束而不处理它，这就是你的僵尸。

微软关于僵尸的文章 http://msdn.microsoft.com/en-us/library/bb203853.aspx

我曾经也必须有一个接收、分批、聚合、发送模式。从多个发件人接收封装的消息，对它们进行分批，按预期收件人聚合(基于两个规则，消息数量或时间延迟，以先发生者为准)。
这种情况对于僵尸来说已经成熟了，当我读到它们时，我设计了它，所以它不会发生。这是用于 BizTalk 2004
我对消息进行了分批处理，并将它们插入到数据库中。我有一个由接收端口轮询的存储过程，如果有一个批次要发送，它会触发一个接收该消息并动态路由它的 Orcherstration。
由于两个 Orchestration 都不必等待另一条消息，因此它们可以优雅地结束，并且不会有僵尸。