云端ABAP應用調試方法是什么

本篇內容介紹了“云端ABAP應用調試方法是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

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

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

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

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

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

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

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

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

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

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

繼續向下滑動鼠標，發現在框架代碼內，因為從第353行內表it_feature_result里沒有讀出任何內容，因此sy-subrc不為0，導致進入第355行的RAISE SHORTDUMP分支。

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

現在我們關于這個運行時錯誤的靜態信息了解得差不多了，下一步在調試器里觀察。

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

把鼠標放在it_feature_result上，發現這個內表是空的，當然無法從里面讀出數據了。這個內表是當前ABAP類CL_CSP_ACT_CHECK_FEATS_ACTIONS的方法handle_rejected_instances的輸入參數，需要搞清楚為啥這個輸入參數為空。

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

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

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

“云端ABAP應用調試方法是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！