SAP API開發方法大全

注销發表於2020-04-06

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/2 0/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的文章：