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模塊的新功能開發還在使用。
我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的文章：
(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后續的文章會介紹，敬請繼續關注。
更多閱讀
要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":
