一个 SAP Fiori 页面打开需要 8 秒，浏览器 Network 面板显示某个 OData 请求迟迟不返回。前端开发看到的是 HTTP 请求慢，ABAP 开发怀疑 CDS View 或数据库查询，Basis 团队又可能认为问题出在 Gateway Hub、RFC 或网络。几方都能找到一些证据，却很难回答一个真正有价值的问题，这 8 秒究竟消耗在哪里。这正是 SAP Gateway Performance Trace 最适合介入的地方。SAP Gateway 的 Performance Trace 并不是类似 ST05 那样只观察 SQL，也不是 SAT 那样围绕 ABAP Runtime 做代码级分析。它站在 OData Service Call 的视角观察一次请求，把消费者发出的 HTTP 调用沿着 SAP Gateway Hub、RFC 通信、Backend Gateway Framework，一直追踪到真正执行业务逻辑的 Data Provider。SAP 官方把它定位为 Service Call Level 的性能监控工具，开发人员、系统管理员、Support Consultant 乃至最终用户都可以利用它调查 OData 请求的性能问题。对于 Hub System，可以使用事务码/IWFND/TRACES，对于 Backend System，则可以使用/IWBEP/TRACES。这两个事务码背后的分工很值得理解。传统 SAP Gateway 部署经常存在 Hub Deployment，HTTP 请求先进入 Frontend Server 或 Gateway Hub，再通过 RFC 到达 Business Suite 或 S/4HANA Back