笔者在 SAP 成都研究院工作多年，从事过多款 SAP 产品的标准开发工作。这些产品里无一例外地都存在着订单(Order) 这种数据模型。

订单模型从数据结构上来说是一棵树，根节点就是我们通常俗称的订单抬头(Header Level) 结构，主要包含订单 ID，创建时间，创建者，订单描述信息，订单涉及到的业务合作伙伴(Business Partner)等字段。

根节点通过所谓的 Association 和 Composition，关联到其他叶节点，最典型的叶节点就是订单行项目(Line Item) 结构。行项目包含订单设计到的产品明细，比如产品 ID，产品数量，产品单价，计税方式，定价信息等等。订单根节点和订单行项目的对应关系为 1:N.

SAP 产品里的订单处理，无论是 On-Premises 解决方案还是云产品，笔者认为归根到底可以概括成四个字：订单编排。这个概念包含两个层次的内容：

1. 单个订单通过业务流程或者工作流驱动的状态迁移；换言之，SAP 产品的应用逻辑，实际上通过订单模型的状态迁移来体现。

2. 多种订单类型协同工作，完成一个完整的端到端的业务流程。

比如 SAP CRM 里经典的 User Status(用户自定义状态)和 System Status(SAP 标准状态)的设计，通过引入 Business Transaction 将两者关联起来，完美地实现了用户自定义订单状态被 SAP 标准程序的感知。

下图左边的 Open, In process， Released 和 Completed 就是用户自定义订单状态，SAP 允许客户给每个状态分配一个 Low 和 High 的值，通过这种方式巧妙地提供了一种用非图形化方式进行状态跳转的定义。

比如 In process 状态的 Low 为 20，意味着 In process 状态不可能重新回到 Open 状态，因为 Open 状态的 ID 10 小于 In process 状态的 Low 字段定义的 20——一个状态能跳转到的目标状态的 ID，必须在由该字段的 Low 和 High 定义的区间内。

用户状态通过 Business Transaction 映射到的 SAP 标准状态，在我截图的系统上一共有 906 个，这既体现了 SAP 软件的高度复杂性，也不得不让人佩服 SAP CRM 当初的设计者考虑问题的周全。

除了复杂的状态处理和跳转外，SAP 订单编排的复杂度主要体现在以下方面：

1. 很多 SAP 的客户，除了购买 SAP On-Premises 产品或者订阅云服务外，还拥有其他业务系统。这类客户的订单编排，在 SAP 标准业务流程基础上往往还存在和这些第三方业务系统的交互。

2. 即使是同一行业的客户群，因为地域和国家，语言的差异，可能业务流程也存在一定的差异。SAP 发布的标准功能有时无法 100% 支持这些千差万别的业务流程。

因此 SAP 系统对订单编排增强的支持就非常必要。

当然，不同的 SAP 产品，对订单增强的实现方式也各不相同。

在 SAP CRM 里，虽然 SAP 没有明确提出 Business Object 这个名词，但订单应用基于的模型实际上仍然是由不同的节点组成：

每个节点对应一些更底层的模型节点，上面可以注册各种事件处理函数。下图是 Service Request 这个 Business Object 的抬头节点的事件处理函数：

每个节点可以分配一个分配一个执行函数，当然，严谨的德国人在最简单的观察-发布者模式上又添加了几个维度的设置。

下图第一列红色的 Execution Time，表示这些分配的函数到底是事件触发后立即执行，还是延迟到订单抬头或者行项目的通用例程执行完后再执行(往往用于实现批量操作，或者待执行函数同通用例程存在依赖关系，或者出于性能考虑）。

第二列的 Priority，即函数执行优先级，如果若干函数除了优先级外其他维度维护的属性完全一致，则按优先级从高到低依次执行。

第三列 Event，就是观察者-发布者模式里的事件了，下面是 SAP CRM 订单框架一些标准的事件：

最后一列就是事件监听函数。

笔者倾向于把 CRM 订单处理系统的运作方式理解成类似下图这种复杂的水管传输系统，订单业务流程依次被注册在不同事件上的监听函数执行，就像这一根根大小粗细长短各异的水管一样。

如果客户对其中某个业务步骤需要做增强(需要替换某根水管), 只需要用一个自己实现的函数去替换 SAP 标准函数(自己另外找一根水管替换掉现在正在工作的水管），能替换的前提是自己实现的函数的接口同被替换函数完全一致(自己另外找的水管和以前的水管两端接口的规格完全一致）。

而 SAP Cloud for Customer 里的订单模型，其 Business Object 在目前最新的 1811 版本里仍然是由 ESF2 框架实现，只是后台对 Partners 不可见，但大家可以类比 SAP On-Premises 世界里的 BOPF 框架，两个框架的实现原理类似。

在 Cloud 的世界里，想对订单处理流程做增强，同之前介绍的 SAP CRM 相比，相对来说受的限制要多一些。

在 Partner 做增强的 Cloud Application Studio 里，所有能做增强的点以 Hook 的方式显示如下:

Partners 可以在这些 Hook 里进行业务功能增强。有些 Hook 可能存在某些读写限制，比如 AfterLoading 这个 Hook，会在 SAP BO 的标准加载逻辑执行完毕后被调用，在这个 Hook 的实现里，SAP 不允许任何对 BO 节点标准字段的写操作，以避免 Partners 的增强对 SAP 标准流程可能带来的影响。

有的顾问朋友可能会说，这些 Hook 不就是 SAP Netweaver 里传统的 Business AddIn(BAdI) 么？没错，概念上可以这么理解，需要提醒的就是，这些 Hook 创建之后，在 ABA P 后台并不是以 BAdI Implementation 的方式存储，而是以 ESF2 Determination 的方式存储，类似下图这种 BOPF 里的 Determination：

总结

本文首先给出了 SAP 产品里订单模型的统一实现思路，接着选择 SAP CRM 和 SAP Cloud for Customer 这两款具有代表性的客户关系管理解决方案，着重介绍了其订单编排逻辑的设计原理与实现细节。