背景:
我们利用了大量的聚合，单例和多例编排，类似于此处描述的Seroter's Round Robin技术(BizTalk 2009)。
所有这些业务流程类型都具有相当随意的退出点或延续点(用于聚合)，通常由计时器定义-即，如果Orch在X分钟内没有收到更多消息，则继续进行批处理，如果在Y之后再进行几分钟已用完，再也没有消息退出。 (由于担心degraded performance after large numbers of messages在一段时间内订阅了单例，因此我们也退出了Single/N-Tons)。
尽我们所能减轻例如僵尸等通过在异步重构业务流程中启动任何继续处理，总是存在一个弱点，即“时间”适时的消息可能会导致僵尸。 (即，接收更多与业务流程的“已完成”形状相关的传入消息)，
如果消息导致其中一个订阅中的僵尸出现，则该消息似乎也不会传播给其他订阅者(即Orchs与``导致僵尸的业务流程''完全分离)，即未处理造成僵尸的消息。
问题
因此，我很想知道一旦有人“编排”超出了对该相关消息感兴趣的程度，是否有人可以通过编程或其他方式从正在运行的业务流程中明确删除相关订阅。 (然后，该新消息通常会使用其自身的相关性来开始新的业务流程等)
在这一点上，我们甚至会考虑采用一种黑客解决方案，例如反射的BizTalk API调用或针对MsgBoxDB的直接SQL删除。
最佳答案
不，您不能在业务流程中显式删除订阅。
随着业务流程的崩溃，订阅将被删除，但是到达该确切实例的消息将被路由到业务流程，但是业务流程将在不进行处理的情况下结束，这就是您的僵尸。
Microsoft有关僵尸的文章http://msdn.microsoft.com/en-us/library/bb203853.aspx
我曾经还必须有一个接收，分批，汇总，发送模式。从多个发件人接收信封邮件，将它们分批处理，然后按预期的收件人进行汇总(基于两个规则，邮件数量或时间延迟，以先到者为准)。
对于僵尸来说，这种情况已经成熟，当我阅读有关僵尸的信息时，我对其进行了设计，因此不会发生。这是针对BizTalk 2004的
我对消息进行了分批处理，然后将它们插入数据库中。我有一个存储过程，该过程由接收端口进行轮询，如果有要发送的批处理，它将进行处理，如果有要发送的批处理，则会触发Orcherstration，该Orchestration将接收该消息并动态路由它。
由于两个业务流程都不必等待其他消息，因此它们可以优雅地结束，并且不会有僵尸。
关于BizTalk Zombies-从BizTalk业务流程中显式删除订阅的任何方式，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7483910/