通过进程管理器的订单流
本部分介绍 Southridge 视频订单流程管理器 、OrderManager 业务流程如何处理订单。 本部分将跟踪一份新订单在业务流程中的处理过程。 本部分还讨论了业务流程如何处理对订单的更新。
注意
业务流程管理器解决方案只包含一个流程管理器，尽管该解决方案已编写为可以使用多种类型的管理器。
OrderManager 业务流程协调实现业务流程以处理订单的从属业务流程。 OrderManager 通过两个阶段发送订单，这两个阶段组合在一起，验证订单，将信息发送到设施组，通过远程处理组件将订单发送到订单系统，并更新订单历史记录。 可以添加、删除或修改这些阶段，而无需更改 OrderManager。
注意
由于 OrderManager 业务流程的大小和范围，你可能希望在 Microsoft Visual Studio 中打开业务流程的情况下阅读本部分。
订单管理器结构
OrderManager 业务流程以激活业务流程的接收形状开始。 下图显示了 OrderManager 业务流程的常规结构。
Order Manager
第一个接收形状将通向两个主要分支。 一个分支（右侧的分支）用于处理新订单。 而左侧的分支则处理订单取消。 由于它接受用户输入， 因此 OrderManager 可以在订单完成后收到订单取消。 这就是左侧主要分支所要处理的情况。 该分支通过设置用于终止处理操作的标志以及向事件日志添加警告，来处理单个取消。 业务流程将处理正在右侧分支内处理订单时到达的订单取消。
订单处理分支执行某种初始化操作，然后进入两个嵌套的循环。 外部循环对订单处理中的每个阶段都会运行一次。 而内部循环则在阶段正进行时运行。 订单管理器还将侦听内部循环中对订单的可能更新。 循环终止之后，订单管理器将发送完成消息。
订单处理阶段使用动态的自相关端口来回 与 OrderManager 业务流程通信。 这简化了 OrderManager 与阶段实例的关联，因为它无需使用关联集。 有关自关联端口的详细信息，请参阅 端口绑定。
接收订单
OrderManager 通过 FromBrokerPort 端口从 OrderBroker 业务流程接收订单消息。 此端口直接绑定到 MessageBox 数据库。 业务流程有两个连接到端口的 接收 形状：一个用于新订单，一个用于更新的订单。
OrderManger 根据筛选器表达式确定要处理的消息。 筛选器表达式测试消息状态字段和订单管理器类型字段 OrderMgrType 中的值。 如果状态字段等于 ACCEPTED，而 OrderMgrType 为 CABLEORDER，则订单为新订单，适用于此进程管理器。
新订单将激活新的业务流程实例。 接下来，OrderManager 检查“决策”形状中的请求类型。 如果该类型为“终止”，则业务流程将执行左侧分支，并终止订单。 否则，业务流程将继续处理该订单。 请注意，这包括侦听与此特定订单相关的随后的消息。
初始化新订单
OrderManager 业务流程收到初始消息并开始main右侧分支后，它会从 SSOConfigStore 获取其配置信息。 它通过 实用程序 程序集中定义的单一实例对象执行此操作。 配置值是 对象的属性。 对象管理配置值的本地缓存，类似于面向服务的体系结构解决方案。 有关单一实例对象的详细信息，请参阅 在业务流程管理解决方案中高效使用 SSO。
与面向服务的解决方案一样，业务流程管理解决方案使用机密存储，因为每当安装 BizTalk 时，它就存在，SSO 会缓存配置信息，以便这些值随时可用，并且可以保护数据库连接字符串和密码等信息。 由于所有这些原因，即使单 Sign-On 不用于管理与后端应用程序的连接，机密存储也是配置信息的良好位置。
注意
业务流程在开始处理前将检索配置信息。 这可确保业务流程在冻结并随后解冻后，仍然使用同一配置。 有关冻结的详细信息，请参阅 业务流程解除冻结和解除冻结。
订单管理器使用配置数据中的一个值： TotalStages，即订单处理过程中的阶段总数。 管理员将此值分配给本地变量 numStages。 它还设置另外两个连接到外部循环的变量： 阶段 和 停止。 阶段指示当前阶段，是外部循环的计数器;停止停止值。
最后，管理器将 orderStatus 变量设置为 STARTED 并进入外部处理循环。
新订单处理循环
只要 阶段 变量的值小于 numStages 变量的值，外部循环就运行。 外部循环驱动每个阶段的处理。 只要某个阶段仍在处理，内部循环就运行。 它还侦听对订单的可能更改。
外部循环
业务流程通过将接收的消息 (NewOrderMgrMsg) 分配给变量 OrderMgrMsg 来开始外部循环。 然后，它将阶段和状态复制到消息的路由部分。 业务流程还会将消息中的返回地址设置为 StageCompletionPort 的地址：
OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =
StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);
然后，业务流程将订单发送到 StagePort，即请求-响应端口。 随后，业务流程将等待来自已启动订单处理的阶段的确认。 阶段在开始处理订单时发送 OrderAck 消息。
注意
OrderAck 消息是由 .NET 类而不是架构定义的解决方案中的几个消息之一。 有关使用 .NET 类定义消息的详细信息，请参阅 在用户代码中构造消息。
当业务流程收到确认时，它会将阶段分配给 currentStage 变量并进入内部循环。
内部循环
只要 currentStage 变量等于 阶段 变量，内部循环就运行;也就是说，只要正在处理当前阶段。 循环的主体是具有三个接收形状的侦听形状。 业务流程中最左侧的形状 “订单请求”是订单更新机制的一部分，下一部分将介绍。
当订单处理阶段完成时，它会将消息发送到 OrderManager 业务流程的 StageCompletion 端口。 如果阶段由于错误而突然终止，则会发送 TerminatedMessage。 在这种情况下， OrderManager 将引发异常。 最外层的异常处理程序捕获异常，并向 OperatorPort 发送错误消息。
如果阶段发送 OrderMgrMsg， 则 OrderManager 递增 阶段 变量。 如果阶段 (少于或等于 numStages) ，业务流程会将 OrderMgrMsg 中的订单状态设置为STAGE_n_COMPLETED其中 n 是当前阶段的编号。 如果没有其他阶段，则业务流程将订单状态设置为 COMPLETED，并退出这两个循环。
订单汇报
OrderManager 业务流程侦听内部处理循环中的订单更新。 请注意，用于此的 接收 形状 OrderRequest 也使用 FromBrokerPort。 如果在循环中同一端口上使用第二个接收形状，并将其与相关集进行组合，则会形成通用 BizTalk Server 模式：保护模式。 使用保护模式可确保同一业务流程实例处理与特定操作连接的第一条及其后续消息。
在订单管理器收到连接到订单的第一条消息后，它将初始化两个相关集。 第一个 是 OrderCorrelation，使用客户 ID (CustID) ，订单 ID (OrderID) 。 订单管理器与订单处理阶段共享此相关。 第二个关联是车队关联 OrderConvoyCorrelation，它使用订单状态 (状态) 以及客户 ID 和订单 ID。 OrderRequestReceive 形状使用 OrderConvoyCorrelation 作为后续关联集。 按此方式设置相关集可确保处理特定订单的订单管理器实例能够接收任何更改。
注意
请回忆一下，相关集是用于确定消息是否属于给定业务流程实例的消息属性的分组。 有关详细信息，请参阅 在业务流程中使用相关性。
当 OrderManager 收到订单的后续消息时，它会首先测试请求的类型。 如果请求类型为 TERMINATE，则决策形状将执行终止分支。 否则，业务流程将测试新消息，以查看它是否是更新消息。 更新消息的序列号 (SeqNum) 高于原始请求。 如果新消息的序列号更高，则业务流程将对新消息启动订单处理。 如果原始消息和更新消息具有相同或更低的序列号，则说明存在序列错误。 如果序列号相等，则更新消息为重复订单，并将标记为重复错误。
有关 SeqNum 的详细信息，请参阅 关键消息和字段。
最终步骤
退出循环后，订单管理器会将回复地址分配给动态端口 CSRCompletionPort。 然后，管理器将构造完成状态消息，并发送该消息，然后测试是否存在错误。 若有错误，则业务流程将执行终止形状；否则，将正常结束。
与阶段协调
OrderBroker 业务流程和第二个处理阶段业务流程 (CableOrder2) 在历史记录数据库中创建条目。 CableOrder2 业务流程更新 OrderBroker 业务流程输入的历史记录信息。 为了确保数据库中有要更新的条目， OrderBroker 在用于数据库的端口上使用传递通知。
配置将历史记录数据库的 OrderBroker 发送端口映射到包含两个端口的发送端口组-一个端口用于测试配置 (HistoryInsert-Test-SP) ，一个用于常规配置 (HistoryInsert-SP) 。 如果将该组中的两个端口都保持活动状态，则解决方案将同时向这两个端口发送消息。 因而，该解决方案将请求两个送达通知，但仅处理其中一个通知。
若要避免这种情况，请取消列出测试端口 (HistoryInsert-Test-SP) ，或停止应用程序的测试版本。 有关传递通知的详细信息，请参阅 使用确认。
错误和路由修复的消息 - 设计选项
订单处理阶段使用的异常处理程序业务流程和业务流程使用错误处理业务流程 (ErrorHandlerOrch) 路由错误订单进行修复。 在设计中，假设有一个部门或组需要以所需格式修复订单。 修复的订单不会通过 Order Broker 业务流程 (OrderBroker) 重新提交。 而是将规范化的订单以其规范化格式进行修复。 当前设计的解决方案具有处理程序业务流程，该业务流程可以将错误消息路由回原始订单的源。 但是，修复的订单必须路由到错误处理程序业务流程上的 MSMQ 端口。 (解决方案的测试版本使用 file folder。) 错误处理程序随后将修复的消息返回到调用业务流程。
此解决方案之所以使用该设计是因为 OrderBroker 会对订单消息进行重要验证和规范化。 从而，需要修复的订单消息也会采用规范化格式。 如果保持消息的规范化格式，则无需处理消息的已提交格式与规范化格式之间的差异问题。