共计 2475 个字符，预计需要花费 7 分钟才能阅读完成。
笔者在 SAP 成都研究院工作多年，从事过多款 SAP 产品的规范开发工作。这些产品里无一例外地都存在着订单(Order) 这种数据模型。
订单模型从数据结构上来说是一棵树，根节点就是咱们通常俗称的订单低头 (Header Level) 构造，次要蕴含订单 ID，创立工夫，创建者，订单形容信息，订单波及到的业务合作伙伴(Business Partner) 等字段。
根节点通过所谓的 Association 和 Composition，关联到其余叶节点，最典型的叶节点就是订单行我的项目(Line Item) 构造。行我的项目蕴含订单设计到的产品明细，比方产品 ID，产品数量，产品单价，计税形式，定价信息等等。订单根节点和订单行我的项目的对应关系为 1:N.
SAP 产品里的订单解决，无论是 On-Premises 解决方案还是云产品，笔者认为归根到底能够概括成四个字：订单编排。这个概念蕴含两个档次的内容：
- 单个订单通过业务流程或者工作流驱动的状态迁徙；换言之，SAP 产品的应用逻辑，实际上通过订单模型的状态迁徙来体现。
- 多种订单类型协同工作，实现一个残缺的端到端的业务流程。
比方 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 订单编排的复杂度次要体现在以下方面：
- 很多 SAP 的客户，除了购买 SAP On-Premises 产品或者订阅云服务外，还领有其余业务零碎。这类客户的订单编排，在 SAP 规范业务流程根底上往往还存在和这些第三方业务零碎的交互。
- 即便是同一行业的客户群，因为地区和国家，语言的差别，可能业务流程也存在肯定的差别。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 这两款具备代表性的客户关系治理解决方案，着重介绍了其订单编排逻辑的设计原理与实现细节。