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應用都貼心地提供了可以雲端試用的版本,通過如下鏈接訪問:
https://www.sapfioritrial.com/
點擊鏈接之後,在Fiori Launchpad裏能看到CRM目錄下存在若干Tile,它們是SAP成都研究院CRM Fiori開發團隊負責開發和維護的,Jerry也曾經是這個團隊的一員。隨便點擊一個Tile, 比如My Opportunities:
然後我們能看到該應用的明細頁面了。在Chrome開發者工具的Network標籤頁,我們能觀察到一個對於metadata的請求:
關於Chrome開發者工具的使用技巧,Jerry曾經做過整理,單獨寫在另一篇文章裏:
我們把這個metadata請求的url從Chrome開發者工具裏拷貝出來,完整鏈接如下:
直接在瀏覽器裏訪問這個鏈接,就能觀察到包含在鏈接里名爲CRM_OPPORTUNITY的OData服務的metadata(元數據)。我們可以把一個OData服務的模型類比成一個SAP Business Object,該模型同樣由一個根節點和若干子節點組成,每個節點包含若干字段。某些節點提供了一些可以執行的邏輯,在OData協議裏稱這些邏輯爲function import(相當於Business Object裏的action)。不同節點之間通過定義Navigation建立關聯關係——SAP基於Netweaver的不同產品的建模方式思路都類似,可以觸類旁通。
另一個重要的請求:
在Jerry的另一篇文章 SAP UI 搜索分頁技術 裏已經對這個請求做過分析:
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幫助文檔:
https://help.sap.com/doc/saphelp_hba/1.0/en-US/dd/f1ceb93a7d48fab4aa16efebc90e02/frameset.htm
關於SEGW更多開發細節,可以參考我的SAP同事環宇的公衆號文章:
環宇有一個名爲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的修改和創建操作,請按照我的另外兩篇博客去實現:
Enable CRM Service Order application with edit functionality
Enable CRM Service Order application with create functionality
值得一提的是,在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請求的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做過的三個維度的分析:
How is OData request routed to Offline data store by Odata offline plugin
How is JavaScript code in OData offline plugin delegated to native Java code in Android
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和微信的交互,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的原創技術文章,請關注公衆號」汪子熙」或者掃描下面二維碼: