点击此处---> 群内免费提供SAP练习系统(在群公告中)
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
伙计们,
背景
我目前正在通过oData通过任务网关为Fiori My Inbox 2.0设计自定义任务提供程序。 到目前为止,我已经总结了数据检索所需的业务逻辑,这必须通过RFC完成,因为数据位于另一个系统上,即我正在将Facade-Class作为网关上的数据提供程序实现,但是 应该管理的数据驻留在我们的ERP系统中。
幸运的是,到目前为止,我对初始数据检索所需的所有逻辑都是由ERP系统上的4个标准功能模块提供的。
问题/讨论
目前,我正在尝试找出什么是"最佳"方法,或者是什么是方法的最佳折衷方案。 到目前为止,我有两个想法,想提出来进行讨论:
A)我将4个远程功能模块合并到我的Facade类的各个方法中,这意味着它们将在嵌套调用堆栈中单独调用。 在Facade类内部或在两个SAP系统(网关和ERP)之间,都不会有编码冗余,但是会有4到X个(假设X =在最坏的情况下最多为数百个)单个RFC。 >
B)我在ERP系统内构建了一个包装器类,在本地进行所有数据检索,理论上可以将检索到的数据减少为网关上所需的实际零件 并且从网关到ERP系统之间仅建立一个RFC,从技术上"逻辑"地检索全部信息一次,但是,它可能在Task Gateway框架/模型中发生多次,即,可能会 信息不会被调用一次,而是几次,这在功能上是毫无意义的,但是框架可能会多次调用某些方法,因此我可能无法始终如一地保存所有信息(我现在还不知道;可能是 实际上只有一个RFC,仅此而已)。 这意味着我将在网关和ERP系统上同时拥有部分冗余的业务逻辑,并可能通过RFC整体带来更大的数据负载(至少在内容方面)。
目前,我为哪种方式感到困扰。 我个人不赞成使用方法B)进行编码冗余,但是这样做并不坏,以至于使事情变得混乱或难以维护。 这更多是一个原则问题。 另一方面,方法A)的性能可能会降低一点,但很可能不会引起人的注意,假设最终用户会不时清理其工作空间,
我也愿意采用完全不同的方法,前提是经过数小时的调试和/或例行盲目检查,我已经麻木了。
欢呼,卢卡斯
(11.0 kB)
清理旧线程。/closed
我同意:不是对是错,只是不同的方法。 :)
+1(方法B)
我以前没有在这种特定情况下工作过,但是在过去,我们曾有几次项目开始从中间件平台协调到后端的多个RFC调用,然后出于性能原因不得不转向包装器功能。 我们从来没有遇到过相反的情况。
毕竟,这个网络充满希望<3
嗨,卢卡斯,
我没有得到这个问题,所以我想问您几件事以清除我的想法:希望您不介意!
这4个FM需要检索整个信息集,还是它们引用4个不同的实体(即通过Deep Entity)?
我发现,如果以不同的方式检索您的信息集却又将它们链接在一起并进行分组,那么使用Deep实体可能会很有用。
嗯,好吧……我已经一年了 我正在与oData和GW一起玩,但是我正在NW731上工作,并且我的GW和ERP一起工作,没有任何第三方的介入,所以我可能是您最后一个需要听听您的问题的人了:)
我在这个主题上的2美分:如果将4个FM一起调用(看起来好像),最好创建一个包装器。
在这种情况下,您从GW到ERP仅打了1个电话,却得到1个响应,而不是保持两个系统之间的对话。
根据我的理解,阅读您的其他问题及其链接后,GW只是一种接收请求(来自Fiori层)并将其传递给相应后端的代理。
让后端(也称为ERP系统)完成其工作:处理数据,仔细阅读数据,然后将结果吐出来。
因此,如果我必须选择一种方法,我会选择选项B。
但是,再次可能是我错了:)
如果可能的话,我想在移动端寻求一种缓存数据方法,以减少 网络负载并增加响应时间。 但是,我同意Simone-方法B
一周热门 更多>