OrderBroker 业务流程中的处理
本部分介绍 OrderBroker 业务流程如何获取订单并为进程管理器做好准备。 本部分首先介绍了该业务流程的日常工作。 随后的部分将介绍该业务流程如何处理消息。 然后，将重点介绍该业务流程如何使用原子事务来提高性能。
注意
由于 OrderBroker 代码的长度，可能需要在 Microsoft® Visual Studio 中打开业务流程的情况下阅读本部分。
为什么使用 OrderBroker？
OrderBroker 业务流程的目的是预处理订单并将其路由到正确的进程管理器。 上述预处理包括为历史记录数据库、服务系统以及确认订单的接收生成信息性消息。 OrderBroker 还会根据客户服务请求创建一般订单消息。 这种订单规范化允许订单通用于业务流程的各个元素。
订单消息是包含独立于订单信息的路由信息的多部分消息。 路由信息也是通用的，其设计为可供任何订单管理器使用。 从而，可以更方便地扩展解决方案。 有关多部分消息的信息，请参阅 如何使用多部分消息类型。
通过将执行 Broker 功能与其他功能相隔离，您也可以将该功能移至其他 BizTalk 组。 由于 OrderBroker 发布到 MessageBox 数据库（即，它是直接绑定的），因此还可以更轻松地将代理放入另一个组，因此无需更改业务流程即可移动代理。 有关将 OrderBroker 放入另一个组的详细信息，请参阅 OrderBroker 和 OrderManager 之间的通信。
注意
OrderBroker 业务流程，因为它只有一个要与之通信的 OrderManager，因此只需为订单管理器消息中的 OrderMgrType 字段分配一个常量字符串。 通常，在存在多个订单管理器的应用程序中，该应用程序将使用业务规则引擎来确定此字段的适当值和订单路由。 有关业务规则引擎的详细信息，请参阅 创建和使用业务规则。
订单处理
OrderBroker 业务流程从侦听形状中的两个 Receive 形状开始。 一个 接收 形状接受来自客户支持系统的消息;另一个是来自供应商系统的消息。 来自任一来源的消息都具有相同的架构。
业务流程从消息中提取返回地址，并使用它设置动态端口 CSRPort 的地址。 该业务流程使用此端口来发送确认和错误消息。
OrderBroker 业务流程中的后续步骤将创建要发送到 OrderManager 业务流程的历史记录消息、服务消息、确认消息和订单消息。 业务流程使用 InsertOrderBody 实用工具函数将订单消息添加到历史记录消息。
注意
在某些情况下，解决方案可能会生成已传送但未使用的消息。 OrderBroker 业务流程使用发送端口将信息插入历史记录数据库中。 此发送端口使用送达通知。 配置将发送端口映射到包含两个端口的发送端口组-一个端口用于测试配置 (HistoryInsert-Test-SP) ，一个用于常规配置 (HistoryInsert-SP) 。 如果将该组中的两个端口都保持运行状态，则解决方案将在这两个端口上发送消息。 因而，该解决方案将请求两个送达通知，但仅处理其中一个通知。
若要避免这种情况，请取消列出测试端口 (HistoryInsert-Test-SP) ，或停止应用程序的测试版本 BTSScn.BPM.OrderBrokerApp.Test。 有关传递通知的详细信息，请参阅 使用确认。
构造要发送到 OrderManager 业务流程的消息时， OrderBroker 业务流程会创建包含两个部分的多部分消息。 其中一个部分包含路由信息，另一个部分包含订单自身。 消息的路由部分 OrderMgrMsg.Routing 使用由 SchemaClasses 程序集中的 C# 类定义的架构。 中转站将消息的顺序部分视为泛型或与类型无关的 XML 文档 (System.Xml。XmlDocument) 并将其分配给 OrderMgrMsg.Order。
路由信息中有两个对订单管理器特别重要的字段： OrderMgrMsg.Routing.OrderMgrType 和 OrderMgrMsg.Routing.Status。 代理将 OrderMgrType 设置为用于处理订单的订单管理器的类型。 在该解决方案中只有一个订单管理器，并且该字段设置为 CABLEORDER。 代理还会将 “状态” 字段设置为 ACCEPTED。 此字段是用于通知订单管理器该消息为新订单的值。 解决方案中的订单管理器 OrderManager 业务流程使用 接收 形状，该形状筛选订单类型等于 CABLEORDER 和状态等于 ACCEPTED。
OrderBroker 业务流程中的剩余步骤会将不同的消息发送到相应的端口。
使用嵌套范围提高性能
有关 OrderBroker 业务流程的一个值得注意的事项是，它使用了嵌套范围。 嵌套作用域的部分用途是通过限制持久化点来提高性能。
业务流程引擎将定期保存整个业务流程在称为持久化点的执行点时的状态。 业务流程引擎自动将多个业务流程形状（包括 发送 形状）视为持久性点。 有关持久性点的列表及其详细信息，请参阅 持久性和业务流程引擎。
对于五个 Send 形状， OrderBroker 业务流程应具有五个持久性点。 但是，在原子事务范围内对 “发送形状” 进行分组时，引擎识别它只需要一个持久性点作为范围。 由于 OrderBroker 业务流程中的四个发送形状不是异常处理程序的一部分，发送后无需执行任何操作，因此它们可以进入原子事务范围。 这样将会减少持久化点数。 有关原子事务的详细信息，请参阅 原子事务。
此外，如果嵌套事务都在同一时间结束，则业务流程引擎将为这些事务使用单个持久化点。 因此， OrderBroker 业务流程嵌套事务的方式进一步减少了持久性点：由于使用了 作用域 形状，业务流程具有单个持久性点。
提示
可以通过最大限度地减少业务流程中的持久化点来提高性能。 可以在原子事务中对 “发送 ”形状进行分组，为所有 “发送 ”形状生成一个持久性点。 如果同时结束嵌套事务作用域，将会为这些事务生成单个持久化点。
原子事务作用域不能具有异常处理程序。 因此，该业务流程将原子作用域嵌套在长期事务中。 此外部事务可以具有异常处理程序，并且正是此处理程序处理 来自发送 形状的异常。
提示
将原子事务嵌套在长期事务中是允许进行异常处理的通用模式。
另请参阅
业务流程管理解决方案中的处理
进程管理器逻辑
业务流程管理解决方案中的中断处理
ExceptionHandler 业务流程