这篇文章主要介绍“SAP CRM Fiori应用冗余round trip的原因是什么”，在日常操作中，相信很多人在SAP CRM Fiori应用冗余round trip的原因是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”SAP CRM Fiori应用冗余round trip的原因是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
有同事抱怨每次他们保存一个appointment时，除了正常的batch 操作外，还有3个莫名的read 操作。
The callstack clearly shows that the three roundtrips are NOT issued by customer extension, or else the customer js file could be observed in the callstack.
Set a breakpoint on the top most callstack, h function. Check the content of e.target.data:
This is actually the batch request payload which could be observed in Chrome network tab:
This finding gives me more confidence that these roundtrips are issued by framework, not standard or customer application code.
So I just continue debugging until I reach this suspicious stack:
in line 1957, this.bRefreshAfterChange = true.
However, in our internal system ( where everything works fine, there is no duplicate read operations ), this.bRefreshAfterChange = false, which has suppressed the refresh operation. This is the reason why the read operation could not be found in my internal system, since they are not executed at all. But in customer system, _isRefreshNeeded returns true, which leads to the execution of all subsequent read operations.
So why is this difference between two systems? In Chrome development tool, search the boolean variable name and we found one function setRefreshAfterChange defined for ODataModel. Just set a breakpoint in this method and re-launch the application in my internal system from beginning:
Breakpoint is triggered:
However, this line in customer system is missing, which is the root cause - our latest standard code didn't reach customer system.
出问题的系统上的标准代码里少了这一行，我在local的Eclipse里试过，如果注释掉，behavior就和出问题的系统上一样，能够重现那三个多余的读操作了。
到此，关于“SAP CRM Fiori应用冗余round trip的原因是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联-成都网站建设公司网站，小编会继续努力为大家带来更多实用的文章！