SAP订单编排和流程加强概述

SAP产品里的订单处理，不管是On-Premises解决方案仍是云产品，我认为归根到底能够归纳成四个字：订单编排，包含两个层次的内容：

1. 单个订单经过业务流程或者工做流驱动的状态迁移；

2. 多种订单类型协同工做，完成一个完整的端到端的业务员流程。

好比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 CRM当初的设计者考虑问题的周全。

除了复杂的状态处理和跳转外，SAP订单编排的复杂度主要体如今如下方面：

1. 不少SAP的客户，除了购买SAP的On-Premises产品或者订阅云服务外，还拥有其余业务系统。这类客户的订单编排，在SAP标准业务流程基础上每每还存在和这些第三方业务系统的交互。

2. 即便是同一行业的客户群，由于地域和国家，语言的差别，可能业务流程也存在必定的差别。SAP发布的标准功能有时没法100%支持这些千差万别的业务流程。

所以SAP系统对订单编排加强的支持就很是必要。

固然，不一样的SAP产品，对订单加强的实现方式也各不相同。

在SAP CRM里，虽然SAP没有明确提出Business Object这个名词，但订单应用基于的模型实际上仍然是由不一样的节点组成：

每一个节点对应一些更底层的模型节点，上面能够注册各类事件处理函数。下图是Service Request这个BO的抬头节点的事件处理函数：

每一个节点能够分配一个分配一个执行函数，固然，严谨的德国人在最简单的观察-发布者模式上又添加了几个维度的设置。

下图第一列红色的Execution Time，表示这些分配的函数究竟是事件触发后当即执行，仍是延迟到订单抬头或者行项目的通用例程执行完后再执行(每每用于实现批量操做，或者待执行函数同通用例程存在依赖关系，或者出于性能考虑）。

第二列的Priority，即函数执行优先级，若是若干函数除了优先级外其余维度维护的属性彻底一致，则按优先级从高到低依次执行。

第三列Event，就是观察者-发布者模式里的事件了，下面是SAP CRM订单框架一些标准的事件：

最后一列就是事件监听函数。

Jerry倾向于把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建立以后，在ABAP后台并非以BAdI Implementation的方式存储，而是以ESF2 Determination的方式存储，相似下图这种BOPF里的Determination：

SAP C/4HANA里的五朵云之一，Commerce Cloud，则能够经过SAP Kyma来作扩展，咱们下次介绍。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":