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

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(131)-MM-134交货的库存调拨

MM 134交货的库存调拨 库存调拨流程始于在同一个公司代码中将物料从一个工厂调拨到另一工厂的请求。该请求,以库存调拨申请的形式在采购工厂通过 MRP 自动创建...

2214
来自专栏FreeBuf

使用各种扫描工具的你,不但踩了“蜜罐”可能还要被团灭了

*本文原创作者:evil7,本文属FreeBuf原创奖励计划,未经许可禁止转载 ? 工作后,越来越没有时间挖洞和写东西了(被世俗的纷争与微弱的工资束缚着),真是...

2958
来自专栏逍遥剑客的游戏开发

一个困扰我一个多星期的Nebula3的BUG

1783
来自专栏PPV课数据科学社区

QQ空间(日志、说说、个人信息)python爬虫源码(一天可抓取 400 万条数据)

爬虫功能: QQSpider 使用广度优先策略爬取QQ空间中的个人信息、日志、说说、好友四个方面的信息。 判重使用“内存位”判重,理论上亿数量级的QQ可瞬间判...

5275
来自专栏FreeBuf

剖析CLDAP协议 Reflection DDoS

2018年上半年,得益于Memcache近5万的反射放大倍数,DDoS的峰值流量已经达到了一个前所未有的新高度—1.7Tbps,这也使得Memcache ReD...

2372
来自专栏SDNLAB

SDNLAB技术分享(八):Neutron的基本原理与代码实现

一、Openstack网络基础 下面对Openstack和Neutron的介绍,要从几个关键词入手。 1. 三代网络 在网络这一口,OpenStack经历了由n...

3737
来自专栏程序猿DD

来自95后的天池中间件大赛总结

天池中间件大赛的初赛在今早终于正式结束了,公众号停更了一个月,主要原因就是博主的空余时间几乎全花在这个比赛上,第一赛季结束,做下参赛总结,总的来说,收获不小。

7666
来自专栏Linux驱动

31.Linux-wm9876声卡驱动(移植+测试)

本节学习目的 1)分析Linux中的OSS声卡系统 2)移植wm9876声卡 3)使用madplay应用程序播放mp3 1.声音三要素 采样频率 音频采样率是指...

5036
来自专栏北京马哥教育

动画演示9个超有趣的Linux命令

1835
来自专栏大数据挖掘DT机器学习

QQ空间(日志、说说、个人信息)python爬虫源码(一天可抓取 400 万条数据)

爬虫功能: QQSpider 使用广度优先策略爬取QQ空间中的个人信息、日志、说说、好友四个方面的信息。 判重使用“内存位”判重,理论上亿数量级的QQ可瞬间判...

6024

扫码关注云+社区

领取腾讯云代金券