在 SAP Gateway 项目里，$expand往往是一个刚开始看起来很简单，等到数据量上来之后才发现里面藏着不少门道的功能。一个典型场景来自销售订单。前端需要读取一个 Sales Order，同时把对应的 Sales Order Item 一并返回。按照 OData 的设计，不需要先请求订单，再拿订单号逐笔请求 Item，而是可以直接使用$expand，让关联实体以内联方式出现在一次 HTTP Response 里。SAP 官方文档给出的例子就是读取销售订单0500000000及其行项目。SalesOrders('0500000000')?$expand=SalesOrderItems如果读取的是整个 Sales Order EntitySet，同样可以写成下面这种形式。SalesOrders?$expand=SalesOrderItems从协议层观察，这只是 URL 后面多了一个$expand。但进入 SAP Gateway Runtime 以后，事情就没有这么简单了。Gateway 需要分析导航属性，构造 Expand Tree，判断应用程序是否准备自行读取关联数据，还要判断哪些路径已经处理、哪些路径仍然交给 Framework 展开。/IWBEP/IF_MGW_ODATA_EXPAND就位于这条处理链的核心位置。 从 $expand 树到应用侧深度读取，深入理解 /IWBEP/IF_MGW_ODATA_EXPAND 与 COMPARE_TO
在 SAP Gateway 项目里，$expand往往是一个刚开始看起来很简单，等到数据量上来之后才发现里面藏着不少门道的功能。一个典型场景来自销售订单。前端需要读取一个 Sales Order，同时把对应的 Sales Order Item 一并返回。按照 OData 的设计，不需要先请求订单，再拿订单号逐笔请求 Item，而是可以直接使用$expand，让关联实体以内联方式出现在一次 HTTP Response 里。SAP 官方文档给出的例子就是读取销售订单0500000000及其行项目。SalesOrders('0500000000')?$expand=SalesOrderItems如果读取的是整个 Sales Order EntitySet，同样可以写成下面这种形式。SalesOrders?$expand=SalesOrderItems从协议层观察，这只是 URL 后面多了一个$expand。但进入 SAP Gateway Runtime 以后，事情就没有这么简单了。Gateway 需要分析导航属性，构造 Expand Tree，判断应用程序是否准备自行读取关联数据，还要判断哪些路径已经处理、哪些路径仍然交给 Framework 展开。/IWBEP/IF_MGW_ODATA_EXPAND就位于这条处理链的核心位置。