基于SAP Kyma的订单编排增强介绍

摘要：当然，不同的产品，对订单增强的实现方式也各不相同。在世界里，想对订单处理流程做增强，同之前介绍的相比，相对来说受的限制要多一些。首单检查返回的分数是，根据当前配置文件这个结果被认定为首单。

尽管有一万个舍不得，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当初的设计者考虑问题的周全。

即便已经设计了这九百零几种状态，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检查结果：客户的邮箱地址有效。

首单检查返回的分数是100，根据当前Commerce配置文件这个结果被认定为首单。具体配置文件的位置和本文主题无关，这里不详述。

现在再回到Kyma的Lambda函数编辑器里，将之前注释掉的从Marketing Cloud获取联系人地址的函数以及调用SAP云平台的Business Partner服务的函数重新启用：

启用之后，保存，然后进入Service Catalog。这个组件也是Kubernetes提供的标准组件，Kyma基于它做了增强，能够将第三方的服务导入进来给Kyma的Lambda函数消费。

这里能看到已经导入了很多第三方服务。我们其实可以把这个界面类比成SAP云平台的Service Market Place。

选择SAP云平台的Business Partner Service：

接下来的步骤和我们在SAP云平台上消费一个服务类似，首先创建一个服务实例：

然后再基于这个服务实例创建一个绑定，

绑定类型设置成Function Binding，绑定的目标设置成之前编辑好的Lambda函数。

现在再下一个单试试，下单客户选择同第一个订单相同的客户：

这一次，这个第二次下的订单的Fraud检查报告，同第一个订单相比就多了两条记录：

首先看第二条首单检查的记录，得分为0，和我们期望的结果一致，因为这已经不是该客户第一次下单了：

从Marketing Cloud的服务返回的检查结果：

从SAP云平台的Business Partner服务返回的结果可以看出，下单的这个客户不存在一个对应的Business Partner。

本文这个例子，在Commerce下单流程中通过Kyma去访问Marketing Cloud和SAP云平台上的服务进行额外的Fraud检查，业务上来说可能意义不大，更多的是从技术的角度出发，介绍了这种基于微服务架构的订单编排增强方式。

祝大家新年快乐! 

相关阅读

站在巨人肩膀上的牛顿：Kubernetes和SAP Kyma

在Kubernetes上运行SAP UI5应用(上）

在Kubernetes上运行SAP UI5应用(下)

要获取更多Jerry的原创文章，请关注公众号"汪子熙":