尧图网站建设 
一个 SAP Fiori 页面打开时发出十几个 OData 请求，这种场景在项目里非常常见。页面头部读取销售订单基本信息，Items 表格读取行项目，旁边还有 Partner、Pricing、Schedule Line、Text、Attachment 等数据。浏览器的 Network 面板里一排GET请求，看起来每一个都很轻，但页面整体响应却并不快。很多开发人员看到这种情况，很自然会想到$batch。既然十几个请求都要发到 SAP Gateway，把它们塞进一个$batch，一次 HTTP 请求全部送过去，网络连接不是少很多了吗。这个思路没有问题，但只理解到这里还不够。SAP Gateway 官方的性能指南确实建议，对于彼此没有 Association 关系的多个请求，可以考虑通过$batch合并 HTTP 请求。特别是在调用数量超过两个以后，$batch可以减少客户端与 SAP Gateway 之间反复进行的网络往返。不过，同一份 SAP 文档也专门提醒，批处理需要同时考虑 Payload 大小，而且 Read 请求以及包含多个 Atomic Unit of Work 的 Update 请求，在某些执行路径上可能仍然按顺序访问 SAP Business Suite，因此批处理甚至可能让总响应时间变长。所以我们真正需要建立的认知不是「用了$batch就快」，而是理解一条完整的 OData 请求到底消耗了哪些时间。假设一个 SAPUI5 应用需要调用 8 个互不关联的 EntitySet。/ SAP Gateway OData 性能优化实践，为什么 $batch 不是请求越多越划算
一个 SAP Fiori 页面打开时发出十几个 OData 请求，这种场景在项目里非常常见。页面头部读取销售订单基本信息，Items 表格读取行项目，旁边还有 Partner、Pricing、Schedule Line、Text、Attachment 等数据。浏览器的 Network 面板里一排GET请求，看起来每一个都很轻，但页面整体响应却并不快。很多开发人员看到这种情况，很自然会想到$batch。既然十几个请求都要发到 SAP Gateway，把它们塞进一个$batch，一次 HTTP 请求全部送过去，网络连接不是少很多了吗。这个思路没有问题，但只理解到这里还不够。SAP Gateway 官方的性能指南确实建议，对于彼此没有 Association 关系的多个请求，可以考虑通过$batch合并 HTTP 请求。特别是在调用数量超过两个以后，$batch可以减少客户端与 SAP Gateway 之间反复进行的网络往返。不过，同一份 SAP 文档也专门提醒，批处理需要同时考虑 Payload 大小，而且 Read 请求以及包含多个 Atomic Unit of Work 的 Update 请求，在某些执行路径上可能仍然按顺序访问 SAP Business Suite，因此批处理甚至可能让总响应时间变长。所以我们真正需要建立的认知不是「用了$batch就快」，而是理解一条完整的 OData 请求到底消耗了哪些时间。假设一个 SAPUI5 应用需要调用 8 个互不关联的 EntitySet。/