全部博文（932）
分类： 架构设计与优化
2019-08-29 15:21:57
尽管有一万个舍不得，2018年还是无可挽回地离我们远去了。
唯有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当初的设计者考虑问题的周全。
即便已经设计了这九百零几种状态，SAP仍然考虑到了客户可能的状态扩展需求，因此采用了一种经典的User Status(用户自定义状态)和System Status(SAP标准状态)的两层状态设计，让用户能够随便定义的User Status通过扮演中间层角色的Business Transaction，映射到能够被SAP标准程序所感知的System Status。
上图左边的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的方式显示如下:
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 Kyma如何完成类似的需求。在使用Kyma之前，大家得对Kyma是什么，SAP为什么要开发出Kyma这两个问题比较清楚才行。我之前的文章 站在巨人肩膀上的牛顿：Kubernetes和SAP Kyma 已经介绍了这两个问题的答案，所以本文不再重复，直接上实例了。
我们假设需要对SAP Hybris Commerce的下单流程做增强，在标准的Fraud(欺诈)检查里加入我们在Kyma里实现的自定义检查流程。
如下图所示，其中浅蓝色的矩形框代表我们用Kyma实现的自定义Fraud检查逻辑。
具体增强了哪些检查逻辑呢？从下的订单里拿到下订单的客户ID，然后在Kyma里调用SAP Marketing Cloud和SAP云平台上提供的服务对这个客户做校验，Kyma拿到校验结果后，再传回Commerce。
下面是具体步骤。
1. 首先登录Commerce的back office页面，定义一个新的action，ID为EXTERNAL_KYMA_FRAUD_CHECK。做过ABAP开发的朋友们不难理解这个action，可以类比成ABAP里的action profile，用于存储和维护Partner的增强。
2. 进到Kyma的console页面：
选择一个stage进去，点击Lambdas进入编辑页面：
新建一个Lambda function，取名fraudcheck2。我们所有的增强逻辑就写在这个函数里。
这个函数自动创建的标签(Labels)，Kubernetes老司机们一定觉得很亲切。这些标签其实和大家现实工作中使用云笔记里的标签，以及图片管理软件里的标签作用相同，就是一种键值对(Key Value Pair), 可以允许用户将Kubernetes对象进行灵活分组，并提供高效的检索。
这个标签的概念不是Kyma发明的，而是Kubernetes的标准功能。
Function Trigger里可以指定这些Lambda函数在哪些事件触发后执行，思路和前文介绍的SAP CRM函数注册一致。选择第一步定义了新的action后对应的event：
关于Lambda函数具体的实现，做过nodejs开发的朋友们一定不会觉得陌生。
首先第18行，19行从event这个输入参数对象里取得发生事件的订单Code，然后第26行消费OCC(Omni Commerce Channel)Restul API获得订单明细，从明细里获得订单的客户ID，再调用第30行的代码根据客户ID拿到客户明细，然后使用第37行和第40行的代码分别检查该客户的邮箱地址是否有效，以及该客户是否第一次下单。
注意第43行和46行的代码我暂时注释掉，稍后才会启用。
现在我们来测试一下。在Commerce里下一个单，记下订单ID 2139。
回到Commerce back office页面，查看刚才下的订单的Business Process，输入2139进行查询：
这里根据ID EXTERNAL_KYMA_FRAUD_CHECK进行搜索，找到了刚才第一步新建的基于Kyma action对应的流程日志记录：
我们再去查看这个订单的Fraud检查记录：
点这个Fraud Reports查看检查结果。这个标签从左到右依次排开的风格很像Fiori和ABAP Webdynpro。
可以看见前文介绍的Email有效性检查和是否是首单的检查结果。
Email检查结果：客户的邮箱地址有效。
