该解决方案使用业务活动监视 （BAM） API 监视处理订单的步骤。 业务流程的设计将活动拆分为多个阶段。 通过重新组合活动，可以营造出一种持续过程的感觉。 BAM 还提供聚合数据，以便了解不同的后端占用时间、已完成的订单数和其他类似信息。
与面向服务的解决方案一样，它使用新的 OrchestrationEventStream 对象。 有关 OrchestrationEventStream 对象的讨论，请参阅 使用 BAM 监视面向服务的解决方案中的“什么是 OrchestrationEventStream 对象”。
有关 BAM 的一般信息，请参阅 “使用业务活动监视”。 有关跟踪配置文件编辑器（TPE）的信息，请参阅 跟踪配置文件编辑器。
封装 OrchestrationEventStream 对象
与面向服务的解决方案一样，业务流程管理解决方案包装 OrchestrationEventStream 对象。 并且，与面向服务的解决方案一样，所有方法都是静态的，因此业务流程无需创建对象的实例即可使用方法。 这也意味着，如果引擎暂停业务流程，则跟踪中使用的对象无需序列化，也不需要保存（不需要是可序列化的）。 但是，业务流程管理解决方案将 OrchestrationEventStream 包装为多个对象，这些对象均派生自单个抽象对象。
抽象类为 BasicActivity。 虽然它是抽象的，但类实际上并不充当派生类的模板。 相反，它通过静态方法提供了一组方法，这些方法在派生类中可以直接使用。 实际上，这提供了方法的四个默认实现。 四种静态方法包括： CreateActivityId、 BeginActivity、 UpdateActivity 和 EndActivity。
类重载 BeginActivity 方法。 其中一个版本采用活动名称作为单个参数，创建用作活动标识符的 GUID，然后调用本身的版本，该版本采用活动名称和活动标识符，然后返回活动标识符。 对于订单可能没有唯一标识符的情况，此单参数版本非常有用。
CreateActivityId 方法采用字符串和唯一标识符（如请求标识符），并返回与下划线连接它们的字符串。 这提供了唯一的活动标识符，并在派生类中广泛使用。 BeginActivity、UpdateActivity 和 EndActivity 方法调用 OrchestrationEventStream 的 BeginActiviy、UpdateActivity 和 EndActivity 方法。
该解决方案从BasicActivity派生类，用于订单代理（CustomerOrderRequest）、订单管理器（OrderManager）和处理阶段（ServiceOrderRequest）。 每个类对应于一个活动。 每个类都为 CreateActivityId 中使用的活动名称提供了一个字符串，用于创建活动标识符以及专用于活动里程碑的方法。
由于订单经纪人转交订单，并在稍后收到响应，因此它包含一种方法，可以恢复与订单请求标识符对应的活动标识符。 这样，业务流程就可以继续跟踪处理订单的最终元素。
注释
如果通过文件设施（而不是通过客户服务 Web 应用程序）提交订单，则需要为每个请求添加唯一的标识符。