Jerry之前的文章：從SAP Leonardo到SAP Data Intelligence 曾經提到，SAP Leonardo Machine Learning Foundation的機器學習API已經被標註為deprecated狀態，將由SAP新的AI產品，SAP Data Intelligence所替代。
在學習SAP Data Intelligence的過程中，Jerry算是瞭解到了一種新的API開發方式。本文首先簡單回顧一下我從事SAP開發工作13年以來，接觸過的各種SAP API的開發方式，然後再介紹SAP Data Intelligence裡遵循Low Code Development(低代碼開發)理念的API開發方式。
文章目錄
(1) ABAP function module + SOAMANAGER
(2) 基於事務碼SEGW的SAP CRM OData服務手動實現
(3) 基於CDS view的OData服務自動生成
(4) SAP Cloud for Customer裡基於Business Object的自定義OData API創建
(5) 基於Java SpringBoot，Node Express等Web應用框架的API開發
(6) Serverless 架構
(7) SAP Data Intelligence Graph
本文提到的API，指的是通過HTTP協議暴露出來，能直接通過瀏覽器，Postman，curl等各種工具，以及各種編程語言消費的API. 在SAP生態圈內，最常遇到的是基於SOAP的Web Service和串聯SAP S/4HANA前後臺的OData服務。
(1) ABAP function module + SOAMANAGER
最古老的技術，把ABAP系統裡的函數通過SOAMANAGER發佈成Web Service. 雖然古老，但至今S/4HANA裡的Service模塊的新功能開發還在使用。
https://blogs.sap.com/2014/05/20/step-by-step-to-create-consume-and-trace-web-service-in-abap-system/
我2014年的時候也寫過一篇介紹SOAMANAGER使用步驟的文章，雖然到現在為止，這個工具已經更新換代多次了。
(2) 基於事務碼SEGW的SAP CRM OData服務手動實現
這是我最熟悉的SAP OData服務實現方式，因為我就是SAP CRM OData服務的開發者之一。SAP成都研究院CRM開發團隊在2014和2015年開發這些OData服務時，SAP Fiori Elements的前身，當時的名稱是Smart Template，還處於發展初期，所以那時候我們沒有選擇這項基於元數據驅動的開發方式。
Jerry在2018年寫過一篇文章 SAP OData編程指南， 裡面詳細介紹了這種方法。
(3) 基於CDS view的OData服務自動生成
再後來，隨著CDS view和Fiori Elements的成熟，我們可以基於加上了@OData.publish註解的CDS view，直接生成OData服務了，具體工作原理在我的這篇文章裡有介紹：
揭開SAP Fiori編程模型規範裡註解的神秘面紗 - @OData.publish工作原理解析
在S/4HANA裡，除了在ABAP Development Tool裡手動給CDS view加上@OData.publish註解之外，還可以採取另一種方式，純粹在瀏覽器裡完成操作。
使用S/4HANA裡的Custom CDS Views這個應用，
可以選擇S/4HANA裡多個標準的CDS view來創建新的複合視圖，
並能根據自己的需求，來挑選哪些標準視圖的字段需要包含到新的複合視圖裡：
最後也是一鍵實現複合視圖的OData服務發佈。
到了SAP雲平臺ABAP環境上，基於CDS view創建的Service Definition和Service Binding，把OData服務和Fiori UI界面的創建全部包辦了。
更多關於這種基於Restful ABAP Programming模型的開發方式，請參考我的文章 30分鐘用Restful ABAP Programming模型開發一個支持增刪改查的Fiori應用。
(4) SAP Cloud for Customer裡基於Business Object的自定義OData API創建
前面在SAP S/4HANA Fiori Launchpad裡看到的Custom CDS View這個應用，即使不太懂技術的Key User，也能在瀏覽器裡完成字段的搭配和OData服務的發佈。
SAP Cloud for Customer也有類似的設計，只不過供Key User選擇的不是CDS view，而是C4C裡標準的Business Object.
Key User在瀏覽器的Custom OData Service應用裡能選擇將Business Object節點裡的哪些字段發佈到OData服務裡，此操作同SAP S/4HANA裡選擇標準CDS view字段的思路是一樣的。
在C4C的Cloud Application Studio裡，還能基於標準Business Object創建Web Service.
總結：基於ABAP技術棧的SAP產品，運行於其上的OData或者Web Service這些API，本質都是通過ABAP Netweaver的ICF(Internet Communication Framework)被外界消費的。我們觀察其調用Url路徑，就能找到SICF事務碼裡的對應的處理節點。
以SAP CRM OData服務Url末尾的CRM_OPPORTUNITY為例：
在SICF事務碼裡能找到對應的同名節點。我們只需要在SICF裡給這個節點綁定一個ABAP類，該節點對應的Url通過瀏覽器或者Postman，或者其他編程語言訪問時，ABAP ICF框架就會自動調用綁定的ABAP類。
也就是說，應用開發人員只需要在ABAP類裡實現業務邏輯，至於這個類運行時的實例如何被ICF調用，如何初始化和銷燬等生命週期管理，ABAP開發人員完全不用操心。
關於更多ABAP ICF的介紹，請參考我的文章：
一個13年ABAP老兵的建議：瞭解這些基礎知識，對ABAP開發有百利而無一害。(5) 基於Java SpringBoot，Node Express等Web應用框架的API開發
採用此類開發方式的生態圈是全球最龐大最活躍的群體，技術成熟穩定，相關文檔和教材非常豐富。更新更先進的開發框架也在不斷演化。開發人員通常在本地完成開發，再將應用部署到服務器上運行。也可以將應用打包成容器鏡像，再以容器的方法運行在物理服務器或者SAP雲平臺，AWS，Google Cloud Platform，Azure等各種雲上。容器數量到達一定規模之後，可以採用Kubernetes進行編排管理。
Jerry這篇文章介紹了一個例子：在SAP雲平臺上部署和運行Docker應用。
Jerry之前的項目裡也消費過SAP Commerce的Web Service：如何使用API的方式消費SAP Commerce Cloud的訂單服務。
(6) Serverless 架構
雲計算行業裡的一個熱門詞彙，Serverless架構，並不意味著採用這個架構後就再也不需要服務器了，而是指應用開發人員不用關心開發好的應用如何部署到服務器，不需要考慮服務器的運行狀態等運營和維護問題。傳統Web應用的開發思路，如Jerry之前介紹的那樣，通常在本地完成開發和單元測試，然後需要考慮採用何種方式，部署到何種服務器或者雲上。
而基於Serverless架構的API/服務開發，根本就沒有API部署的這個步驟。以Jerry之前介紹過的SAP Kyma上的Lambda Function為例，API函數本身的代碼編寫就是在雲上完成。一旦保存，只要API維護的觸發條件滿足(事件觸發或者Url觸發)，該API立即被調用。
下圖是我在SAP Kyma裡使用nodejs編寫的一個Lambda Function：
我設置其通過HTTPS的方式被調用：
在瀏覽器裡訪問這個HTTPS-endpoint，Lambda Function立即執行。
從這個角度講，Jerry覺得ABAP開發人員，在開發API的時候，一直就在享受著Serverless架構帶來的便利。因為ABAP領域的開發，無論是通過SAPGUI，ABAP Development Tool，還是通過各種Key User工具，本質上都是連接到ABAP Netweaver這個集應用開發和運行為一體的服務器上進行的，因而根本沒有傳統Java/nodejs開發裡的應用部署這一環節。
關於更多如何使用Lambda Function實現API的介紹，請參考Jerry的文章：
- 從ABAP Netweaver的SICF到SAP Kyma的Lambda Function
- 周伯通的空明拳，米諾斯的星塵傀儡線，SAP Kyma的Serverless
(7) SAP Data Intelligence Graph
這種方式嚴格來講也算基於Serverless，使用者通過瀏覽器登錄SAP Data Intelligence控制檯，進行Graph建模。完成後啟動，Graph就直接運行在SAP Cloud Platform的Kubernetes基礎設施上了。
之所以把這種方式單獨拿出來介紹，是因為其又具有Low Code Development(低代碼開發)的特質。
看一個具體的例子。
假設我想實現一個支持CRUD的API，消費者通過HTTP GET, POST和DELETE請求，能夠在數據庫裡分別讀取，插入和刪除一條記錄。
低代碼開發平臺，通常都提供了圖形化的用戶界面，給使用者提供了通過拖拽組件和模型驅動開發的方式, 結合少量的編碼來快速創建應用或者API.
訪問SAP Data Intelligence Launchpad，進入Modeler：
我們像小朋友搭積木一樣，從左邊的工具箱裡，拖拽HTTP Server和若干個JavaScript Handler到編輯頁面裡。
這些積木一樣的組件搭配在一起，如何就實現了支持增刪改查的API功能的呢？由於篇幅原因，Jerry後續的文章會介紹，敬請繼續關注。
更多閱讀
- SAP OData編程指南
- 30分鐘用Restful ABAP Programming模型開發一個支持增刪改查的Fiori應用
- 一個13年ABAP老兵的建議：瞭解這些基礎知識，對ABAP開發有百利而無一害
- 在SAP雲平臺上部署和運行Docker應用
- 如何使用API的方式消費SAP Commerce Cloud的訂單服務
- 從ABAP Netweaver的SICF到SAP Kyma的Lambda Function
- 周伯通的空明拳，米諾斯的星塵傀儡線，SAP Kyma的Serverless
- 從SAP Leonardo到SAP Data Intelligence
閱讀更多 汪子熙的游泳故事 的文章
