在传统的 SAP Gateway 项目里，有一种性能问题很容易被低估。一个页面只想显示 50 张销售订单，同时把订单行项目和业务伙伴一起带回来。前端发出的 OData 请求看上去很自然，类似下面这样。SalesOrderSet?$top=50$expand=ToLineItems,ToBusinessPartner从 HTTP 请求的角度看，这只是一个$expand。但进入 SAP Gateway 运行时以后，事情并不一定只有一次数据库读取。SAP 官方文档明确说明，Gateway Framework 默认提供通用的$expand实现。框架读取父实体集后，可能针对每一个父实体继续调用相关实体的GET_ENTITYSET。以 Sales Order 和 Sales Order Item 为例，父订单读出来以后，框架可能在循环中逐张订单读取它们的行项目。这里很容易出现经典的 N 加 1 类访问模式。公开的GWSAMPLE_BASIC性能分析里就记录过一个相当直观的数据。读取 50 个 Sales Order，同时展开 Business Partner 和 Sales Order Item 时，标准的通用 Expand 处理最终产生了 101 次数据库访问。后来通过重新实现/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITYSET，把相关数据按集合一次性读取，数据库访问数量从 101 次压缩到了 3 次。这个案例很好地解释了为什么 SAP Gateway 会提供 从 $expand 字符串到 Expand Tree，深入理解 /IWBEP/IF_MGW_ODATA_EXPAND
在传统的 SAP Gateway 项目里，有一种性能问题很容易被低估。一个页面只想显示 50 张销售订单，同时把订单行项目和业务伙伴一起带回来。前端发出的 OData 请求看上去很自然，类似下面这样。SalesOrderSet?$top=50$expand=ToLineItems,ToBusinessPartner从 HTTP 请求的角度看，这只是一个$expand。但进入 SAP Gateway 运行时以后，事情并不一定只有一次数据库读取。SAP 官方文档明确说明，Gateway Framework 默认提供通用的$expand实现。框架读取父实体集后，可能针对每一个父实体继续调用相关实体的GET_ENTITYSET。以 Sales Order 和 Sales Order Item 为例，父订单读出来以后，框架可能在循环中逐张订单读取它们的行项目。这里很容易出现经典的 N 加 1 类访问模式。公开的GWSAMPLE_BASIC性能分析里就记录过一个相当直观的数据。读取 50 个 Sales Order，同时展开 Business Partner 和 Sales Order Item 时，标准的通用 Expand 处理最终产生了 101 次数据库访问。后来通过重新实现/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITYSET，把相关数据按集合一次性读取，数据库访问数量从 101 次压缩到了 3 次。这个案例很好地解释了为什么 SAP Gateway 会提供