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

原文地址:https://www.cnblogs.com/sap-jerry/p/10113877.html

时间: 2024-08-01 08:26:48

SAP订单编排和流程增强概述的相关文章

如何修改基于Debian包管理dpkg的程序流程方法概述

/*********************************************************************  * Author  : Samson  * Date    : 05/14/2014  * Test platform:  *              Mint 15-3.8.13.13  *              GNU bash, version 4.2.45  * ***************************************

Oracle EBS 中直发订单Drop Ship流程的系统操作记录

Oracle EBS 中直发订单Drop Ship流程的系统操作记录 应用场景: A公司向客户B销售产品,但是自己不生产该产品,而是向供应商C来采购,并且通常是要供应商C直接把货发到B客户处,属于贸易型企业经常用到的业务流程,有些集团公司下的子公司销售业务也用这种方式. 在实际业务中,并非所有的销售都是企业内部发出的,为了节约成本.提高周转效率.甚至应急销售,企业往往将外部企业也作为自己销售供货的来源之一,通过采购后直接发货的方式,将其他企业的货物直接销往自己的客户.这种销售业务模式,系统中称之

SAP S4/HANA BP屏幕增强添加自定义字段(BDT方式)

喜欢博主的读者也许会意识到,这是本博客中第一篇有关屏幕增强的文章.之前没有总结过相关的东西,除了因为相关经验有限之外,我个人也是不喜欢所谓dynpro编程的,它有许多“潜规则”一样的东西要记住,想要运用熟练,就需要花些力气去学,而它又十分老旧,在SAP的发展路线中处于即将被淘汰的地位..即便学成,可能也没什么用处. 但是在S4开始普及的这段时间里,我们毕竟还是使用着GUI.过去的供应商.客户的事务代码被废弃,相关的功能被整合到事务代码BP(Business Partner)中,因此相应的增强也要

SAP采购申请审批记录增强

业务需要,开发就搞.... EBAN中增强结构:CI_EBANDB ANAME 1 类型 UNAME CHAR 12 0 用户名 ADATE 1 类型 AEDAT DATS 8 0 更改日期 ATIME 1 类型 UZEIT TIMS 6 0 时间 BNAME 1 类型 UNAME CHAR 12 0 用户名 BDATE 1 类型 AEDAT DATS 8 0 更改日期 BTIME 1 类型 UZEIT TIMS 6 0 时间 二级审批 ME54N的增强: LMEREQF06 在函数:ME_UP

Lazada订单处理发货流程详解Lazada新手开店干货

#Lazada订单处理# #lazada发货流程#? #Lazada新手开店#? Lazada物流都是通过官方来运送的,主要有三个渠道:深圳.义乌.香港,卖家要保证5天之内将货发到Lazada的官方仓库,且Lazada不需要客户确认收货,只要官方物流显示妥投了,货款就会打给卖家. 一.LGS(Lazada Global Shipping)的使用 第一,使用LGS的优势.LGS,即为lazada全球物流,使用LGS,卖家货物可每日直接寄送,大大缩短了派送时效,一般在10天之内,货物就能送达.LGS

流程任务-概述

任务表示要在流程中完成的工作,类型主要有: service task:调用webservice或自动执行任务,如java service task.web service task.shell task. send task:处理向外部的流程参与人员发送消息工作,如email task.mule task. receive task:等待外部流程参与者发送消息的任务,. user task:需要业务人员参与的用户任务. manual task:手工任务,不需要任务的流程引擎或应用的驱动,会被自动

SAP ABAP 如何查找SMOD增强

1.查找程序名 T-CODE:SE93 2.查找开发类 T-code:se38 3.查找SMOD增强 T-CODE:SE16N.表:TADIR 4.查看增强具有哪些功能 T-CODE:SE16N.表:MODSAP

SAP公有云和私有云解决方案概述

SAP公有云解决方案见下图最右侧,比较著名的有SAP SuccessFactors和SAP Cloud for Customer(C4C)等,作为SAP软件即服务(SaaS)的解决方案. 而最左侧的SAP HANA Enterprise Cloud,是SAP一个私有云平台.这个平台上能购买的方案最主要的就是SAP S/4HANA(当然也有Business Suite等).客户购买产品后,SAP负责搭建底层基础设施(Infrastructure)和系统运维.也就是说,这些系统实际上运行于SAP遍布

复杂订单流程的梳理小结

来介绍下项目 从事电商行业,是一个女装类自营电商平台,结合虚拟试衣技术,和线下试穿服务,为用户提供一种不用出门就可以享受逛店试穿的服务.用户首先购买平台会员,在会员有效期内可以在平台上将喜欢的衣服加入试衣盒子,盒子满5件时可以在不付任何费用的情况下寄给用户,用户拿到盒子后,试穿这些衣服,再决定是否购买,然后将不买的衣服装入盒子再寄回平台,往返包邮. 这篇文章产生的背景,这篇文章是在做订单管理模块重构的时候产生的,好像所有系统建立的第一个版本都是暂时符合现在版本的APP,然后需求越来越多,不停的往