一个 SAP Fiori 页面打开销售订单对象页时，表面上只是浏览器发出几次 HTTP 请求，拿回订单抬头、行项目、业务伙伴、状态和金额。真正落到后端，这件事并不轻。数据可能来自多个 CDS View、多个业务对象甚至不同后端系统，客户端还希望只拿当前页面真正需要的字段，订单修改之后最好只同步变化部分，而不是重新把整个业务对象下载一次。这正是理解 SAP Gateway Foundation 的 OData V4 运行时设计时很合适的切入口。OData V4 并不是简单把 OData V2 的版本号从 2 改成 4。SAP 官方对这一代协议的定位很明确，V4 吸收了大量既有 SAP OData V2 应用的实践经验，对 V2 时代暴露出来的标准缺口进行了补充，同时围绕客户端与服务器端的处理开销、网络传输量以及复杂业务模型表达能力重新设计了一批机制。SAP 特别提到更轻量的 JSON、同步机制、计算与聚合处理，以及 containment、bound action 和更丰富的属性建模能力。如果只把 OData 当成一种把 ABAP 内表转换成 JSON 的技术，就很难理解这些变化。OData V4 更接近一种完整的业务对象访问协议。它不仅规定数据如何传输，还规定业务模型如何描述、实体之间如何导航、操作怎样绑定到业务对象、客户端如何增量获取变化以及服务如何组合。这也是 SAP Gateway Foundation for OData V4 Developer Guide 真正想解决的问题。从传输数据转向表达业务对象OData V2 已经能够很好地完成传统 CRUD，也就是 Create、Read、Update、Delete，并且
