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二次開發從業者們有所啟發，感謝閱讀。