问题
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.
Although there are some suggestions or workarounds like clicking “Load Metadata” to force a cache synchronization with backend, and once we see the successful load popup,
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
分析
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…
Ghost appears again. The cache in AG3/001 is still latest:
However the cache in GM6/001 returns to old version again:
However, my ASSERTION does not take effect – there is no ASSERT failure runtime error in ST22 in AG3/001.
I 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:
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.
But in the working case, the entry for our new enhanced node are there in the table, see example below:
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:
The question is, where does another version 20150205092736 come from? ( it does not have our latest enhancement ).
It comes from QHD/504. Since QHD/504 still has the older version of OData model, every time an OData request is sent from GM6 to QHD/504, the cache of lower version in QHD/504 will be fetched and filled in GM6/001, which causes the trouble.
In the past it is configured that GM6 could connects both to AG3 ( latest version ) and QHD ( lower version ). After we remove the System alias for QHD/504, this issue is resolved.
更多Jerry的原创文章，尽在："汪子熙":