企业里的 OData 服务一旦开始承载员工薪资、银行账户、客户联系方式、医疗信息或者其他受监管的数据，一个很现实的问题很快就会出现。业务用户通过 SAP Fiori 打开了一条员工记录，某个外部系统通过 OData API 查询了一批客户，一个管理员使用$filter精确检索某个特定人员的数据，这些操作在功能层面可能完全合法，但从数据保护和审计角度看，仅仅知道接口调用成功还远远不够。我们往往还需要回答更细的问题，究竟是谁读取了敏感数据，读取的是哪一类数据，通过什么请求读取，发生在什么时间，查询时又带了哪些条件。SAP 为这类场景提供的标准能力就是 Read Access Logging，通常简称 RAL。从 SAP 当前的官方文档来看，RAL 的定位并不是普通意义上的技术 Trace，也不是单纯记录 HTTP 请求的 Access Log。它面向的是敏感数据读取行为，目标是帮助系统回答谁在什么时间以什么方式访问了敏感信息。敏感信息究竟包括哪些内容，并不存在一个对所有企业都完全相同的答案，它既可能由所在国家或地区的数据保护法规决定，也可能来自公司的内部安全政策和外部合规要求。在 SAP Gateway Foundation 里，OData 被 RAL 当成一种 Channel，也就是数据离开系统的一种通道。SAP 当前的 Channel 文档同时列出了 OData V2 和 OData V4，并明确说明两者都支持 Input Logging 与 Output Logging。对于 OData V4，部分可配置的 Channel Fields 与 V2 已经不同，因此在维护 V4 服务的 RAL 配置时，不适合直接照搬很多早期针对 OData V2 编写的操作资料。