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

我的问题与描述的相同：

我使用两种编排。第一个业务流程通过双向发送端口使用直接绑定调用第二个业务流程。第二个管弦乐队有一个双向接收端口，将结果发送回第一个管弦乐队。每件事都在正常工作，但我得到了以下例外

由于消息引擎无法将响应与现有请求消息关联，双向接收端口“未知”的响应消息正在挂起。这通常发生在主机进程被回收时。

建议的解决方案也很有效（在发送到直接绑定端口之前的第一个业务流程中，将BTS.EpmRRCorrelationToken值设置为一个随机值，即新GUID，然后在secod业务流程中，我将该值从inputMessage复制到outputMessage，因此该值保持不变。使用此方法，BizTalk知道如何将响应与c相关联aller）。但我不明白为什么会这样，以及这是否是解决问题的好方法。BTS.EpmRRCorrelationToken的流程如下所示：

---

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

在您的情况下，更改此属性肯定是可以的

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

---

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

我再次检查了解决方案，发现我甚至不需要在第二个编排中复制

BTS.EpmRRCorrelationToken

！我只需要在第一个业务流程中使用新生成的Guid填充

BTS.EpmRRCorrelationToken

。但是为什么？不确定您是否阅读了以下内容：。出于兴趣，为什么不使用输出消息调用第二个业务流程（可以，尽管耦合），或者只使用单独的发送和接收端口（以及您自己的关联）？我已经阅读了这篇文章，谢谢。我不想做额外的工作来设置相关性。我只想使用为消息类型\上下文设计的编排来拾取已发布的消息。例如，当我发布带有“NEW”的消息时状态，我希望此消息将由NewMessageOrchestration拾取和处理，而不是ProcessedMessageOrchestration或任何其他。