abap如何屏幕增强_基于SAPKyma的订单编排增强介绍
尽管有⼀万个舍不得，2018年还是⽆可挽回地离我们远去了。
唯有SAP成都研究院的同事和我去年在⽹络上留下的这些痕迹，能证明2018年我们曾经很认真地去度过每⼀天：
SAP成都研究院2018年总共87篇技术⽂章合集
微服务在哪里⼀个SAP开发⼈员的2018年终总结
今天写的这篇⽂章也是因为⼯作需要。本⽂会⾸先介绍SAP传统产品⾥的订单编排增强技术，再来了解⼀下同样的增强需求，SAP Kyma 是如何完成的。
⽬录
基于SAP传统ABAP技术的订单编排增强技术
基于SAP Kyma的订单编排增强技术
订单编排，包含两个层次的SAP产品⾥的订单处理流程，⽆论是On-Premises解决⽅案还是云产品，我认为归根到底可以概括成四个字：订单编排
内容：
1. 单个订单通过业务流程或者⼯作流驱动的状态迁移，⽐如从初始的Created状态，经过⼀系列操作，最后进⼊Closed状态；
2. 多种类型的订单协同⼯作，完成⼀个完整的端到端业务流程。典型的例⼦有销售⾃动化(Sales Force Automation)⾥的从Lead, Opportunity, Quotation到Contract，Order这些不同类型的订单协同。
SAP系统⾥订单状态的迁移到底有多复杂？复杂度绝对远超初学者的想象。
以SAP CRM为例，在我使⽤的SAP CRM 714系统⾥，订单状态总共有906种，这不得不让⼈佩服SAP CRM当初的设计者考虑问题的周全。
User Status(⽤户⾃定义状态)即便已经设计了这九百零⼏种状态，SAP仍然考虑到了客户可能的状态扩展需求，因此采⽤了⼀种经典的User Status
Business
System Status(SAP标准状态)的两层状态设计，让⽤户能够随便定义的User Status通过扮演中间层⾓⾊的Business
和System Status
Transaction，映射到能够被SAP标准程序所感知的System Status。
Transaction
上图左边的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定义的区间内。
除了复杂的状态处理和跳转外，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的⽅式显⽰如下:

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。