在 SAP Fiori 或其他 OData Consumer 调用 SAP S/4HANA 后端时，有一种请求非常常见。页面需要显示一张 Sales Order 的抬头信息，同时还要展示这张订单下面的全部 Sales Order Item。如果按照普通 REST 请求思路处理，很容易变成两次甚至更多次 HTTP 请求，一次读取订单抬头，另一次根据订单号读取 Item。SAP Gateway 提供的$expand正是为这种场景准备的。它允许一个 OData 请求在读取主 Entity 的同时，把与其存在 Association 的关联 Entity 一起带回来。SAP 官方对这个能力的描述非常直接，$expand可以让应用以深层结构读取并返回 Entity，也就是把原本分散在多个 Entity 或 EntitySet 中的数据按照 Navigation Property 组织成一个嵌套结果。最典型的请求就是下面这个。https://server:port/.../service_name/SalesOrders('0500000000')?$expand=SalesOrderItems这里读取的是订单0500000000，与此同时沿着SalesOrderItems这个 Navigation Property，把关联的订单行项目一起返回。如果目标不是一张订单，而是一批 Sales Order，也可以保持完全相同的思 SAP Gateway 深度读取的两条路径，Framework Expand 与 Data Provider Expand 的运行机制与性能取舍
在 SAP Fiori 或其他 OData Consumer 调用 SAP S/4HANA 后端时，有一种请求非常常见。页面需要显示一张 Sales Order 的抬头信息，同时还要展示这张订单下面的全部 Sales Order Item。如果按照普通 REST 请求思路处理，很容易变成两次甚至更多次 HTTP 请求，一次读取订单抬头，另一次根据订单号读取 Item。SAP Gateway 提供的$expand正是为这种场景准备的。它允许一个 OData 请求在读取主 Entity 的同时，把与其存在 Association 的关联 Entity 一起带回来。SAP 官方对这个能力的描述非常直接，$expand可以让应用以深层结构读取并返回 Entity，也就是把原本分散在多个 Entity 或 EntitySet 中的数据按照 Navigation Property 组织成一个嵌套结果。最典型的请求就是下面这个。https://server:port/.../service_name/SalesOrders('0500000000')?$expand=SalesOrderItems这里读取的是订单0500000000，与此同时沿着SalesOrderItems这个 Navigation Property，把关联的订单行项目一起返回。如果目标不是一张订单，而是一批 Sales Order，也可以保持完全相同的思