一种基于事件驱动架构的 SAP 产品集成方案介绍

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)相比较的优势。