在 SAP Gateway 项目里，$expand很容易给人一种错觉，只要在 OData URL 后面加上$expand=SalesOrderItems，Gateway 就会自动把销售订单和行项目一次性查出来，似乎整个过程与数据库里的JOIN差不多。真正进入/IWBEP/IF_MGW_APPL_SRV_RUNTIME这一层之后，情况要复杂得多。同样一条 OData 请求，SAP Gateway 可以采用完全不同的执行路径。一条路径由 Gateway Framework 自动完成，传统文档里叫generic expand，现在通常称为 Framework Expand。另一条路径则由 Data Provider Class，也就是 DPC 自己承担，过去常被称为basic expand，现在通常叫 Data Provider Expand。这两个名字看起来只是实现方式不同，但在真实的 SAP S/4HANA 项目中，它们直接关系到 DPC 方法调用次数、后端 Business API 调用次数、数据库访问模式、ABAP Application Server CPU 消耗，以及一个包含几百条 Header 的 OData 请求究竟会执行几十次还是几百次业务读取。SAP 官方文档给出的定义非常明确，SAP Gateway 默认提供 generic$expand实现，不需要应用开发人员额外实现代码。当读取SalesOrders并展开关联的SalesOrderIte
SAP Gateway $expand 深入解析，从 Framework Expand 到 Data Provider Expand 的执行链路与性能取舍
在 SAP Gateway 项目里，$expand很容易给人一种错觉，只要在 OData URL 后面加上$expand=SalesOrderItems，Gateway 就会自动把销售订单和行项目一次性查出来，似乎整个过程与数据库里的JOIN差不多。真正进入/IWBEP/IF_MGW_APPL_SRV_RUNTIME这一层之后，情况要复杂得多。同样一条 OData 请求，SAP Gateway 可以采用完全不同的执行路径。一条路径由 Gateway Framework 自动完成，传统文档里叫generic expand，现在通常称为 Framework Expand。另一条路径则由 Data Provider Class，也就是 DPC 自己承担，过去常被称为basic expand，现在通常叫 Data Provider Expand。这两个名字看起来只是实现方式不同，但在真实的 SAP S/4HANA 项目中，它们直接关系到 DPC 方法调用次数、后端 Business API 调用次数、数据库访问模式、ABAP Application Server CPU 消耗，以及一个包含几百条 Header 的 OData 请求究竟会执行几十次还是几百次业务读取。SAP 官方文档给出的定义非常明确，SAP Gateway 默认提供 generic$expand实现，不需要应用开发人员额外实现代码。当读取SalesOrders并展开关联的SalesOrderIte
