在排查 SAP Gateway 的 OData 请求时，经常会碰到这样一种情况，HTTP 请求确实已经进入 SAP 系统，/IWFND/ERROR_LOG里却只能看到错误发生之后留下来的结果，真正想知道的往往是请求什么时候进入 Gateway、经过了什么处理阶段、调用了哪个后端系统、某个业务步骤从哪里开始、又是在什么位置失败。这类问题仅靠断点并不好解决。生产系统不能随意调试，偶发问题又很难复现，一个请求可能还横跨 Gateway Hub、RFC、S/4HANA Backend 等多个技术层。SAP Gateway Foundation 为此提供了一套专门的日志 API，其中非常重要的入口就是/IWFND/CL_LOGGER。SAP 官方把/IWFND/CL_LOGGER定义为 Gateway logging API 的核心类，它提供多种面向不同场景的日志方法。类本身采用 singleton 风格管理当前请求所对应的 logger，INIT_LOGGER是静态方法，用于初始化 singleton logger，而GET_LOGGER也是静态方法，用来重新取得当前 logger 实例。真正记录步骤、业务消息以及完成状态的操作，则主要由实例方法完成。理解这套机制时，我更愿意把一个 SAP Gateway 请求看成一条完整的处理链。外部 Consumer 发出 HTTP 请求，请求进入 SAP Gateway Connectivity Layer，Gateway 建立当前请求对应的日志上下文，随后进入技术处理，再进入业务处理，期间可能访问 Backend Syst