还在用ABAP进行SAP产品的二次开发？来了解下这种全新的二次开发理念吧

Jerry从2018年底至今，已经写了一系列关于SAP Kyma的文章，您可以移步到本文末尾获得这些文章的列表。Kyma是SAP开源的一个基于Kubernetes的云原生应用开发平台，能够允许SAP的partners以简捷而现代的方式，对SAP的云解决方案和传统On Premises产品进行连接，集成和扩展。所谓“现代”，即partners在进行二次开发时，可以充分利用近些年来企业级开发领域不断涌现出的新技术，比如Serverless计算，微服务架构等等。

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

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

Kyma和SAP Cloud Platform Extension Factory的关系，就好比Open UI5和SAP Fiori目前使用的UI5框架之间的关系一样。在Jerry这篇文章特殊的上下文里，因为Jerry不想每次都敲出“SAP Cloud Platform Extension Factory这五个单词”，所以下文还是统一用Kyma这个词。

Jerry之前的文章 WordPress，SAP Kyma和微信三者的集成，介绍了如何使用SAP Kyma中的Lambda Function，监听WordPress中的post.created事件，从而完成对WordPress的增强。

今天这篇文章，让我们把通过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创建和修改事件：

由于文章篇幅原因，这里暂时不介绍在Kyma Lambda Function里如何调用C4C的OData API，而只是简单的打印出C4C传递过来的事件参数：

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

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

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

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

为什么只打印了两个guid呢？因为C4C暴露的BO事件，其参数规范里就只包含了发生事件的当前节点和Root节点的guid. 至于如何在Kyma的Lambda Function里调用C4C的OData, 咱们将来再聊。

大家可以试着比较一下，如何使用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，即可完成开发任务。

希望本文能够对广大的SAP二次开发从业者们有所启发，感谢阅读。