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二次开发从业者们有所启发,感谢阅读。
要获取更多Jerry的原创文章,请关注公众号"汪子熙":
原文地址:https://www.cnblogs.com/sap-jerry/p/11396970.html