BizTalk - 传递通知上的路由失败

Question

我最近遇到了一个非常奇怪的删除通知问题.这是场景:

• 我有一个编排,它发送一个消息给单向发送端口配置了发送通知=已发送(顺便说一下发送端口使用FTP适配器,但我认为适配器是什么并不重要).

• 当存在消息传递错误时,业务流程会捕获错误(因此意味着传递通知机制按预期工作),这会执行一些日志记录,然后以编程方式终止(终止形状).消息传递实例仍然存在,并且可以暂停和恢复.

• 解决导致消息传递错误的问题后,我恢复了挂起的消息传递实例.

此时我收到2个非常可疑的消息传递实例:ACK和消息传递实例的路由失败仍然有效(但什么都不做......).我确信路由失败实例是与活动消息传递实例相关的传递通知,因为它们具有相同的CorrelationToken.还有一个细节:如果我终止活动实例,它将被挂起(不可恢复),并且错误消息表明实例已完成而不消耗其所有消息!

最后但并非最不重要的是,我只在某些环境中遇到此问题...

更新:似乎问题出现在运行BizTalk 2006 R2 SP1的BizTalk框上.它从未出现在运行没有SP1的BizTalk 2006 R2的盒子上.我会尽快确认这一点

更新2:我在上次更新时看起来是对的:安装SP1 CU1后出现问题...所以下一步:我将尝试查找以下CU之一是否可以解决问题.

Answer 1

实际上没有 CU 纠正所描述的问题。但还有更多：似乎所有较新的 BizTalk 版本都受到关注：我已经对带有所有 CU 的 BizTalk 2009 和带有所有 CU 的 BizTalk 2010 进行了测试，问题仍然存在！

我发现的唯一解决方案是创建一个订阅所有传递通知的编排......不是很干净，但它完成了工作 - 至少是大部分工作。

事实上，当您为带有传递通知的失败消息启用路由时，我还发现了 1 个问题：AckRequired属性和相关令牌被复制到路由的失败消息中，这意味着如果此失败消息被发送，则将发布 ACK由发送端口（例如：ESB 异常发送端口）使用，并且如果原始编排仍在执行，则可以将该 ACK 路由到原始编排。如果是这样，这将导致典型的僵尸消息情况，因为编排不会消耗此 ACK！现在，尝试向您的客户解释您的开发人员不应该受到指责......：p