一个 ODataPOST请求返回了200，SAP Fiori 页面也没有弹出技术异常，可页面上的金额、状态或者某个业务字段偏偏和预期不一致。此时去看/IWFND/ERROR_LOG，里面可能干干净净。继续盯着 ABAP 断点调试，又发现DPC_EXT或 RAP 业务逻辑返回的数据似乎没有问题。问题究竟发生在请求进入 SAP Gateway 之前，还是 Gateway 解析请求时，抑或响应序列化之后，这种场景正是Payload Trace最有价值的地方。SAP 官方对这个工具的定位非常明确。Payload Trace用来监控服务请求和响应过程中实际传输的数据，特别适合检查 HTTP Header 和 HTTP Body 的真实内容。更关键的一点在于，有些返回内容虽然不符合业务预期，却没有产生能够写入Error Log的技术错误，这类问题仅靠错误日志很容易陷入盲区。Payload Trace则能够把那次 OData 调用的报文留下来，让分析重新回到真实的 HTTP 数据上。这也是我一直把 SAP Gateway 排障分成两类的原因。出现明确异常时，我更关注/IWFND/ERROR_LOG、/IWBEP/ERROR_LOG、ST22、业务消息容器以及应用日志。请求本身能够正常走完，而结果存在字段、格式、Header、过滤条件或者序列化方面的偏差时，Payload Trace往往比单纯盯着 ABAP 调试器更快。