云端ABAP應(yīng)用調(diào)試方法是什么

172次閱讀

共計 1837 個字符，預(yù)計需要花費 5 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“云端 ABAP 應(yīng)用調(diào)試方法是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

Jerry 之前在 SAP Cloud Platform 上進(jìn)行 nodejs 和 Java 開發(fā)的時候，對運行在云上的用這兩門語言開發(fā)的應(yīng)用的單步調(diào)試很頭痛。盡管仍然可以通過 Jerry 這篇文章
如何提高后臺服務(wù)應(yīng)用問題的排查效率？日志 VS 遠(yuǎn)程調(diào)試里介紹的端口映射方式實現(xiàn)在本地電腦上調(diào)試云端應(yīng)用的功能，但 Jerry 還是懷念 On-Premises ABAP 里面那種單步調(diào)試的便捷性——鼠標(biāo)輕輕一點，斷點即設(shè)置好，無需任何配置，立即就能進(jìn)行單步調(diào)試。

那么現(xiàn)在 ABAP 到了云端后，其單步調(diào)試還和之前的 On-Premises 環(huán)境里一樣易于使用么？答案是肯定的。

咱們就拿一個具體例子來體驗。

Jerry 通過 Restful ABAP Programming 系列的前兩篇，已經(jīng)開發(fā)出了一個支持增刪改查，支持自定義數(shù)據(jù)校驗和 Action 的 Fiori 應(yīng)用。

我選中 ID 為 103 這條記錄，點擊 Accept Travel 按鈕后，期望通過該 Action 將其狀態(tài)設(shè)置為 Accepted：

不幸的是，我沒能看到期望中的狀態(tài)變化，而是下面這個所有 ABAP 編程人員都不愿意看見的 ABAP 運行時錯誤提示界面。

不過，大家注意到了上圖右下角的 Debug 超鏈接么？和 SAPGUI 一樣，點擊之后立即就能打開調(diào)試器，能夠觀察發(fā)生這個運行時錯誤的調(diào)用棧，引起錯誤的詳細(xì)代碼位置和相關(guān)變量的值。

順便提一句，如果您想自定義在 SAP GUI 里出現(xiàn)的 ABAP 運行時錯誤顯示(就是在 On-Premises 環(huán)境下 ST22 事務(wù)碼里看到的內(nèi)容)，比如添加一段佛祖保佑，永無 BUG，那么可以參考 Jerry 這篇文章：

你的 ABAP 程序給佛祖開過光么？來試試 Jerry 這個小技巧

回到 ABAP Development Tool 里，我們先點擊 Show 超鏈接，就可以看到運行時錯誤明細(xì)：Short Text 告訴我們，我們點擊 Accept 按鈕后，相關(guān)的處理框架有意地拋出一個 CX_CSP_ACT_RESPONSE 的異常。拋出異常的位置是在程序 CL_CSP_ACT_CHECK_FEATS_ACTIONS 里，這暗示我們，這個錯可能和 Action 執(zhí)行前的檢查 (CHECK) 有關(guān)。

繼續(xù)向下滑動鼠標(biāo)，發(fā)現(xiàn)在框架代碼內(nèi)，因為從第 353 行內(nèi)表 it_feature_result 里沒有讀出任何內(nèi)容，因此 sy-subrc 不為 0，導(dǎo)致進(jìn)入第 355 行的 RAISE SHORTDUMP 分支。

在 SAP Cloud Platform ABAP 環(huán)境下當(dāng)前登錄用戶發(fā)生的所有運行時錯誤，可以在 ABAP Development Tool 的 Feed Reader 視圖下查看，這個功能相當(dāng)于 SAP GUI 里的 ST22 事務(wù)碼。

現(xiàn)在我們關(guān)于這個運行時錯誤的靜態(tài)信息了解得差不多了，下一步在調(diào)試器里觀察。

重新啟動 Fiori 應(yīng)用，再次點擊 Accept 按鈕，出現(xiàn)運行時錯誤后點擊 Debug 超鏈接，ABAP 調(diào)試器自動彈出，引起運行時錯誤的那一行代碼被高亮，同時左邊顯示出調(diào)用棧。

把鼠標(biāo)放在 it_feature_result 上，發(fā)現(xiàn)這個內(nèi)表是空的，當(dāng)然無法從里面讀出數(shù)據(jù)了。這個內(nèi)表是當(dāng)前 ABAP 類 CL_CSP_ACT_CHECK_FEATS_ACTIONS 的方法 handle_rejected_instances 的輸入?yún)?shù)，需要搞清楚為啥這個輸入?yún)?shù)為空。

從拋出運行時異常的棧幀往外看一幀，就知道這個輸入的內(nèi)表是通過第 291 行的 execute_feature_controllers 生成的，這個方法會通過回調(diào)函數(shù)的方式，調(diào)用我們在 Behavior Definition 實現(xiàn)的一個 get_features 方法里：

這里我們就找到了引起這個運行時錯誤的根源：因為之前 Jerry 出于測試目的，注釋了一段代碼，導(dǎo)致 get_features 被框架回調(diào)時，沒有返回框架期望的數(shù)據(jù)：

當(dāng) Jerry 把這段需要的代碼重新 enable 然后設(shè)置斷點，點擊 Accept 按鈕，通過調(diào)用棧可以清晰看到框架的 execute_feature_controllers 是如何調(diào)用到我們實現(xiàn)的 get_features 回調(diào)方法的。