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

Question

背景：

我们使用了大量的聚合、单例和多吨编排，类似于这里描述的塞鲁特回合罗宾技术(BizTalk，2009年)。

所有这些业务流程类型都有相当任意的退出点或延续点(用于聚合)，通常由计时器定义--即如果Orch在X分钟内没有收到任何更多的消息，则继续进行批处理，如果Y之后过了更多分钟而没有更多消息退出。(由于对大量消息后性能下降的担心，我们也退出了单个/N，在一段时间内订阅了单例)。

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

如果一条消息在其中一种订阅上导致僵尸，则该消息似乎也不适合其他订阅者(即，与“僵尸引起”编排完全解耦的兰花)，即导致僵尸的消息未被处理。

问题

因此，我非常感兴趣的是，是否有其他方法，无论是以编程方式还是其他方式，在业务流程“进展”之后，通过编程或其他方式，显式地从运行的业务流程中删除相关的订阅，而不是对这个相关的消息感兴趣。(这条新消息通常会启动一个新的业务流程，并具有其自身的相关性等)

此时，我们甚至会考虑一个黑客解决方案，比如反射的BizTalk API调用或针对MsgBoxDB的直接SQL。

Answer 1

不，不能在业务流程中显式删除订阅。

当业务流程自身崩溃时，订阅将被删除，但是到达该确切实例的消息将被路由到业务流程，但是业务流程将在不处理它的情况下结束，这就是您的僵尸。

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

我也曾经有过一个接收、剥离、聚合、发送模式。接收来自多个发件人的信封邮件，对它们进行破坏，由预期的收件人进行聚合(基于两条规则、消息数量或时间延迟，以先发生者为准)。这个场景对于僵尸来说是成熟的，当我读到它们的时候，我设计了它，所以它不会发生。这是在BizTalk 2004中，我删除了这些消息，并将它们插入数据库。我有一个存储过程，这个存储过程由一个接收端口轮询，如果有一个批处理要发送，它就会计算出，如果有，它将触发一个接收该消息并动态路由它的Orcher体外。由于两支乐队都不需要等待另一条消息，他们可以优雅地结束，不会有僵尸。