笔者在 SAP 畛域工作多年，对 SAP 利用的了解就是：模型以及基于模型的增删改查。

只是同咱们大学专业课学习时实现的家庭作业相比，SAP 模型的复杂程度减少了好几个数量级。

和传统的增删改查相比，以订单编排畛域为例，SAP订单模型的"增"，还须要思考理论业务流程中各种类型的前置和后序订单，即 SAP 应用的术语文档流(Document Flow)。

而"改", 除了订单本身状态的迁徙外，还包含订单模型提供的各种可执行逻辑。这些逻辑既包含订单模型自身字段的更改，也能够包含订单与第三方零碎的交互。在很多上下文里，咱们称这些逻辑为 Action。

如下图右下角所示：

既然订单模型复杂度如此之高，那么引入一种精良的能反对企业级订单编排利用的高质量建模形式，就显得至关重要。

轻易看些例子，SAP CRM 总共反对多少种规范的订单类型？下图中 BUS2000 结尾的就是不同的订单类型，我没有具体数过，然而几十种总是有的。

而SAP Cloud for Customer，尽管位于 CRM 命名空间上面的 Business Object 的数量比 SAP CRM 要少一些，然而根本的用于实现销售自动化流程的订单模型依然一应俱全。

咱们先来看 SAP CRM 的订单模型。有没有可能用一套模型来形容SAP CRM反对的几十种订单类型呢？有，那就是SAP CRM One Order模型，其自描述的名称就体现了该模型的特色。

上面是 SAP CRM 利用的架构图：

其中 One Order框架从架构上讲，位于上图红色区域内，包含数据库表，ABAP构造体以及操作它们的API代码。

笔者刚刚接触 One Order 模型的时候，吃惊地发现，居然没有一个比拟直观的图形化界面，可能显示出这个模型的全貌。不过瑕不掩瑜，对于一个诞生于 20 年前的框架来说，咱们不应该用20年后的规范来奢求它。

咱们设想一下，不同类型的订单，有什么共同点？无非每种订单都有低头构造，行我的项目。有的构造，从业务上说能够同时呈现在订单的低头和行我的项目，比方参加订单的业务搭档明细(Involved parties), 组织架构(Organization Unit)等等。有的字段只有行我的项目能力呈现，比方卖出的产品信息(Product, Scheduled Line)。

SAP One Order建模的原理，相似咱们小时候玩的积木。

组成One Order模型最小粒度的单元，就是一个个表演积木作用的构造体，在事务码CRMC_OBJECTS里查看。
下图是这些构造体的列表，如果 SAP 规范的构造体不能满足需要，客户依然能够自行创立新的构造体。

而后咱们用搭积木的形式，将业务上具备关联关系的若干构造体组合起来，独特调配给某个订单类型，比方形容服务流程的订单类型 BUS2000116，就由下列这些构造体组成：

有了模型之后，剩下的就是实现基于这些模型的增删改查操作，即 ABAP 编程。

One Order API 的代码实现原理，实际上就是设计模式里的模板(Template)模式和察看-发布者模式的结合体。
咱们学习模板模式的时候，有一个经典的例子，上帝通过模板模式主宰芸芸众生的生老病死。

咱们每个人被父母实例化进去之后，只能被动地实现上帝在模板里定义好的四个办法：生，老，病，死，而不可能更改这个模板自身，比方调换这四个办法的程序。即便是乔布斯，也没有方法给本人增加一个"永生"的办法。听起来很残暴，但这是事实。

那么，One Order框架里，作为One Order利用的上帝，定义了哪些模板办法？

事务码CRMV_EVENT，指定 BUS2000116, 执行：

失去下图列表。红色的第一列，就是前文提到的组成One Order模型的积木。蓝色的第二列，是这些积木对产生在本人身上的感兴趣的事件列表。从图中能够看到这些事件名称都是自描述的，比方AFTER_CREATE, BEFORE_CHANGE, BEFORE_DELETE等等。

第三列彩色的ABAP函数，就是这些事件的监听函数。

这些监听函数的后缀 EC 代表 Event Callback.

借助上述框架，One Order利用的开发人员的开发工作就变得无比轻松：

(1) 通过搭积木的形式，定义出本人利用须要的One Order模型
(2) 实现模型里须要关注的事件对应的监听函数。

至于这些监听函数什么时候被调用到？利用开发人员齐全不必操心。

由此咱们能发现，One Order框架的实现，把编程复杂度从利用开发人员身上转移到了框架实现身上。

One Order框架外部的实现比较复杂。通常状况下，One Order框架的使用者只须要理解CRM_ORDER_READ, CRM_ORDER_MAINTAIN等API的用法即可。

One Order的API之一，为消费者提供批改操作的CRM_ORDER_MAINTAIN, 所有SAP规范反对的构造体都作为输出参数之一呈现在参数列表里:

这种设计办法尽管让参数列表显得有点简短,然而从另一方面看，也起到了自描述的成果, 确保API的使用者即便不浏览文档,仅凭浏览这些参数自身,就能大略理解该API到底反对One Order哪些数据的批改。

这也合乎那份驰名的来自 Google 的API设计最佳实际文档里提到的，好的API应该满足的条件之一：易学易用，自描述，不易造成误会。

SAP CRM 的局部性能迁徙到 SAP S/4HANA后，局部实现做了一些革新，其中就包含One Order的革新。

为什么要革新？因为SAP CRM搬到了S/4HANA上，而S/4HANA的一个弱小之处，即 S/4HANA在 SAP 历史上第一次实现了 OLTP 和 OLAP 的完满联合，即一套零碎的惟一数据源，能够同时满足Transaction事务型利用和Analytics剖析报表型利用的须要。

而SAP CRM One Order没有革新之前的模型是无奈和S/4HANA的上述个性匹配的。

革新之前，每个组成One Order模型最小粒度的构造体，都有本人独立的一张专属数据库表，命名标准个别是CRMD_加上构造体名。

这套底层存储模型如果一成不变地搬到S/4HANA里，在运行报表统计等利用时会呈现性能问题——为了取出报表后果，后盾须要在很多个构造体的存储表中做各种数据库表的内外连贯操作。当参加连贯操作的数据库表尺寸增长到肯定数量级后，整个利用的性能体现不佳。笔者也参加了性能评测，最初咱们决定对One Order的底层数据模型做革新。

因为留给咱们从调研到革新的原型开发，再到正式开发一共只有八个月的工夫，因而咱们抉择了一种代价最小，对One Order框架改变最小的形式。

首先咱们摈弃了之前每个构造体领有一张专属数据库表的做法，在 S/4HANA 里，每种订单类型只领有两张表，一张存储低头级别的数据，另一张寄存行我的项目数据。之前散落在不同构造体表中的字段，现在对立保护在这两张表里。因为所有的字段都平铺在这两张表里，咱们外部形象地称其为平坦表(Flattened Table)。

存储模型大大简化之后，咱们基于这两张表再创立CDS view，让下层的报表利用生产。这样革新后简化的模型，能满足S/4HANA中OLAP利用的需要。

针对S/4HANA OLTP利用的革新，用一句话概括，就是咱们采纳设计模式里的适配器模式(Adapter), 在API与简化后的数据库表之间引入一个微型的中间件，表演Adapter的角色。

当消费者通过One Order API进行读操作时，中间件负责把存储在简化后的数据表中的数据进行还原，再填充到One Order API下层的缓存中。对后者来说，它对底层存储模型产生的变动毫不知情，因为Adapter封装了底层数据读取的逻辑并做了格局转换，所以One Order API下层不须要做任何改变，也齐全可能像在SAP CRM里一样失常运行。

而当消费者调用One Order API进行写操作时，在存储于各个构造体对应的缓存中的数据长久化到数据库之前，同样是Adapter负责把这些扩散在不同缓存构造中的数据做一个合并，合并后的构造体再写入平坦表。

讲完了CRM One Order订单模型的设计，咱们再来简略看看SAP Cloud for Customer的订单模型设计。

尽管SAP Cloud for Customer的后盾对客户和Partners不可见，但咱们依然能够从非法渠道取得一些其订单模型的设计信息。

从SAP社区上这位SAP员工的回复，咱们得悉ESF2和BOPF有很多相似之处，设计理念相似，但ESF2次要用于部署在云端的产品，比方SAP Cloud for Customer上Business Object的开发，而后者次要服务于On Premises解决方案比方S/4HANA。

同之前介绍的SAP CRM One Order框架一样，通过BOPF实现的订单模型，同样由若干个构造体通过搭积木的形式组成，这些构造体如上图红色高亮区域所示，每个构造体也有本人的专属存储数据库表。而SAP CRM One Order里每个构造体的事件监听函数，采取的是 ABAP 传统的面向过程的函数实现，而BOPF则采取了实现指定接口的ABAP类，二者原理雷同，只是实现细节有差别。

SAP C4C的订单模型，尽管和SAP CRM传统的One Order模型一样，每个构造体领有一张专属的数据库表，然而在运行报表程序时并不会呈现性能问题，这是怎么做到的？

答案是采纳了TREX，一个专为只读报表利用优化过的存储仓库。换句话说，SAP C4C的事务处理和报表解决应用的是两套不同的存储系统，这一点和S/4HANA不同。

SAP Cloud for Customer的订单模型，在Cloud Application Studio里对客户和Partners是可见的，大家感兴趣的能够自行去查看。

总结

本文首先具体介绍了 SAP CRM 零碎里订单模型的演进历史和设计原理，以及生产该订单模型的 API，接着介绍了这种模型迁徙到 S/4HANA 零碎时面临的挑战，以及笔者所在我的项目团队给出的迁徙重构计划。最初将另一款云端 CRM 零碎的订单模型进行类比，心愿对工作于客户关系治理畛域的读者能有所帮忙。