2020-09-09 00:38发布
点击此处---> 群内免费提供SAP练习系统（在群公告中）加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）尊敬的会员 这可能不是问这个问... 显示全部
加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）
尊敬的会员
这可能不是问这个问题的第一个，但我没有找到关于该主题的最佳实践。 因此，让我从这个角度提出问题。
我们有一个RFC，它将提供约7个表参数作为输出。 输入将从UI提供给此oData服务，并且需要提供7个表参数作为输出。 在用户界面中，所有这7个表参数都可能不会一次显示。 UI中大约有4个选项卡将列出这些数据。 我们知道
GET_EXPANDED_ENTITYSET可以与关联和导航一起使用。 我们已经建立了这个并且能够成功获得结果。 我试图从最佳实践的角度来理解什么更有意义？
1）RFC/SOAP/REST服务中的传统处理方式-在一次调用中获取输入并提供所有相关的输出，因此不会有多个客户端到服务器的调用。 从系统和用户的角度来看更好。 我的视图-这很好，因为我们不会在网关系统中加载所有导航/多个EntitySet调用。
2）使用oData和某些标准服务-设计是为了与UI匹配，因此仅在需要时才从UI对后端进行多次调用，以从相应的实体集中检索数据（kinda微服务）。 如果用户不断在选项卡或页面之间导航，这似乎在客户端和服务器之间来回很多。 我的视图-我们可以使用$ batch将所有实体集调用包装成一个，但仍然不行。 从网关到后端，将需要使用批处理中的全部工作流程（乘以Get/Insert调用的次数）。 如果同时有100个用户使用该应用程序，则我们将消耗全部 并行的工作流程和其他工作流程将必须等待/使用顺序本质流程 。
我想从您的经历中听到什么更有意义。
您何时采用上述每种策略？
使用GET_EXPANDED_ENTITYSET时的性能如何？
此致
Raj
感谢安德烈·菲舍尔
我们在使用moc的某些服务上使用并行化，还基于SPRO配置-定义批查询的并行化对$ batch请求进行并行化。
我有点安心了，因为这实际上是基于案例的，而不是真正的一种/最佳方法。 诸如前端之类的多种因素以及后端系统中存在的因素也将推动这一点。
如果我们还没有一个大的RFC，那么我们可能会去进行基于实体的服务实现，在这里我们可以让前端团队一次批调用所有实体，也可以在某个时候将它们分成多个批。 需要。
尽管感谢您的澄清！
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','http://www.easysap.com/data/attach/logo/logo.png', '推荐 zhangjiyang1323 的问题《oData-多个RFC输出表参数-最佳实践》','https://www.easysap.com/answer/65923/184479.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
感谢安德烈·菲舍尔
我们在使用moc的某些服务上使用并行化，还基于SPRO配置-定义批查询的并行化对$ batch请求进行并行化。
我有点安心了，因为这实际上是基于案例的，而不是真正的一种/最佳方法。 诸如前端之类的多种因素以及后端系统中存在的因素也将推动这一点。
如果我们还没有一个大的RFC，那么我们可能会去进行基于实体的服务实现，在这里我们可以让前端团队一次批调用所有实体，也可以在某个时候将它们分成多个批。 需要。
尽管感谢您的澄清！
一周热门 更多>