在Biztalk中从不同的接收位置路由相同消息类型的消息

Question

我有一个简单的场景，我必须将消息从一个文件夹路由到另一个文件夹。现在，这些消息可以来自10个不同的来源（文件夹），并且将被路由到10个不同的位置（文件夹）。

例如。考虑SourceA, SourceB, SourceC ...是接收位置，DestA, DestB, DestC，...是目的地位置。

因此，来自SourceA的文件将路由到DestA，依此类推。

现在，我已经实现了这个场景。 我的问题是什么是最好的方法呢？

1）一个接收端口，具有10个接收位置，逻辑接收端口与物理端口绑定。一个监听形状将监听该消息，并且在执行单独的任务之后，将路由到相应的位置。可能还有单独的编排，因为可能必须为每个传入消息执行特定任务。

2）10个接收位置，其中所有消息都发布到消息框，并在业务流程中有一个动态逻辑接收端口。

主要问题是来自源位置的单独消息应仅路由到相应的目标位置。

注意：消息类型＆amp;这些位置的数据也可以完全相同。因此，基于某些数据字段的路由是不可能的。

如果您需要更多说明，请与我们联系。

Answer 1

在这种情况下，最好的答案是最简单的。

• 10个接收端口/位置
• 10发送端口

发送端口过滤器基于BTS.ReceivePortName。

Answer 2

如果没有要路由的数据属性，则需要一个可以路由的上下文属性。根据Johns-305的回答，如果只有没有Orchestrations的消息传递，你可以使用BTS.ReceivePortName。但是，如果您拥有Orchestration，则要么必须确保持久保存BTS.ReceivePortName，要么使用其他提升的上下文属性。

我们更喜欢使用 BTS.Operation 的上下文属性，因为它会自动提升，可以通过以下方式之一进行设置。

• 在WCF-WebHttp中通过Http方法和URL映射接收位置
• 在WCF-WSHttp中通过它的操作
• 通过让BRE管道组件设置操作来实现其他端口。
• 来自逻辑端口的操作名称设置的业务流程。

Answer 3

如果真的是1-1路由场景，我的投票将转到Johns-305，这意味着rcvLocation A将始终路由到目的地A - 然后只是扩展您的接收位置以分离接收端口并订阅发送端口相应

现在，如果您正在进行内容驱动的路由，意味着消息中的某些内容决定了消息的去向，那么您可以执行编排路径...但这可能是过度的。我将为flatfile创建一个模式，使用属性模式提升将用于路由消息的任何字段，并将发送端口订阅到该模式。

希望这有帮助！