一個 SAP Fiori 應用在瀏覽器里突然報出500 Internal Server Error，前端只拿到一段非常籠統(tǒng)的 OData 錯誤響應。Chrome DevTools 能確認請求已經(jīng)抵達 SAP Gateway，HTTP 狀態(tài)碼也清清楚楚，但真正的 ABAP 異常發(fā)生在哪里，究竟是 DPC 擴展類里的數(shù)據(jù)轉(zhuǎn)換失敗，還是 Gateway Framework 在處理 URI 時出了問題，單看客戶端響應往往判斷不出來。這種場景在 SAP Gateway 開發(fā)里很常見。特別是傳統(tǒng)的 SAP Gateway Foundation，也就是SAP_GWFND技術(shù)棧，框架為了遵守統(tǒng)一的 OData 錯誤響應規(guī)范，會把后端發(fā)生的許多 ABAP 異常包裝起來。對于消費服務的 SAPUI5 應用來說，這種統(tǒng)一封裝是必要的，因為客戶端不應該直接看到 ABAP Runtime Error 的內(nèi)部細節(jié)。但站在開發(fā)和排錯角度看，它又會形成一道屏障。sap-ds-debug就是 SAP Gateway 留給開發(fā)人員的一扇診斷窗口。在普通 OData 調(diào)用中，我們訪問類似下面這樣的資源路徑。/sap/opu/odata/SAP/ZSALES_ORDER_SRV/SalesOrderSet如果請求成功，SAP Gateway 通常按照AcceptHeader 或$format返回 XML 或 JSON。如果請求失敗，客戶端得到的是規(guī)范化后的 OData Error Response。在開發(fā)系統(tǒng)里，把 URI 改成下面