背景
我们使用了很多聚合，单例和多元编排，类似于此处描述的Seroter's Round Robin技术（BizTalk 2009）。
所有这些业务流程类型都有相当任意的退出或延续点（对于聚合），通常由定时器定义 - 即如果Orch在X分钟内没有收到任何更多的消息，那么继续进行批处理，如果之后Y更多分钟已经过去，没有更多消息然后退出。 （由于担心degraded performance after large numbers of messages在一段时间内订阅了单身人士，我们也退出我们的单/ N-Tons。
尽管我们试图减轻僵尸，例如通过在异步重构编排中启动任何延续处理，总会存在一个弱点，即“正常”的定时消息可能导致僵尸。 （即接收与业务流程的“已完成”形状相关的更多传入消息），
如果消息在其中一个订阅上导致僵尸，则消息似乎不会传播给OTHER订阅者（即orchs与'zombie cause'业务流程完全解耦），即僵尸导致的消息未被处理
问题
因此，一旦业务流程“进展”超出了对此相关消息感兴趣的点，我就会非常感兴趣地看看是否有人以其他方式（以编程方式或其他方式）从正在运行的业务流程中显式删除相关订阅。 （这个新消息通常会启动一个具有自己相关性的新业务流程等）
此时我们甚至会考虑一个黑客解决方案，例如反映的BizTalk API调用或针对MsgBoxDB的直接SQL删除。
答案 0 :(得分：1)
否则您无法在业务流程中明确删除订阅。
当Orchestration正在撕毁时，订阅将被删除，但是到达该确切实例的消息将被路由到Orchestration，但Orchestration将在不处理它的情况下结束，那就是你的Zombie。
微软关于僵尸的文章http://msdn.microsoft.com/en-us/library/bb203853.aspx
我曾经不得不接受，发送，汇总，发送模式。接收来自多个发件人的封套邮件，对其进行报告，按预期收件人汇总（基于两条规则，邮件数量或时间延迟，以先发生者为准）。 僵尸的这种情况已经成熟，当我读到它们时，我设计它就不会发生。这是BizTalk 2004 我谴责了这些消息，并将它们插入到数据库中。我有一个由接收端口轮询的存储过程，如果有一个批处理要发送，如果它会触发一个可以接收该消息并动态路由它的Orcherstration，那么这个存储过程就可以解决。 由于两个Orchestration都不得不等待另一个消息，他们可以优雅地结束，并且没有Zombies。