共计 4759 个字符，预计需要花费 12 分钟才能阅读完成。
尽管有一万个舍不得，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 的原创文章，请关注公众号 ” 汪子熙 ”: