揭開SAP Fiori編程模型規範里註解的神秘面紗 - @OData.publish工作原理解析

Jerry的前一篇文章揭開SAP Fiori編程模型規範里註解的神秘面紗 – @ObjectModel.readOnly工作原理解析，給大家分享了@ObjectModel.readOnly這個註解對應的Fiori UI和ABAP後台的工作原理。

今天我們繼續研究另一個註解@OData.publish.

在SAP官網的ABAP Programming Model for SAP Fiori的幫助文檔里，在OData Annotations目錄下有對這個註解的介紹：

https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/1709%20000/en-US/ccdb054e4ecf4573829d4ba258cafa72.html

一旦加上了這個註解的CDS view激活時，會自動生成一個OData服務。

這個OData服務是如何自動生成的？這就是本文所要分享的內容。

假設我們對加了這個註解的CDS view激活後自動生成的OData服務的明細一無所知，從何處開始入手進行研究呢？

我創建了一個名為zjerrytest20160311的view，然後加上這個註解，激活。根據我的經驗，按照SAP慣例，自動生成的OData服務的名稱應該也會包含0311這個字元串。

激活之後，我試著用0311作為關鍵字在OData服務的註冊事務碼/IWFND/MAINT_SERVICE里搜索，果然搜到了對應生成的OData服務：

在Jerry之前的文章 ABAP CCDEF, CCIMP, CCMAC, CCAU, CMXXX這些東東是什麼鬼曾經提到ABAP Netweaver的註冊表TADIR，按照0311進行查詢，發現CDS view激活之後，除了OData服務本身，還自動生成了下列這些對象：

IWMO: SAP Gateway Business Suite Enablement對應的模型 IWSV: SAP Gateway Business Suite Enablement對應的服務 CLAS: OData服務的實現類ZCL_ZJERRYTEST20160311

做個實驗，當我把OData.publish的值設置為false，再次激活，發現類型為IWMO和IWSV的對象從註冊表TADIR中消失了，這再次印證了二者是註解OData.publish設置為true之後激活CDS view生成的。

那麼如何研究CDS view激活時，這兩個對象的自動生成邏輯呢？

打開ST05跟蹤模式，激活CDS view，在資料庫跟蹤結果里果然發現了將自動生成的對象名稱插入到註冊表TADIR的OPEN SQL語句。

《神鵰俠侶》天竺僧去絕情谷給楊過找情花毒解藥時，說過一句話：毒蛇出沒之處，七步之內必有解藥。

同樣，在ABAP里，在插入資料庫表的OPEN SQL語句之前，必定有待插入數據的生成邏輯。

點擊ST05里藍色的眼鏡圖標，自動跳轉到OPEN SQL語句里。設置斷點，激活CDS view，斷點觸發：

從當前的調用棧往外追溯，發現在第21個調用棧幀，正是自動生成OData服務的地方：

CL_WB_DDLS_SECOBJ_HNDLR_SINGLE->IF_DDIC_WB_DDLS_SECOBJ_HANDLER~ON_ACTIVATION

這個方法首先根據delta_state判斷出需要刪除，新增或者更新的對象清單，分別存儲在下圖12到14行三個輸出參數里。

舉個例子，當我在一個已經激活過後的CDS view源程式碼里添加@OData.publish:true的註解，然後激活，此時該註解對於的EDIT_STATE為N(New), 而其他的註解因為沒有任何變化，被標記為U(Unchanged).

此處會根據EDIT_STATE的值，進入對應的分支。

EDIT_STATE值為N的分支，則執行OData服務的創建，通過CL_SADL_GTK_ODATA_SERVICE_GEN完成，後綴GEN代表Generation.

從調試器里能看出，名稱為ZJERRYTEST20160311的OData服務通過create_via_exposure方法被創建。

完整的調用棧：

本文其實也是另一個具體的例子，在不了解一段邏輯(無論框架層面或者應用層面)的情況下，如何使用ST05這個工具來找到設置斷點的程式碼位置，從而找到問題分析的突破口。

感謝閱讀。