为什么双向发送端口不处理响应？

如何解决为什么双向发送端口不处理响应？

我们有一个双向接收端口'ReceivePort1'，接收消息类型为MessageA。

双向发送端口“SendPort1”订阅 MessageA 并将其发送到休息服务“MyRestService”。

rest 服务返回消息类型 MessageB 的响应，其中一个元素被提升为 'PropertyA'，值为 '1'

双向发送端口'SendPort2'订阅了PropertyA=1的MessageB，并将其发送到同一个rest服务'MyRestService'。

rest 服务返回消息类型 MessageB 的响应，其中一个元素被提升为 'PropertyA'，值为 '2'

单向发送端口“SendPort3”订阅 MessageB，Property=2 并通过 SMPT 发送。

本质上，流程是ReceivePort1 -> SendPort1 -> SendPort2 -> SendPort3。

问题在于，BizTalk 永远不会使用 SendPort2 收到的响应。使用 fiddler，我们可以看到服务返回了响应，但是我们没有跟踪信息、没有消息、没有事件日志错误来表示 BizTalk 曾经看到过它。我们甚至尝试调试发送端口上的接收管道，并且管道永远不会传递响应消息。我们已经尝试在 SendPort2 的接收管道中使用 passthrough、xmlreceive 和我们自己的自定义管道，但似乎都没有从其余服务传递响应。双向发送端口链在这里有意义吗？ BizTalk 是否在做一些我不知道的事情？

编辑 1：

作为测试，我简化了场景，SendPort3 从单向文件接收端口接收文件，并且成功了。文件端口上的接收管道与 Sendport2 上的接收管道相同。下一个测试是让 SendPort2 从单向文件接收端口接收文件。

编辑 2：

SendPort2 从一种文件接收方式接收文件，一切正常。我们发现在原来的双向ReceivePort1 -> Two Way SendPort1 -> Response -> Two Way SendPort2 -> Response -> SendPort3的场景中，当我们检查SendPort3的请求端的管道时，IsSolicitResponse上下文属性为false。此属性指示 wcf 适配器是否期望返回响应。我们还不知道 IsSolicitResponse 在链中的哪个位置被设置为 false。