如果使用$ expand不会 并行GET请求，但是无论您是否已实现GET_EXPANDED_ENTITYSET还是让SAP Gateway框架以递归方式调用GET_ENTITY和GET_ENTITYSET方法的工作，都只有一个。

实现GET_EXPANDED_ENTITYSET是否带来任何性能依赖于 基础业务逻辑。 如果您在第一次调用时仍要读取全部数据（例如，如果使用一个BAPI一次调用标头和项目数据）会更好，但是实现起来比较麻烦。

您 可能要研究构建CDS视图并使用参考数据源方法。

致谢

Andre

感谢安德烈·菲舍尔

我们将这些oData构建在系统中已存在多年的包装RFC之上，该包装将不同级别的数据整合在一起。 我们确实选择了

GET_EXPANDED_ENTITYSET（数据提供程序扩展）基于最佳实践，以避免递归地使用标准网关框架的$ expand。

我的问题更多关于Entityset输出。 我们几乎有大约7个表格参数需要在屏幕上的不同选项卡中显示。 数据提供者以传统的方式将所有数据提供给前端，然后前端团队确定何时何地显示，以避免多次调用后端系统。 使用oData，我们可以选择分别调用这些实体，因此想知道何时最好调用单个实体Vs将所有实体作为输出返回？

我已经看到My Fiori收件箱使用$ batch合并了对不同实体（例如项目，附件，相关对象等）的所有get请求调用的种类。使用$ batch在集线器部署中，所有这些对backenntity调用的es都将进行 被GW调用，因为处理的单个工作占用网关上的更多资源。 现在，在这种情况下，不是使用1个工作流程，而是使用4个或5个以不同的方式获取相同的数据。

希望我在上述声明中明确表示自己。 很乐意讨论这些问题，以了解SAP使用1个工作流程（GET_EXPANDED_ENTITYSET）与多个工作流程用法（$ batch）背后的策略。

感谢安德烈·菲舍尔

我们在使用moc的某些服务上使用并行化，还基于SPRO配置-定义批查询的并行化对$ batch请求进行并行化。

我有点安心了，因为这实际上是基于案例的，而不是真正的一种/最佳方法。 诸如前端之类的多种因素以及后端系统中存在的因素也将推动这一点。

如果我们还没有一个大的RFC，那么我们可能会去进行基于实体的服务实现，在这里我们可以让前端团队一次批调用所有实体，也可以在某个时候将它们分成多个批。 需要。

尽管感谢您的澄清！