关于 SAP ABAP gateway OData 的一个诡异问题及解决办法-阿里云开发者社区

开发者社区> 开发者小助手-bz4> 正文

关于 SAP ABAP gateway OData 的一个诡异问题及解决办法

简介: 关于 SAP ABAP gateway OData 的一个诡异问题及解决办法
+关注继续查看

问题

You can see that the old version of cache re-appears in the table in gateway system.


Our SEGW project name: CRM_OPPORTUNITY.

Gateway system: GM6/001

Backend system: AG3/001


I am doing some new enhancement on CL_CRM_OPPORTUNITY_MPC_EXT~ DEFINE to add some new nodes. ( The enhancement is done by directly changing the source code of ABAP class CL_CRM_OPPORTUNITY_MPC_EXT without any re-activation in SEGW.


P.S: As an experienced developer, I felt really shameful to tell my Product owner something like “I don’t know why this issue occurs, and I guess it is not caused by our enhancement”. I am eager to know the root cause of this issue. I did made some pre-analysis and the entry point for cache table filling is done via method /IWFND/CL_MED_MDL_PROVIDER~ GET_META_MODEL, so I would like to know what types of operations and which user has triggered the method call. I am evening considering to ask our IT colleagues to switch on the table log on this cache table so that at least I would know the SAP name of the user who has filled this old version cache.


image.png

The cache in GM6 will become latest version. However, I don’t think this is acceptable since it would be a disaster for a customer to do this stupid activity again and again.

I believe in that every issue has its root cause, and now I have trouble to find it L

image.png

分析

The Metadatacache is refreshed with Call $metadata or if the user press ‚load metadata‘ in /IWFND/MAINT_SERVICE.


The cache is not refreshed by any automatism.


With NW 7.40 SP10 there is a Metadata Invalidation for Business Data Requests, this means that with Get Requests – Call the Framework is checking the Metadata and if there is newer data the Cache will be deleted.


If the Cache is deleted it will be automatically loaded with a Business Data Request.


The metadata Cache can be controlled with overwriting Method /IWBEP/IF_MGW_MED_LOAD~GET_LAST_MODIFIED in the DPC Class and this can also lead to errors.

This method is called to determine the last version. Can you please check that this method is not overwritten.


Yes we have to redefine GET_LAST_MODIFIED in our CL_CRM_OPPORTUNITY_MPC_EXT since the metadata of BP Model is reused so we just return compare the last-modify timestamp of BP and Opportunity model and return the latest one. The logic is as below, very simple and I don’t think the code will cause trouble.


Since today I have to make some changes on the model for development, I add a “trap” in line 15.

Since in principle all cache entries in GM6 must come from backend system AG3/001, so suppose the cache in GM6 returned to an older version, that older version must also come from AG3. In that case the line in 15 will cause a dump in AG3/001.


Let’s wait and see if any prey will fall into this trap…


image.png

image.png

 am extremely confused why this very version 20150108130735 is returned but not the others.


I am writing to you regarding another very strange issue.


If you log on GM6/001, tcode /IWFND/ERROR_LOG, and you can find there are many errors for user LIROS as displayed below:

image.png

The annoying thing is, sometimes this issue will occur but some other times everything just works perfectly.


I debugged and find some hint that, every time the issue occurs, it is because there is no corresponding entry existed in internal table ms_model_class-associations.

Take the below screenshot for example. In the wrong situation, no corresponding entry for OpportunitycomplexNotesSet in the internal table.

image.png

It looks like it is quite unstable. Do you have any suggestions?


Finally we have found the root cause. I have written a report ZJERRY_CACHE_TEST in GM6/001 and schedule it as background job to track the change of that buffer table

with interval like 10 seconds.


It has shown that in GM6/001 there are TWO types of caches for Opportunity model. The red one which has our latest enhancement is the correct one, has timestamp

20150205074407 which exactly matches to AG3/001:


image.png

image.png


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
2315
文章
0
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载