使用 Kyma 扩展企业级云原生应用
在 Kyma 官网的客户成功案例中，赫然有 SAP，Netconomy，Accenture，Digital Lights 这些企业用户。
SAP 在客户体验产品线(Customer Experience) 这一领域推出的 C/4HANA 套件，包含市场云，电商云，销售云，服务云和客户数据云。Kyma 正是 SAP 推荐的对这些企业家云原生应用进行扩展的推荐平台和工具之一。
下面我们来了解一些具体的扩展案例。
SAP 电商云(Commerce Cloud) 有一套订单状态编排模型，从用户下单到订单最终处于 Complete 状态，状态的迁移通过一系列 Action 进行驱动。
假设我们期望在 SAP 电商云里实现这样一个增强场景：在用户下单之后，发货之前，增添一个自定义的检查步骤 Fraud Check(订单欺诈检查)，如下图流程图内浅色矩形框所示。
一种比较直接的方式，是在 SAP 电商云源代码里，查找订单编排流程里基于 Spring 框架的 Hook，通过自定义 Java Bean 的方式，实现自定义检查逻辑。这种方式在开发完成后，需要重新构建 SAP 电商云的 Java 源代码。这就是所谓的 In-App extension 方式。
如果选择 Kyma 以事件驱动的方式对 SAP 电商云进行增强，则增强逻辑以 Lambda Function 的载体存储在 Kyma 平台上，而非对 SAP 电商云本身的源代码进行增强。这种方式又称为 Side-by-Side extension 方式。
主要的开发步骤如下：
(1) 在 SAP 电商云进行配置，将自定义事件 Fraud Check 发布给 Kyma.
(2) SAP 电商云的增强开发人员，登录 Kyma 控制台，创建 Lambda Function，将 Function Triggers 选择为步骤一在 SAP 电商云里发布的自定义事件。Lambda Function 的实现内容，即从事件对象里解析出下单的客户信息，然后调用 Marketing Cloud 和 SAP 云平台提供的 Restful API，对该客户身份的有效性进行检查。
运行时，当用户下单后，SAP 电商云向 Kyma 抛出一个事件。Kyma 分别调用 SAP Marketing Cloud 和 SAP 云平台的 Business Partner API，将检查结果返回给 SAP 电商云。
登录 SAP 电商云 Backoffice 配置页面，定义一个新的Action，ID 为 EXTERNAL_KYMA_FRAUD_CHECK.
登录 Kyma 控制台，创建一个新的 Lambda Function，Function Triggers 选择为 SAP 电商云 Backoffice 里维护的自定义事件：
Lambda Function 的具体实现：
- 代码 18～19 行：从 输入的 event 事件对象参数里，解析出订单 Code
- 26 行：消费 SAP 电商云的 OCC(Omni Commerce Channel) Restul API，获得订单明细，从中获得下单的客户 ID
- 30 行：根据客户 ID 拿到客户明细
- 37 行：检查该客户的邮箱地址是否有效
- 40 行：检查该客户是否第一次下单
- 43 行：调用 SAP Marketing Cloud API 检查客户身份有效性
- 46 行：调用 SAP 云平台 Business Partner API 检查客户身份有效性
下面对这种基于事件驱动方式所完成的增强实现进行测试。
在 SAP 电商云里创建一个新的订单，记下订单 ID 2139.
登录 SAP 电商云 Backoffice 控制台，检查自定义 Fraud Check 逻辑是否按照我们期望的流程来执行。
根据 ID EXTERNAL_KYMA_FRAUD_CHECK 进行搜索，找到了之前新建的 Action 对应的流程日志记录：
打开订单的 Fraud Reports 面板，查看检查记录：
Email 字段检查结果：客户维护的 Email 字段是一个有效的邮箱地址。
首单检查(First Time Order Check)返回的分数是 100，根据 SAP 电商云当前配置，这个结果被判定为首单。
SAP Marketing Cloud API 调用返回的结果：
SAP 云平台 Business Partner API 调用返回的结果：
我们再来看看另一个使用 Kyma 扩展 SAP 销售云即 SAP Cloud for Customer Sales 模块的例子。
这是一个所谓 Account Address Enrichment 的场景，用户在 SAP 销售云里创建 Account 主数据时，只需维护基本的地址信息，点击保存后，销售云发送事件给 Kyma，后者响应该事件，调用 SAP API Hub上的 Address 微服务，把 Enrich 之后的地址详情，通过销售云 Account OData API 进行写回。这个增强可以减少销售云用户录入 Account 数据的工作量。
这个增强最关键的一步，就是打通 SAP 销售云与 Kyma 的连接，让 Kyma 能够接收到 SAP 销售云运行业务流程时抛出的事件。
进入 SAP 销售云 Administration 工作中心 的 Event Notification 配置页面：
新建一个销售云 OData 事件的消费者，即 Kyma 实例。
Consumer 创建页面需要维护远端 Kyma Application Connector url：
这个 url 可以通过登录 Kyma 控制台，点击 Connect Application 按钮生成：
回到销售云配置页面，指定将 Account 和 Opportunity 这两个 Business Object 的创建和更新事件，发送给 Kyma.
这些 Business Object 的事件发布行为，通过销售云的 Subscription 来描述：
保存配置后，到 Kyma 控制台，此时就能观察到 SAP 销售云(Sales Cloud) 注册的事件了。
点击 SAP Sales Cloud，能够查阅注册事件的技术明细，比如事件负载(Payload) 格式，包含的字段名和数据类型等。
剩下的就是和之前扩展 WordPress 以及 SAP 电商云一样的操作，在 Kyma 中基于 SAP 销售云注册的事件，创建 Lambda Function，解析事件参数并进行相应处理。出于文章篇幅限制，在 Lambda Function 里仅仅简单将销售云传入的事件对象的内容打印出来。
在 SAP 销售云里新建一个 Opportunity 并保存。
到 Kyma Lambda Function 日志控制台里，观察到了函数体里使用 console.log 打印出的来自 SAP 销售云的 Opportunity 创建事件包含的字段：
总结
本文首先简要介绍了 Kyma 这个底层基于 Kubernetes 的开源云原生应用开发平台和运行时，接着分成两大部分，分别分享了使用 Kyma 对传统的 On-Premises 应用(WordPress) 和企业级云原生应用(SAP 电商云和 SAP 销售云)进行扩展的案例。
这些扩展案例均来自笔者实际工作中的项目经历，希望能起到抛砖引玉的作用，感谢阅读。
