我最近遇到了一个非常奇怪的删除通知问题。这是场景：
我有一个编排，它将消息发送到配置了发送通知的单向发送端口=已发送（顺便说一下发送端口使用FTP适配器，但我认为适配器是什么并不重要） ）。
当出现消息传递错误时，业务流程会捕获错误（因此意味着传递通知机制按预期工作），这会执行一些日志记录，然后以编程方式终止（终止形状）。消息传递实例仍然存在，并且可以暂停和恢复。
解决导致邮件错误的问题后，我恢复了挂起的邮件实例。
此时我收到2个非常可疑的消息传递实例：ACK和消息传递实例的路由失败仍然有效（但什么都不做......）。我确信路由失败实例是与活动消息传递实例相关的传递通知，因为它们具有相同的CorrelationToken。 还有一个细节：如果我终止活动实例，它将被挂起（不可恢复），并且错误消息表明实例已完成而没有消耗所有消息！
最后但同样重要的是，我仅在某些环境中遇到此问题......
更新：似乎问题出现在运行BizTalk 2006 R2 SP1的BizTalk框上。它从未出现在运行没有SP1的BizTalk 2006 R2的盒子上。我会尽快确认这个
更新2 ：我上次更新时看起来是对的：安装SP1 CU1后出现问题...下一步：我将尝试查找以下其中一个CU是否更正了问题
答案 0 :(得分：1)
实际上没有CU纠正所描述的问题。但还有更多：似乎所有较新的BizTalk版本都关注：我已经在BizTalk 2009上测试了所有CU和BizTalk 2010以及所有CU，问题仍然存在!!!
我找到的唯一解决方案是创建一个订阅所有传递通知的业务流程...不是很干净，但它完成了工作 - 至少大部分工作。
事实上，当您使用投放通知 为失败的消息启用路由时，我发现了另外一个问题：AckRequired属性和相关令牌被复制到路由失败消息，这意味着如果发送端口（例如：ESB异常发送端口）使用此失败消息，则将发布ACK，并且如果该ACK仍在执行，则该ACK可以路由到原始业务流程。如果是这样，那将以经典的 zombie message 情况结束，因为业务流程不会消耗此ACK！ 现在，尝试向您的客户解释您的开发人员不应受到责备......：p