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