BizTalk Zombies - 从BizTalk业务流程中明确删除订阅的任何方法

Question

背景:

我们使用了许多聚合,单例和多元编排,类似于此处描述的Seroter循环技术(BizTalk 2009).

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

尽管我们试图通过在异步重构编排中启动任何延续处理来减轻僵尸,但总有一个弱点,即"好"的定时消息可能会导致僵尸.(即接收与业务流程的"已完成"形状相关的更多传入消息),

如果消息在其中一个订阅上导致僵尸,则该消息似乎不会传播给OTHER订户(即,orchs与'zombie cause'业务流程完全解耦),即不处理导致僵尸的消息.

题

因此,一旦业务流程"进展"超出了对此相关消息感兴趣的点,我就会非常感兴趣地看看是否有人以其他方式(以编程方式或其他方式)从正在运行的业务流程中显式删除相关订阅.(这个新消息通常会启动一个新的业务流程,并具有自己的相关性等)

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

Answer 1

不，您无法显式删除业务流程中的订阅。

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

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

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