一套典型的 SAP Fiori 应用通过浏览器发起 OData 请求，请求经过反向代理、SAP Gateway Hub，再通过系统别名和 RFC 到达后端 SAP S/4HANA。HTTP 报文没有问题，OData URI 也能正常解析，身份认证已经通过，CSRF Token 同样有效，但请求里的业务对象 Key、业务状态或者几个参数之间的组合关系却不合法。这种请求在协议层面是合法的，在业务层面却可能根本没有执行价值。SAP Gateway 的请求检查与验证机制，解决的恰恰是这个处在协议安全和业务逻辑之间的问题。SAP 官方文档把它描述为对消费端应用传入的技术上下文和业务上下文进行语义正确性检查，检查对象可以包含业务对象状态、请求参数之间的依赖关系以及其他业务语义。很多 SAP 项目把 Gateway 理解成一个单纯负责 OData 协议转换的中间层，这个理解并不完整。在经典 Central Hub 架构中，Gateway 完全可以承担一部分轻量级业务请求过滤工作，让明显无效的请求根本不进入后端业务系统。这件事看似只是少发一次 RFC，背后实际上同时牵涉性能、安全边界、数据复制、授权模型和网络分区。能被 OData Runtime 接收，并不代表业务请求成立理解 Application Request Validation，需要先把几个经常混在一起的概念拆开。浏览器发送这样的请求GET /sap/opu/odata/sap/ZSALESORDER_SRV/SalesOrderSet('471
