可二次开发的crm系统，SAP CRM系统订单模型的设计与实现

1. logic in One Order Read

2. Logic of in One Order

3. Logic of in One Order

4. Logic of in One Order

5. Logic of in One Order

6. , and in order table

One Order的API之一，为消费者提供修改操作的, 所有SAP标准支持的结构体都作为输入参数之一出现在参数列表里:

这种设计方法虽然让参数列表显得有点冗长,但是从另一方面看，也起到了自描述的效果, 确保API的使用者即使不阅读文档,仅凭浏览这些参数本身,就能大概了解该API到底支持One Order哪些数据的修改。

这也符合那份著名的来自的API设计最佳实践文档里提到的，好的API应该满足的条件之一：易学易用可二次开发的crm系统，自描述，不易造成误解。

在我的另一篇文章 我曾经提到，SAP CRM的部分功能迁移到SAP S/4HANA后，部分实现做了一些改造，其中就包括One Order的改造。

Jerry是负责One Order改造设计的三位人员之一，详细的改造原理和实现我已经分享到SAP社区了，这里只简述一些核心概念。

为什么要改造？因为SAP CRM搬到了S/4HANA上，而S/4HANA的一个强大之处，在我同事Zhang Sean的文章 里也提到了，那就是S/4HANA在SAP历史上第一次实现了OLTP和OLAP的完美结合，即一套系统的唯一数据源，可以同时满足事务型应用和分析报表型应用的需要。

而SAP CRM One Order没有改造之前的模型是无法和S/4HANA的上述特性匹配的。

改造之前，每个组成One Order模型最小粒度的结构体，都有自己独立的一张专属数据库表，命名规范一般是CRMD_加上结构体名。

这套底层存储模型如果原封不动地搬到S/4HANA里，在运行报表统计等应用时会出现性能问题——为了取出报表结果，后台需要在很多个结构体的存储表中做各种数据库表的内外连接操作。当参与连接操作的数据库表尺寸增长到一定数量级后，整个应用的性能表现不佳。Jerry也参与了性能评测，最后我们决定对One Order的底层数据模型做改造。

因为留给我们从调研到改造的原型开发可二次开发的crm系统，再到正式开发一共只有八个月的时间，因此我们选择了一种代价最小，对One Order框架改动最小的方式。

首先我们抛弃了之前每个结构体拥有一张专属数据库表的做法，在S/4HANA里，每种订单类型只拥有两张表，一张存储抬头级别的数据，另一张存放行项目数据。之前散落在不同结构体表中的字段，如今统一维护在这两张表里。由于所有的字段都平铺在这两张表里，我们内部形象地称其为平坦表( Table)。

存储模型大大简化之后，我们基于这两张表再创建CDS view，让上层的报表应用消费。这样改造后简化的模型，能满足S/4HANA中OLAP应用的需求。

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

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

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

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

虽然SAP Cloud for 的后台对客户和不可见，但我们仍然可以从合法渠道获得一些其订单模型的设计信息。

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

因为Jerry不能够把C4C后台ESF2的界面给大家看，所以我选择了展示S/4HANA的 开发框架BOPF，因为前面说了，二者很多方面都非常相似。

同之前介绍的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 的订单模型，在Cloud 里对客户和是可见的，大家感兴趣的可以自行去查看。

希望这篇文章能让大家对SAP CRM两款产品中的订单模型设计有最基础的认识，感谢阅读。