今天是2020年2月1日鼠年大年初八，這是Jerry鼠年的第 8篇文章，也是汪子熙公眾號總共第 207篇原創文章。

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

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

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

SAP Help Portal

一旦加上了這個註解的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 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啟用時，這兩個物件的自動生成邏輯呢？

使用Jerry文章( SAP錯誤訊息除錯之七種武器：讓所有的錯誤訊息都能被定位) 裡介紹的第六種武器，離別鉤之ST05.

開啟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這個工具來找到設定斷點的程式碼位置，從而找到問題分析的突破口。

感謝閱讀。

更多閱讀

SAP Fiori程式設計模型規範裡註解 - @OData.publish工作原理解析

相關文章