Biztalk 发送端口组和过滤答案

【问题标题】：Biztalk Send Port Group and FilteringBiztalk 发送端口组和过滤
【发布时间】：2009-03-03 22:45:19
【问题描述】：

所以我的解决方案需要的模型如下：

我需要轮询数据库并根据结果创建对数据库的请求以获取更多数据，获取响应并将其传递给一组端口，基于提升的属性，只有一个端口会行动的。

看起来像这样：

但是，如果您将“临时输出”分配给发送端口组，则消息将发送到该组中的所有端口，而与每个端口上设置的过滤器无关。据我了解，这是预期行为（阅读here）。

所以我探索了其他选项，例如在 SDK 中使用基于内容的路由（CBR 示例）。您可以查看此here。

我试过这个并完全删除了编排（它真的不需要）。但是，存在重大的路由/订阅错误，经过进一步研究，如果您有请求响应端口，您似乎无法做到这一点。关于 here 的一些文章。我和this用户几乎有同样的问题。

最后，我是否使用编排对我来说并不重要。但是，我需要一种解决方案，在该解决方案中，我可以将消息传递到多个发送端口，并且我只能让一个实际使用消息并发送。这是必要的，这样我就可以轻松地编辑和添加端口，而无需在编排中修改任何其他内容或硬代码决策。

【问题讨论】：

【解决方案1】：

您可以在编排的发送端口上使用Direct Binding 将消息注入回消息框数据库。使用多个端口组，每个端口组可以直接订阅所需的消息类型并过滤提升的属性。

【讨论】：

在某种程度上我找到了解决方案。我删除了编排，提升了属性，并在第二个和第三个端口上，将过滤器放在了我定义 BTS.SPName 的位置（我认为这是存储过程名称，但现在理解为发送端口名称）。路由问题是因为我没有完全订阅它们。

【解决方案2】：

我发现 CBR 示例模型确实有效。路由的问题在于订阅。如果我要将发送端口订阅到请求响应端口，我必须设置 BTS.SPName（发送端口名称）过滤器而不是 BTS.ReceivePort 过滤器。通过这样做，消息被正确过滤。你的答案也可以，但它需要使用我试图避免的编排。

【讨论】：