SAP CRM系统订单模型的设计与实现

SAP成都市研究所的一个单位领导干部要我为他的精英团队做一个SAP CRM One Order架构的学习培训，这是我提前准备的培训计划。

在Jerry以前的文章内容根据SAP Ky ** 的订单编排提高详细介绍，我表示了自已对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模型，其自描述的命名就展现了该模型的特点。

Jerry以前尝试弄清楚"One Order"这一叫法，是来源于SAP官方网，或是只是被SAP开发者内部结构应用。

用百度搜索引擎依据关键词One Order检索，获得的結果几乎都是Jerry写的blog，囧。但是进系统软件依据ONE ORDER为关键词或是能检索出大把的编码。

我的文章内容 Jerry的WebClient UI 42篇原创文章内容合辑里有这张架构图：

在其中One Order架构从构架上讲，坐落于图中红 ** 域内，包含数据库表，ABAP结构体及其实际操作他们的API编码。

SAP One Order架构有多取得成功？百度搜索引擎输入关键词"SAP CRM ONE ORDER", 第一条百度搜索即Jerry写的一篇blog。在其中第一段话就给我们做详尽的论述：

虽然它如此取得成功，但当Jerry刚触碰One Order的情况下，惊讶地发觉，居然没有一个较为直接的图形界面页面，可以展示出这一模型的全貌。但是不经之谈，针对一个问世于20年以前的架构而言，大家不应该用20年之后的规范来追求它。

大家想像一下，不一样种类的订单，有哪些相同点？无非每一种订单都是有仰头构造，行新项目。有的构造，从服务上说可以一起发生在订单的仰头和行新项目，例如参加订单的工作小伙伴清单(Involved parties), 组织结构(Organization Unit)这些。有的字段名仅有行新项目才可以发生，例如售出的商品信息(Product, Scheduled Line)。

SAP One Order模型的基本原理，相近小时候玩的乐高积木。

构成One Order模型最少粒度分布的模块，便是一个个饰演乐高积木功效的结构体，在事务管理码CRMC_O ** ECTS里查询。

下面的图是这种结构体的目录，假如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的使用方法就可以。

假如想知道大量关键点，可以参照我的SAP小区blog：

1. Buffer logic in One Order header extension Read

https://blogs.sap.com/2017/03/22/buffer-logic-in-one-order-header-extension-read/

2. Logic of FILL_OW function module in One Order

https://blogs.sap.com/2017/03/22/logic-of-fill_ow-function-module-in-one-order/

3. Logic of CHANGE_OW function module in One Order

https://blogs.sap.com/2017/03/23/logic-of-change_ow-function-module-in-one-order/

4. Logic of CREATE_OW function module in One Order

https://blogs.sap.com/2017/03/24/logic-of-create_ow-function-module-in-one-order/

5. Logic of S ** E_EC function module in One Order

https://blogs.sap.com/2017/03/23/logic-of-save_ec-function-module-in-one-order/

6. CHANGED_AT, HEAD_CHANGED_AT and CRM_CHANGED_AT in order header table

https://blogs.sap.com/2017/04/27/changed_at-head_changed_at-and-crm_changed_at-in-order-header-table/

One Order的API之一，为顾客给予改动使用的CRM_ORDER_MAINTAIN, 全部SAP规范适用的结构体都做为键入主要参数之一发生在主要参数目录里:

这类设计方法尽管让主要参数目录看起来有点儿冗杂,可是从另一方面看，也发挥了自描述的实际效果, 保证 API的使用人即使不阅读文章文本文档,光凭访问这种主要参数自身,就能大约掌握该API究竟适用One Order什么数据信息的改动。

这也合乎那份知名的来源于Google的API设计方案最佳实践文本文档里提及的，好的API应当达到的前提之一：易懂实用，自描述，不容易导致误会。

在我的另一篇文章 Hello World, S/4HANA for Customer Management 1.0 曾经的我提及，SAP CRM的一部分作用转移到SAP S/4HANA后，一部分完成干了一些更新改造，在其中就包含One Order的更新改造。

Jerry是承担One Order更新改造设计方案的三位工作人员之一，详尽的更新改造基本原理和完成我已经发送到SAP小区了，这儿只概述一些关键定义。

https://blogs.sap.com/2018/03/02/crm-one-order-model-redesign-in-s4hana-for-customer- ** nagement-1.0-part-1/https://blogs.sap.com/2018/03/05/crm-one-order-model-redesign-in-s4hana-for-customer- ** nagement-1.0-part-2/

为什么要更新改造？由于SAP CRM搬到了S/4HANA上，而S/4HANA的一个强劲之处，在我朋友Zhang Sean的文章内容 S/4HANA业务流程人物角色概述之订单到收付款篇里也提及了，那便是S/4HANA在SAP在历史上第一次完成了OLTP和OLAP的极致融合，即一套体系的唯一数据库，可以一起达到Transaction事务管理型使用和Analytics剖析表格型运用的必须。

而SAP CRM One Order沒有更新改造以前的模型是没法和S/4HANA的以上特点配对的。

更新改造以前，每一个构成One Order模型最少粒度分布的结构体，都是有自已单独的一张专享数据库表，命名规范一般是CRMD_再加上结构体名。

这套最底层储存模型假如原封不动地搬至S/4HANA里，在运作报表统计等运用的时候会发生功能问题——为了更好地取下表格結果，后台管理必须在许多个结构体的储存表格中做各种各样数据库表的里外联接实际操作。当参加联接实际操作的数据库表规格提高到一定量级后，全部运用的特性主要表现不佳。Jerry也参加了特性测评，最终我们决定对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不可见，但我们仍然可以从合法渠道获得一些其订单模型的设计信息。

https://archive.sap.com/discussions/thread/3602400

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

因为Jerry不能够把C4C后台ESF2的界面给大家看，所以我选择了展示S/4HANA的Business Object开发框架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 Customer的订单模型，在Cloud Application Studio里对客户和Partners是可见的，大家感兴趣的可以自行去查看。

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