很多 SAP OData 性能问题，追到比较深的位置时，会发现问题未必出在 OData 协议本身，也未必出在 SAPUI5、Fiori Elements 或 HTTP 层，而是出在一个更早的架构决定上，我们到底把业务服务的处理逻辑放在哪里。
假设一个销售订单查询服务需要读取订单抬头、行项目、计划行、业务伙伴以及状态信息，同时还要处理 $filter、$orderby、$skip、$top 等查询条件。表面上看，这只是一个普通的 OData 请求，但系统真正需要回答的问题其实是，几十万甚至几百万条业务数据应该在哪里过滤，在哪里排序，在哪里完成分页，又应该在哪个系统里组装最终结果。
如果把大量原始数据先搬离业务系统，再交给外围 Gateway 系统加工，网络传输、RFC 往返次数、ABAP 内存消耗都会参与进来。反过来，如果服务实现代码本来就位于保存 SAP Business Suite 数据的后端系统，OData 请求携带的查询语义便可以尽可能早地进入业务处理层，甚至继续向数据库层下推。
这正是 SAP Gateway 在设计 Development in SAP Business Suite Backend System 这种开发模式时最重要的思路。
SAP 官方文档给出的判断很直接。当一个 OData 服务需要具有较高灵活性，并且需要同时支持多种业务场景时，把应用代码部署在 SAP Business Suite 数据所在的系统中通常更有优势。SAP Gateway 并不只是充当一个把 ABAP 数据包装成 JSON 或 XML 的 HTTP 转换器，它的 OData Channel 会把查询语义带入后
