笔者在 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 编程。
