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

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":