在 SAP S/4HANA 项目里排查一个看似普通的 OData 问题，经常会碰到一种很令人抓狂的情况。业务人员在上午十点左右操作 SAP Fiori 应用时发现数据不对，等开发人员下午开始介入，应用已经恢复正常，/IWFND/ERROR_LOG里也没有能够直接解释问题的技术错误。前端团队拿出来的是浏览器截图，后端团队看到的是当前数据库状态，可真正决定问题性质的那一次 HTTP Request 和 HTTP Response 已经过去了。这种场景里，SAP Gateway 的 Payload Trace 很有价值。它关注的并不是 ABAP 程序到底运行了多少毫秒，而是一次 OData 调用在 SAP Gateway 中实际收到了什么，又实际返回了什么。HTTP Header、HTTP Body、Request URI、HTTP Method，以及与请求相关的 Transaction ID 都可以成为排查现场的一部分。SAP 官方文档也明确把 Payload Trace 定义为用于观察服务请求与响应数据流的诊断工具，尤其适合检查实际发送和接收的 HTTP Header 与 Body。当响应中出现异常数据，却没有形成足以进入 Error Log 的系统错误时，Payload Trace 依然可以把问题留下来。很多 SAP Gateway 开发人员已经熟悉事务码/IWFND/TRACES，但真正到了复杂项目里，决定 Payload Trace 是否能帮上忙的，往往不是会不会打开这个事务，而是两个容易被忽略的问题。一条 Trace 到底保存多久。几小时前甚至昨天产生的 Trace，当前配置已经看不到了，又该怎么把它找回来。
