OData(Open Data Protocol)協議是一個開放的工業標準，用於定義RESTFul API的設計和使用。我的文章標題前加上SAP的字首，只是為了表明這篇文章介紹的是Jerry在SAP專案開發中使用到OData的一些心得和經驗。

目前OData被廣泛用於SAP Business Suite和SAP S/4HANA的眾多Fiori應用中，以及SAP Customer Engagement Center和一些正在開發的新一代雲產品中。此外OData也是SAP Cloud for Customer推薦的一種將C4C和客戶第三方應用整合的技術手段。關於這種整合方式，在我的另一篇文章裡有所介紹：

本文會從OData服務的實現和消費這兩個方面來介紹，目錄如下：

在SAP Business Suite中進行OData開發
在SAP S/4HANA中進行OData開發
使用ABAP程式碼消費OData服務
使用Java程式碼 + Apache Olingo消費OData服務
使用UI5消費OData服務
OData效能測試
C4C中的OData應用
XS OData Services
更多閱讀

在SAP Business Suite中進行OData開發

以SAP CRM為例。SAP對於很多Fiori應用都貼心地提供了可以雲端試用的版本，透過如下連結訪問：

點選連結之後，在Fiori Launchpad裡能看到CRM目錄下存在若干Tile，它們是SAP成都研究院CRM Fiori開發團隊負責開發和維護的，Jerry也曾經是這個團隊的一員。隨便點選一個Tile, 比如My Opportunities：

然後我們能看到該應用的明細頁面了。在Chrome開發者工具的Network標籤頁，我們能觀察到一個對於metadata的請求：

關於Chrome開發者工具的使用技巧，Jerry曾經做過整理，單獨寫在另一篇文章裡：

Jerry和您聊聊Chrome開發者工具

我們把這個metadata請求的url從Chrome開發者工具裡複製出來，完整連結如下：

sap/opu/odata/sap/CRM_OPPORTUNITY/$metadata?sap-language=en&sap-client=001

直接在瀏覽器裡訪問這個連結，就能觀察到包含在連結里名為CRM_OPPORTUNITY的OData服務的metadata(後設資料)。我們可以把一個OData服務的模型類比成一個SAP Business Object，該模型同樣由一個根節點和若干子節點組成，每個節點包含若干欄位。某些節點提供了一些可以執行的邏輯，在OData協議裡稱這些邏輯為function import(相當於Business Object裡的action)。不同節點之間透過定義Navigation建立關聯關係——SAP基於Netweaver的不同產品的建模方式思路都類似，可以觸類旁通。

另一個重要的請求：

sap/opu/odata/sap/CRM_OPPORTUNITY/Opportunities?$skip=0&$top=20&$inlinecount=allpages&sap-client=001

在Jerry的另一篇文章 SAP UI 搜尋分頁技術裡已經對這個請求做過分析：

$skip=0&$top=20：通知後臺執行分頁搜尋，只將滿足查詢條件的前20條記錄從資料庫取出，返回給UI。
$inlinecount=allpages: 返回資料庫滿足搜尋條件的記錄數。因為Jerry未指定搜尋條件，所以返回系統裡Opportunity的總個數1051。

下面簡單介紹SAP Business Suite系統裡如何開發OData模型和服務。

在動手開發前，我們需要先溫習Fiori的架構。

在我的文章 SAP Fiori應用的三種部署方式裡提到過這張圖：

談到Fiori開發時，就這張圖而言，可以總結成兩句話：

1. 在ABAP Back-End伺服器上做OData模型和服務的開發

2. 在ABAP Front-End伺服器上做OData服務的註冊，以便讓Fiori應用能夠消費

首先我們到ABAP Back-End伺服器上，使用事務碼SEGW開啟CRM_OPPORTUNITY這個OData服務。可以看到Data Model裡包含了很多節點，每個節點實際上由一個ABAP DDIC Structure實現，節點上的每個欄位對應著Structure上的欄位。我們定義好OData模型包含哪些Structure之後，點選工具欄的Generate Runtime Objects按鈕：

SAP Gateway框架就會基於我們定義的OData模型，自動生成4個ABAP類和兩個模型。

MPC和MPC_EXT：當消費者訪問該服務的metadata時，這兩個類負責把透過ABAP DDIC Structure描述的metadata資訊轉換成OData協議規範的格式並返回。每次開發人員修改OData模型，點選Generate按鈕後，MPC的程式碼都會重新生成。如果開發人員需要在模型上新增一些額外資訊，比如一些版本控制資訊或者相關注解(annotation),那麼需要在MPC_EXT裡透過ABAP程式碼實現。MPC_EXT是MPC的子類，其程式碼不會被Generate按鈕覆蓋。一個例子如下：

DPC和DPC_EXT：包含了OData服務的實現，實際上也就是基於OData模型的CRUD操作，搜尋操作和function import的實現。以Opportunity為例，因為該模型底層使用的是CRM One Order模型，所以DPC_EXT裡包含了大量CRM_ORDER_*等函式呼叫，CRM顧問朋友們對這些函式應該非常熟悉。

在ABAP Back-End伺服器做好OData開發後，登陸ABAP Front-End伺服器，使用事務碼/IWFND/MAINT_SERVICE將後臺伺服器做好的OData服務進行註冊。

下圖是OData服務在ABAP Front-End伺服器的註冊介面。從下圖能看出理論上一臺ABAP Front-End伺服器可以連線多臺ABAP Back-End伺服器，

SAP把這種1:N的關係稱為Multiple Origin Composition，典型的使用場景比如一家跨國企業，其美洲分公司的應用執行於Back-End伺服器1，歐洲分公司位於Back-End伺服器2。一個銷售經理使用Fiori應用檢視該企業某個時間段內全球的銷售資料，則其OData實現會將這兩臺伺服器的後臺資料蒐集起來，進行彙總並返回給UI。具體細節請參考SAP幫助文件：

關於SEGW更多開發細節，可以參考我的SAP同事環宇的公眾號文章：

十分鐘手把手系列之SEGW Project入門

環宇有一個名為Fiori的公眾號，介紹的全是Fiori知識。感興趣的朋友可以關注一下。

在S/4HANA中進行OData開發

在我的公眾號文章 Hello World, S/4HANA for Customer Management 1.0 裡提到，CDS view是S/4HANA裡一個重要的建模方式。

我們還是來看個具體的例子。假設需要在S/4HANA裡開發一個管理Service Order的Fiori應用，功能暫定為支援對Service Order的只讀操作，即查詢和瀏覽。藉助S/4HANA的CDS view建模技術，我們不需要寫一行JavaScript，就可以自動生成一個滿足需求的Fiori應用，聽起來是不是很神奇？

我們需要建立一個CDS view，用它來自動生成OData的模型和服務，即下圖綠色的Z_C_Service_Order_View。該View又從其他更底層的CDS view取資料，將Service Order的抬頭，行專案，狀態資訊等資料聚合在一起。

CDS view開發完畢後，只需要在事務碼SEGW裡將其透過Reference->Data Source載入進去：

就可以自動生成OData模型，以及前一章節提到的MPC和DPC各兩套一共4個ABAP Class，分別對應下圖藍色和紅色區域所示，無需應用開發人員再寫ABAP程式碼。

然後用SAP WebIDE建立一個新的Fiori應用，注意建立時不要使用普通的SAPUI5 Application模板，而採用Smart Template Application模板。在建立嚮導裡指定之前基於CDS view自動生成的OData服務。

點選向導的Finish按鈕，最終不用寫一行JavaScript程式碼，就得到這樣一個Fiori應用：

上圖提到的CDS view的原始碼，以及Smart Template的工作原理，都在我的部落格裡：

Create a CRM Service Order Fiori application within a couple of minutes

更進一步，如果想給這個自動生成的Fiori應用增添一些功能，例如支援對Service Order的修改和建立操作，請按照我的另外兩篇部落格去實現：

值得一提的是，在CDS view裡有一個強大的註解：

@OData.publish: true

和SpringBoot的註解能實現很多神奇的功能一樣，被該註解定義過的CDS view，能夠不借助SEGW的幫助，自動生成OData模型和服務，進一步簡化了開發人員做OData開發需要的配置，有助於開發人員快速構建出標準化的OData服務。

@OData.publish這個註解的實現原理，請參考我的CDS view自學教程系列的第4部分：

Part 4 how does annotation @OData.publish work

OData服務的消費

前面說了這麼多都是OData模型和服務的開發，現在來談談如何消費。

使用ABAP程式碼消費OData服務

以消費C4C Opportunity的標準OData服務為例。

首先在postman裡搞清楚如何使用HTTP Post加上OData的$batch操作來建立Opportunity：

其實最主要的工作量就是把$batch操作的一整套流程用ABAP程式碼實現。$batch請求的body透過下圖程式碼裡insert_line這個自定義宏操作的一系列字串去填充。

因為ABAP Netweaver既可作為Web Server，又可作為Web Client，所以使用ABAP程式碼消費OData這種RESTFul API，實質上是利用了IF_HTTP_CLIENT的SEND和RECEIVE方法，進行網路請求的傳送和接收。

我在SAP Community上寫過一個用ABAP程式碼消費OData服務的教程：

Consume standard C4C OData service via ABAP code

使用Java程式碼 + Apache Olingo消費OData服務

相信大多數開發人員都不願意像下面的程式碼這樣直接操作OData $batch body，既麻煩又容易出錯。

於是在Java裡就有了Apache Olingo，一個開源庫，您可以把它當成OData的Java SDK，封裝了OData底層的細節。$batch操作需要填充的BatchChangeSet和BatchChangeSetPart在Olingo裡都有了對應的類進行封裝，看看下圖使用Java程式碼呼叫OData服務進行ServiceTicket 的建立，和上圖ABAP程式碼進行比較，是不是從語義上看清晰了很多？

上圖的完整Java程式碼，參考我的github

使用UI5消費OData服務

在SAP UI5官網上能找到詳細的API說明。

Jerry只補充兩點原創內容。

1. UI5 OData API的同步和非同步引數。

2015年6月時，我和德國一位負責Quality的同事就這個話題在半小時的電話會議裡產生了爭執。因為時間有限，我沒能在電話裡說服他，所以就有了這篇部落格。德國同事看了之後，同意了我的意見。具體細節參考部落格：

A Test on Fiori OData request Synchronous mode VS Asynchronous mode

下圖是5個請求以同步模式發出在Chrome開發者工具Network標籤頁中觀察到的時序：

下圖是5個請求以非同步模式發出：

2. 在SAP雲平臺的CloudFoundry環境下消費ABAP On-Premise OData服務

場景：在微信裡消費On-Premise系統的OData服務。

詳細步驟已經在我之前的微信公眾號文章介紹過了。

OData效能測試

1. 使用Netweaver提供的效能測試工具

詳細介紹參考我的部落格：

How to find OData performance trace and payload trace functionality

2. 使用JMeter測試OData服務在高併發場景下的效能指標

在Jerry工作過的客戶專案裡，很多客戶提出了這種效能測試要求，比如同時發起1000個Service Request的OData建立請求，測量其平均響應時間。

Jerry在這兩篇部落格裡介紹了兩種辦法：

(1) 自己寫Java程式碼，用多執行緒程式設計技術，每個執行緒發起一個OData建立請求，自己度量平均響應時間。

(2) 使用效能測試神器JMeter，這樣一行程式碼都不用寫。

兩種辦法的具體介紹參考我的部落格：

Kapsel OData plugin原理講解

SAP移動解決方案的Offline(離線)模式使用了Kapsel OData plugin，用於將業務資料從後臺系統抽取出來，儲存於裝置本地的離線儲存區域。

關於其工作原理，參考Jerry做過的三個維度的分析：

C4C中的OData應用

Jerry做過的C4C客戶專案中對OData使用的一些分享：

Leverage C4C Odata notification to monitor C4C Opportunity change in CRM system

使用場景：在C4C建立業務資料後，利用這篇部落格介紹的用法，能自動傳送一個通知給其他系統/應用。可以作為一種輕量級的系統整合方案。
Expose TextCollection data belonging to a Custom BO via OData service

該解決方案我提供給了一個Chinese C4C客戶。
Expose Custom BO logic implemented by ABSL via Custom OData service

透過OData將用ABSL實現的自定義邏輯暴露給第三方應用。
C4C和微信整合系列教程

這個系列教程裡，C4C和微信的互動，60%使用了C4C OData，40%使用了C4C Web Service。

XS OData Services

HANA Studio裡開發的HANA view也能透過HANA Extended Application Service暴露成OData服務。

據我的成都同事介紹，SAP Customer Engagement Center採用的就是這種方式。

更多介紹參考這篇SAP部落格:

HANA Development: XS OData Services

更多閱讀

所有更多閱讀的連結都已經分佈在文章的每一章節，這裡為閱讀方便起見，將部分連結再次統一羅列如下：

要獲取更多Jerry的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

SAP OData程式設計指南

相關文章