在 BizTalk 应用程序中运行时确定消息目标集
我是 BizTalk 的新手，我需要创建一个以特定方式广播消息的 BizTalk 2006 应用程序。我并不是在寻求完整的解决方案，而是寻求建议和指南，即我应该使用 BizTalk 的哪些功能。
为了简单起见，有一个消息源，例如，用户在其中添加文件以发布它们的目录。有多个订阅者，每个订阅者都有一个用于接收已发布文件的目录。订阅者的数量在程序的利用过程中可能会有所不同。还有一些规则根据文件名确定特定订阅者是否需要接收特定文件。例如，每个订阅者都有一个文件名模式或掩码，他们收到的文件必须匹配。这些规则（例如模式）也会随着时间而改变。
我不知道该怎么做。在运行时创建一组发送端口，每个端口对应每个目的地？是否可以？使用一个端口更改其绑定？并发发送时它能正常工作吗？还有其他方法吗？
编辑
我意识到我的问题可能过于晦涩和笼统，更喜欢一个答案而不是另一个答案。所以我只是对他们投了赞成票。
I’m a complete newbie at BizTalk and I need to create a BizTalk 2006 application which broadcasts messages in a specific way. I’m not asking for a complete solution, but for advise and guidelines, which capabilities of BizTalk I should use.
There’s a message source, for simplicity, say, a directory where the user adds files to publish them. There are several subscribers, each having a directory to receive published files. The number of subscribers can vary in the course of exploitation of the program. There are also some rules which determine if a particular subscriber needs to receive a particular file, based on the filename. For example, each subscriber has a pattern or mask of filename which files they receives must match. Those rules (for example, patterns) can change in time as well.
I don’t know how to do this. Create a set of send ports at runtime, each for each destination? Is it possible? Use one port changing its binding? Would it work correctly with concurrent sendings? Are there other ways?
EDIT
I realized my question may be to obscure and general to prefer one answer over another to accept. So I just upvoted them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您的订阅者确实是动态的，您可以考虑使用动态发送端口来实现此目的。这会带来一些复杂性，因为您需要使用编排根据您的规则配置发送端口的属性。
如果可以的话，尝试消除复杂性。如果您知道添加订阅者时不需要真正动态（即订阅者及其规则只能配置一次）并且您拥有可管理数量的订阅者，那么我建议使用每个订阅者自己的发送端口来配置它并使用过滤器根据消息上下文属性创建订阅。这种方法的优点在于，您不需要创建和部署编排，这将成为一个高性能且可扩展的解决方案。
You could look at using dynamic send ports to achieve this - if your subscribers are truly dynamic. This introduces a bit of complexity since you'll need to use an orchestration to configure the send port's properties based on your rules.
If you can, try and remove the complexity. If you know that you don't need to be truly dynamic when adding subscribers (i.e. a subscriber and it's rules can be configured one time only) and you have a manageable number of subscribers then I would suggest configuring each subscriber using it's own send port and use a filter to create subscriptions based on message context properties. The beauty of this approach is that you don't need to create and deploy an orchestration and this becomes a highly performant and scalable solution.
如果目的地经常发生变化，那么您寻求更动态的解决方案是正确的。一种不错的解决方案是使用动态发送端口和业务规则引擎。您为收到的消息创建规则集。这可以基于消息中的目标属性或客户 ID。使用这些事实，规则引擎可以返回一堆信息，例如文件掩码、服务器名称、发送服务器的 IP 地址等。然后您可以使用这些信息在编排中配置动态发送。这里真正好的一点是，您可以更新规则引擎中的规则集，而无需重新部署整个解决方案。作为一个新手，这些是一些高级概念，但并不像你想象的那么困难。
对于更简单的解决方案，您可能需要考虑通过其属性架构（即文件名、目录等）设置文件发送适配器属性。您可以使用表达式形状内的辅助类从数据库中提取这些值。在每条消息输出时，使用属性 shcema 来设置消息的发送位置和命名位置。这样，您只需在情况发生变化时更新数据库即可。
祝你好运！
If the changes to the destination are going to be frequent, you are right in seeking a more dynamic solution. One nice solution is using dynamic send ports and the Business Rules Engine. You create rule set for the messages you are receving. This could be based on a destination property or customer ID in the message. Using these facts, the rules engine can return a bunch of information like file mask, server name, ip address of deleiver server, etc. You can thenuse this information to configure the dynamic send in the orchestration. The real nice thing here is that you can update the rule set in the rules engine without redeploying the whole solution. As a newb, these are some advanced concepts, but not as diificult as you may think.
For a simpler solution, you might want to look at setting the FILE Send adapters properties via it's Propery Schema (ie. File name, Directory, etc.). You could pull these values from a database with a helper class inside an expresison shape. On each message ogig out, use the property shcema to set where the message will be sent and named. This way, you just update the database as things change.
Good Luck!