Kyma 是 SAP 开源的一个基于 Kubernetes 的云原生应用开发平台，能够允许 SAP 的 partners 以简捷而现代的方式，对 SAP 的云解决方案和传统 On Premises 产品进行连接，集成和扩展。所谓“现代”，即 partners 在进行二次开发时，可以充分利用近些年来企业级开发领域不断涌现出的新技术，比如 Serverless 计算，微服务架构等等。

Kyma 是完全开源和免费的，任何人都可以试着在自己的本地电脑上进行安装。当然，尝试自己本地安装有一些门槛，因为安装过程中需要从 Google 的网站上拖取一些 Kubernetes 相关镜像。

而 SAP Cloud Platform Extension Factory，是 SAP 在开源项目 Kyma 上进一步完善而推出的一个商业化解决方案，本身并不单独卖，而是作为 SAP 云平台的一个组成部分。

Kyma 和 SAP Cloud Platform Extension Factory 的关系，就好比 Open UI5 和 SAP Fiori 目前使用的 UI5 框架之间的关系一样。

本文我们把通过 SAP Kyma 进行扩展的对象换成 C/4HANA 中的一朵云，SAP Cloud for Customer(C4C)。Jerry 希望每当 C4C 中有新的 Opportunity 创建时，C4C 都会把这个事件通知给 Kyma 上的 Lambda Function，后者作为事件监听函数，可以进行对应的处理，具体做什么逻辑，大家可以试着开开自己的脑洞。

比如实现一个 Account Address Enrichment 的功能，就是用户在 C4C 里创建 Account 时，只需要维护基本的地址信息，然后点击保存，C4C 发送事件给 Kyma，后者接到这个事件后，调用 SAP API Hub 上的 Address 微服务，把丰富过后的地址详情通过 C4C Account OData API 调用的方式，写回 C4C。通过这个增强，减少了 C4C 用户录入数据的工作量，同时也展示了 Kyma 与被其扩展的 C/4HANA 产品的数据双向读写功能。

下面我们就来看看这个扩展如何完成。

首先当然是要把 C4C 同 Kyma 建立起互相信任的连接了。对于 SAP partners 来说，好消息是这个连接的配置是一个黑盒子，通过下图 Kyma 的 Application Connector 模块完成，partners 不需要了解其技术实现。

首先进入 SAP Cloud for Customer 的 Administration 的工作中心，打开 General Settings 视图，进入 Event Notification 配置 UI：

新建一个 C4C OData 事件和 API 的消费者：

类型选择 SAP Cloud Platform Extension Factory，即 Kyma：

这个 Remote Environment URL 从哪里来呢？就是 SAP Kyma 应用里的 Application Connector 对应的 url：

到 Kyma 控制台的应用里，点击 Connect Application，就得到了需要维护到 C4C 里的 url：

维护了回调用户名和密码之后，再添加 Subscription，即您希望将 Cloud for Customer 系统里的哪些 BO 事件，发布给 Kyma：

我选择了 Account 和 Opportunity 这两个 BO 的创建和更新事件，暴露给 Kyma：

成功保存并激活配置：

回到 Kyma 的应用界面，在 Provided Services & Events 界面下，此时能看到 Cloud for Customer 发布过来的 API 和事件了：

进入 Kyma Service Management 的 Catalog 界面下，找到从 Cloud for Customer 系统导入进来的服务，

进入服务明细，能观察到 Cloud for Customer 系统发布的 BO 事件的字段参数，

以及该 C4C 系统所有支持的 OData API 列表。如果我们期望在 Kyma 的 Lambda Function 里对 C4C 的数据进行写回操作，就得使用这些 OData API.

接下来，我们就可以基于这些 API 和事件进行 Lambda Function 的开发了。首先基于 C4C 导入进来的服务，创建一个新的实例：

确保实例处于运行状态：

然后基于该实例创建一个新的 Lambda Function：

Lambda Function 的触发方式，选择之前 C4C 暴露的 BO 创建和修改事件：

这里简单的打印出 C4C 传递过来的事件参数：

至此 Kyma 端的开发和配置就结束了，是不是觉得步骤非常简单明了？

现在到 C4C 里创建一个新的 Opportunity，保存：

到 C4C 的 Event Notification Monitoring 界面去，观察到 Opportunity 创建的事件已经成功被投递到 Kyma 去了，对应的 Kyma 实例的 url 也可以在投递明细里查看到。

再回到 Kyma Lambda Function 的日志界面，这里也看到了 Lambda Function 实现体里打印出的来自 C4C 的事件明细：

为什么只打印了两个 guid 呢？因为 C4C 暴露的 BO 事件，其参数规范里就只包含了发生事件的当前节点和 Root 节点的 guid.

大家可以试着比较一下，如何使用 C4C 传统的二次开发方式，该如何监听 BO 的创建和更新事件呢？那就是使用 SAP Cloud Application Studio，在 Solution 里创建 BO 增强，然后在 BO 节点上创建 AfterModify 并通过 ABSL 编程实现。

而 SAP Kyma 的横空出世，确实像 SAP 的官方宣传那样，给 SAP partners 们提供了一种不同于过去在 ABAP 平台上进行的全新的二次开发方式。通过 SAP Kyma 提供的事件监听机制，进行 SAP 二次开发的从业人员不再需要对被增强的 SAP 解决方案的技术细节有过多的了解，仅仅在 Kyma Lambda Function 定义好的接口上下文内，调用公开稳定的 API，即可完成开发任务。

总结

本文通过笔者实际工作中参加过的一个使用 Kyma 基于事件驱动的松耦合方式同 SAP Cloud for Customer 进行集成的项目经验分享，阐述了这种方式同传统的应用内扩展(In Application Extension)相比较的优势。