双向接收端口直接绑定的 BizTalk 中的异常

Posted 2023-02-24

【中文标题】双向接收端口直接绑定的 BizTalk 中的异常

【英文标题】：Exception in BizTalk with Two-Way receive port direct binding

【发布时间】：2011-10-26 11:13:52

【问题描述】：

我遇到了和here描述的一样的问题：

我正在使用两个编排。第一个编排通过双向发送端口使用直接绑定调用第二个编排。第二个管弦乐队有一个双向接收端口将结果发送回第一个。一切正常，但我收到以下异常。

A response message for two-way receive port "Unknown " is being suspended as the messaging engine could not correlate the response to an existing request message. This usually happens when the host process has been recycled.

建议的解决方案也有效（将 BTS.EpmRRCorrelationToken 值设置为随机值，在我的情况下为新 GUID，在发送到直接绑定端口之前的第一个编排中，然后在我复制的第二个编排中从 inputMessage 到 outputMessage 的值，因此该值保持不变。通过这种方法，BizTalk 知道如何将响应关联回调用者）。但我不明白为什么这会奏效，以及这是否是解决问题的好方法。 BTS.EpmRRCorrelationToken 流程如下：

当我不更改 BTS.EpmRRCorrelationToken 属性时，它在流程中流动的所有消息中都是相同的，但是如果 BizTalk 不能正确关联消息，为什么不更改它呢？

【问题讨论】：

我再次检查了解决方案，发现我什至不需要在第二个Orchestration中复制BTS.EpmRRCorrelationToken！我需要做的只是在第一个编排中使用新生成的 Guid 填充BTS.EpmRRCorrelationToken。但为什么呢？

不确定你是否读过这篇文章：bveldhoen.wordpress.com/2010/09/05/…。出于兴趣，为什么不使用输出消息调用第二个编排（好的，尽管是耦合的），或者只使用单独的发送和接收端口（以及您自己的关联）？

我已经阅读了这篇文章，谢谢。我不想做额外的工作来建立相关性。我只想使用专为消息类型\上下文设计的编排来获取已发布的消息。例如，当我发布一条状态为“NEW”的消息时，我希望这条消息将由 NewMessageOrchestration 而不是由 ProcessedMessageOrchestration 或任何其他人接收和处理。

【参考方案1】：

在您的情况下，更改此属性肯定没问题。

问题是直接绑定。当你使用它时，你实际上会走更“低级”的方式，并且必须处理 BTS 发布-订阅机制的工作原理。

发送-接收端口订阅接收带有特定 BTS.EpmRRCorrelationToken 的消息。因此，当您再次在消息框中（对于第二个管弦乐队）发布接收消息时，接收端口也会抓住它并取消订阅。当您最终尝试发送响应时 - 没有人在等待它。因此，您必须更改该属性，直到您将响应发送回端口。