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的原创文章，请关注公众号"汪子熙":