SAP 官方在解释 Gateway 的$expand机制时，给过一个非常典型的请求。SalesOrders('0500000000')?$expand=SalesOrderItems客户端只发出一次 HTTP 请求，希望一次拿到销售订单0500000000，同时把它下面关联的销售订单行项目一起带回来。SAP Gateway 自己完全有能力处理这样的$expand。按照 SAP 官方对 Framework Expand 的说明，框架可以先读取 Sales Order，再根据导航关系读取对应的 SalesOrderItems。当查询对象从单个订单扩大成订单集合时，Gateway 的通用实现会读取订单集合，并针对返回的订单逐条处理关联实体。问题也恰恰出现在这里。如果一次读取 200 张销售订单，而框架针对每一个 Sales Order 都再次调用关联 SalesOrderItems 的GET_ENTITYSET，从 Data Provider 的调用形态看，很容易形成经典的1 + N模式。这里不能简单等同于一定执行了201条 SQL，因为具体数据库访问次数取决于每个GET_ENTITYSET内部的实现，但 Provider Runtime 的调用次数会明显增加。数据规模上去以后，网络往返、ABAP 方法调用、授权检查、数据转换、数据库查询都会叠加。这正是/IWBEP/IF_MGW_ODATA_EXPAND存在的重要原因。 读懂 SAP Gateway 的 Expand Tree，/IWBEP/IF_MGW_ODATA_EXPAND 与 GET_CHILDREN 深度解析
SAP 官方在解释 Gateway 的$expand机制时，给过一个非常典型的请求。SalesOrders('0500000000')?$expand=SalesOrderItems客户端只发出一次 HTTP 请求，希望一次拿到销售订单0500000000，同时把它下面关联的销售订单行项目一起带回来。SAP Gateway 自己完全有能力处理这样的$expand。按照 SAP 官方对 Framework Expand 的说明，框架可以先读取 Sales Order，再根据导航关系读取对应的 SalesOrderItems。当查询对象从单个订单扩大成订单集合时，Gateway 的通用实现会读取订单集合，并针对返回的订单逐条处理关联实体。问题也恰恰出现在这里。如果一次读取 200 张销售订单，而框架针对每一个 Sales Order 都再次调用关联 SalesOrderItems 的GET_ENTITYSET，从 Data Provider 的调用形态看，很容易形成经典的1 + N模式。这里不能简单等同于一定执行了201条 SQL，因为具体数据库访问次数取决于每个GET_ENTITYSET内部的实现，但 Provider Runtime 的调用次数会明显增加。数据规模上去以后，网络往返、ABAP 方法调用、授权检查、数据转换、数据库查询都会叠加。这正是/IWBEP/IF_MGW_ODATA_EXPAND存在的重要原因。