7

我最近遇到了一个非常奇怪的问题，即删除通知。这是场景：

  • 我有一个编排，它将消息发送到配置为传递通知 = 已传输的单向发送端口（顺便说一句，发送端口使用 FTP 适配器，但我认为适配器是什么并不重要）。

  • 当出现消息传递错误时，该错误被编排捕获（因此意味着传递通知机制按预期工作），它执行一些日志记录，然后以编程方式终止（终止形状）。消息传递实例仍然存在并且被挂起和恢复。

  • 在解决了导致消息传递错误的问题后，我恢复了暂停的消息传递实例。

在这一点上，我得到了 2 个非常可疑的消息传递实例：ACK 的路由失败并且消息传递实例仍然处于活动状态（但什么也不做......）。我确信路由失败实例是与活动消息传递实例相关的传递通知，因为它们具有相同的 CorrelationToken。更多细节：如果我终止活动实例，它会被挂起（不可恢复），并且错误消息说实例完成但没有消耗所有消息！

最后但并非最不重要的一点是，我只在某些环境中遇到这个问题......

更新：似乎问题出现在运行 BizTalk 2006 R2 SP1 的 BizTalk 盒子上。在没有 SP1 的情况下运行 BizTalk 2006 R2 的机器上从未出现过这种情况。我会尽快确认

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

4

1 回答 1

1

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

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

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

于 2013-04-03T14:11:23.427 回答