本部分介绍 OrderBroker 业务流程如何获取订单并为进程管理器做好准备。 本部分首先讨论编排的一般运作方式。 下一部分讨论编排过程如何处理消息。 然后，它提出编排是如何利用原子事务来提升性能的。
注释
由于 OrderBroker 代码的长度，因此您可能需要在 Microsoft® Visual Studio 中打开流程编排的情况下阅读此部分。
为什么选择订单经纪人？
OrderBroker 业务流程的目的是预处理订单并将其路由到正确的进程管理器。 此处的预处理包括为历史记录数据库、服务系统生成信息性消息，以及确认收到订单。 OrderBroker 还会从客户服务请求创建一条通用订单消息。 此订单的标准化允许业务流程的元素对订单进行泛化处理。
订单消息是一条多部分消息，其路由信息与订单信息分开。 路由信息也是通用的，旨在由任何订单管理器使用。 这反过来又便于扩展解决方案。 有关多部分消息的信息，请参阅 如何使用多部分消息类型。
隔离代理功能后，您可以将其迁移到另一个 BizTalk 组。 由于 OrderBroker 发布到 MessageBox 数据库（即直接绑定），因此还可以更轻松地将中转站置于另一个组中，因此无需更改业务流程即可移动中转站。 有关将 OrderBroker 置于另一个组中的详细信息，请参阅 OrderBroker 和 OrderManager 之间的通信。
注释
OrderBroker 业务流程，因为它只有一个 OrderManager 与之通信，因此只需将常量字符串分配给订单管理器消息中的 OrderMgrType 字段。 通常，在有多个订单管理器的应用程序中，应用程序将使用业务规则引擎来确定此字段和订单路由的正确值。 有关业务规则引擎的详细信息，请参阅 “创建和使用业务规则”。
订单处理
OrderBroker 编排以监听形状中的两个 Receive 形状开头。 一个 接收 形状从客户支持系统获取消息；另一个 接收 形状从供应商系统获取消息。 来自任一源的消息具有相同的架构。
业务流程从消息中提取返回地址，并使用它为动态端口 CSRPort 设置地址。 业务流程使用此端口发送确认和错误消息。
OrderBroker 业务流程中的后续步骤将创建历史记录消息、服务消息、确认消息和要发送到 OrderManager 业务流程的订单消息。 编排使用 InsertOrderBody 实用函数将订单消息添加到历史记录消息。
注释
在某些情况下，解决方案可能会生成传递但未使用的消息。 订单代理业务流程使用发送端口在历史记录数据库中插入信息。 此发送端口使用传递通知。 配置将发送端口映射到包含两个端口的发送端口组，一个端口用于测试配置（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 业务流程中的四个 Send 形状不是异常处理程序的一部分，并且发送后无需执行任何作业，因此它们可以进入原子事务的范围。 这会减少持久性点数。 有关原子事务的详细信息，请参阅 原子事务。
此外，如果事务全部同时结束，业务流程引擎将为嵌套事务使用单个持久性点。 因此， OrderBroker 业务流程嵌套事务的方式进一步减少持久性点：由于使用 作用域 形状，业务流程具有单个持久性点。
小窍门
可以通过减少编排中的持久性点数来提高性能。 可以在原子事务中对 “发送 ”形状进行分组，为所有 “发送 ”形状生成单个持久性点。 同时结束嵌套事务范围会为事务创造一个统一的持久化点。
原子事务范围不能有异常处理程序。 因此，协调将原子级作用域嵌套在一个长时间运行的事务中。 此外部事务可以有一个异常处理程序，该处理程序负责处理来自 Send 形状的异常。
小窍门
在长时间运行的事务内嵌套原子事务是允许异常处理的常见模式。
另请参阅
业务流程管理解决方案中的处理
进程管理器逻辑
业务流程管理解决方案中的中断处理
ExceptionHandler 业务流程