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)相比較的優勢。