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

SAP订单编排和流程增强概述相关推荐

基于SAP Kyma的订单编排增强介绍
尽管有一万个舍不得,2018年还是无可挽回地离我们远去了. 唯有SAP成都研究院的同事和我去年在网络上留下的这些痕迹,能证明2018年我们曾经很认真地去度过每一天: SAP成都研究院2018年总共87 ...
SAP MIGO生产订单入库校验BADI增强MB_MIGO_BADI
SAP MIGO生产订单入库校验BADI增强MB_MIGO_BADI 1. 创建BADI增强实施 2.修改增强实施 3.生产订单MIGO过账效果 1. 创建BADI增强实施 SE19->创建BA ...
SAP 产品一脉相承的 UI 增强思路，在 SAP Commerce Cloud(电商云) UI 增强实现中的体现
本文首先快速回顾几种 SAP 产品中的 UI 增强思路,然后具体介绍该思路是如何在 SAP Commerce Cloud(电商云) UI 增强中贯彻实施的. Jerry 之前的文章:Jerry 在 2 ...
SAP License：SAP订单的归档及删除
在CO中有时候我们会因为误操作等原因创建一些错误订单,如果不再需要,可以从系统中删除掉.SAP提供了两种删除方法:物理删除和归档. 物理删除之后,这张订单就再也找不回来了,因此要慎用.这种方法比较快捷 ...
SAP MM 外部采购流程里的如同鸡肋一样的Advanced Returns Management功能
SAP MM 外部采购流程里的如同鸡肋一样的Advanced Returns Management功能文章中的配置界面和单据流界面都是基于SAP S4HANA 1909系统. Part I: 外部采 ...
SAP MM 外部采购流程里的Advanced Return Management
SAP MM 外部采购流程里的Advanced Return Management 本文简要介绍外部采购订单中高级退货管理功能. 1,采购订单单据类型 NB2, 2,交货单类型的设置 3, BP主数据 ...
SAP公司间STO流程里外向交货单PGI后自动触发内向交货单的实现
SAP公司间STO流程里外向交货单PGI后自动触发内向交货单的实现公司间采购(公司间库存转储)在很多SAP项目里很常见,笔者在很多项目里都有这种场景.项目实践中,都是采用SAP的Inter-comp ...
sap 标准委外和工序委外_「SAP技术」SAP MM 委外加工采购流程里副产品的收货
「SAP技术」SAP MM 委外加工采购流程里副产品的收货委外加工采购流程,在很多SAP项目里都有. 其标准流程是: 我方因受限于生产工艺或者生产产能不足,或者降低生产成本的缘故,需要寻找外部加工商 ...
赛锐信息：SAP订单统一管理系统
一.引言 SAP商超订单统一管理系统解决方案以商超平台订单集中管理为核心,系统支持多平台.多店铺.全渠道系统采购订单.验收单.结算单等业务单据的统一管理. **关键字:SAP 订单.SAP 商超订单. ...

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

SAP订单编排和流程增强概述相关推荐

最新文章

热门文章