本部分介绍如何将模式图转换为 BizTalk Server 工件。
连接和完整性条件
我们几乎可以从任何位置开始，将模式转换为 BizTalk Server 组件。 但是，组件之间的连接实际上就是组件的基础结构，因此它似乎是一个很好的开始位置。 此外，在聚合器模式的情况下，我们需要考虑什么会告诉它，它具有它所需的所有信息。 这会影响其与其他组件的连接以及其设计。
解决方案需要提供方便且一致的使用方式。 服务接口指定其他应用程序如何使用它。 由于解决方案需要使用 IBM WebSphere MQ 与旧应用程序通信，因此 IBM WebSphere MQ 需要成为服务接口的一部分。 但是，对于较新的应用程序，Web 服务界面似乎是一个明显的选择。 Web 服务接口为使用该服务的其他应用程序提供最大的灵活性。 在这里，我们可以使用 BizTalk Server 的灵活性来提供双重服务接口。 有关将业务流程公开为 Web 服务的信息，请参阅 如何将业务流程映射到 Web 服务。
其他连接是服务接口与收件人列表、收件人列表和后端应用程序之间，以及后端应用程序、聚合器和服务接口之间的连接。
如果与收件人列表的连接是同步的，则解决方案不需要使用关联来确保向收件人列表发送和接收所有邮件。 后端应用程序与聚合器之间的连接可以同步，原因相同。 聚合器需要来自所有三个后端应用程序的响应来完成查询响应。 响应时间应较短，以便同步连接合适并简化解决方案。
在聚合器模式中，通常存在完整性条件。 如果有多个后端服务器和响应时间缓慢，则完整性条件可能是，例如，在给定时间段内至少接收一个响应。 此面向服务的解决方案需要所有三个响应才能构造最终消息。 因此，在这里，完整性条件是收到所有三个响应。
注释
通过 IBM WebSphere MQ 接收请求时，该解决方案通过将 MQMD_MsgId 值复制到响应消息 MQMD_CorrelId 来添加相关标识符。 这是使用 MQSeries 适配器进行请求-响应模式时的标准方法的一部分，以避免可能出现的竞态条件。 有关详细信息，请参阅 使用 Request-Reply 关联消息。
确定业务流程边界
该解决方案必须允许来自 IBM WebSphere MQ 队列以及通过 Web 服务接口发出的请求。 将服务接口放入一个编排中，将 IBM WebSphere MQ 输入至另一个中，并将主要处理放到第三个，使外部通信与处理相互独立。
将组件转换为协调模块
要转换为形状的模式将在最终解决方案中编排为单个整体。 在 BizTalk Server 中创建基于内容的路由器有多种方法，包括创建 MessageBox 订阅。 在解决方案中，路由使用 MessageBox 订阅。 表达式形状计算消息是否包含必填字段的值。 决策构造评估表达式构造中设置的变量，并通过编排流程选择路径。
CustomerService 业务流程使用并行形状将消息发送到后端应用程序并同时接收响应。 在发出下一个请求之前，它不必等待一个应用程序完成。 如果应用程序数量频繁更改，或者与应用程序的连接不可靠，则业务流程需要以不同的方式转换模式。
在解决方案中，聚合器必须合并来自三个响应消息的元素。 使用并行形状可确保与后端系统的通信是并行的。 而且，由于形状在收到所有响应或超时之前不会终止，聚合器将始终知道何时可以继续。 编排使用转换形状，将来自三个后端响应消息的元素和原始请求消息的元素映射到响应消息中的元素。
注释
与后端系统的通信也可能超时。可以通过将 “接收 ”形状括在 作用域 形状中并设置范围的 Timeout 属性来设置超时期限。
有关编排形状的完整列表，请参阅 编排形状。