一个 SAP Fiori 页面调用 OData 服务时返回HTTP 500，前端只看到请求失败，浏览器 Network 面板能够确认请求确实到达了 SAP 系统。ABAP 开发人员进入/IWFND/ERROR_LOG，也确实找到了对应时间点的错误，可点进去之后却发现一个很奇怪的现象，服务名称看不到，HTTP Request Payload 看不到，HTTP Response Payload 也看不到，甚至某些 Message 里的变量值都消失了。很多人在这里会怀疑是不是 SAP Gateway 没有把日志记完整，也有人会继续去查ST22、SM21、SLG1，甚至直接在 DPC Extension Class 里加断点。实际上，这种现象很可能完全正常，因为 SAP Gateway Error Log 默认采用的并不是一个完全开放的日志模式，而是Secure。SAP 官方把 Error Log 设计成两个安全级别，Secure和Full。这里的关键词其实不是传统意义上的 Log Level，而是 Security Level。Secure并不能简单理解成类似 Java 日志框架里的INFO，Full也不能机械地类比成DEBUG。两者真正控制的是，当 Gateway Runtime 发生错误之后，哪些请求上下文可以被持久化下来，哪些业务数据允许出现在 Error Log 中，以及后续排障人员能够看到多深的请求细节
一个 SAP Fiori 页面调用 OData 服务时返回HTTP 500，前端只看到请求失败，浏览器 Network 面板能够确认请求确实到达了 SAP 系统。ABAP 开发人员进入/IWFND/ERROR_LOG，也确实找到了对应时间点的错误，可点进去之后却发现一个很奇怪的现象，服务名称看不到，HTTP Request Payload 看不到，HTTP Response Payload 也看不到，甚至某些 Message 里的变量值都消失了。很多人在这里会怀疑是不是 SAP Gateway 没有把日志记完整，也有人会继续去查ST22、SM21、SLG1，甚至直接在 DPC Extension Class 里加断点。实际上，这种现象很可能完全正常，因为 SAP Gateway Error Log 默认采用的并不是一个完全开放的日志模式，而是Secure。SAP 官方把 Error Log 设计成两个安全级别，Secure和Full。这里的关键词其实不是传统意义上的 Log Level，而是 Security Level。Secure并不能简单理解成类似 Java 日志框架里的INFO，Full也不能机械地类比成DEBUG。两者真正控制的是，当 Gateway Runtime 发生错误之后，哪些请求上下文可以被持久化下来，哪些业务数据允许出现在 Error Log 中，以及后续排障人员能够看到多深的请求细节
