When trying to add my service, from my ED2(300) server, I can't see it in the Gateway IWFND/MAINT_SERVICE
It's definitely there in the backend, I've activated SEGW...
The way round this (for reasons unknown...) was to create a SEGW Project in the Gateway with the same name as the project in the backend.
You don't need to populate it with the data entries, mappings to fms etc, just needs to be a faux shell.
Once that's done, go back into the IWFND/MAINT_SERVICE transaction, and try and add the Service again.
This time round, the Service was there, and the transaction even seems to have picked up that it needs to be looking at ED2(300). My guess as to why the latter should be the case is that this was a previously used service that was deleted then re-inserted.
Thanks a lot to Manu for this one... :D
Hi guys,
Caching eh? Supposed to make things a lot faster, prevent unnecessary trips to the server to get data the browser thinks it's got already.
Except it doesn't...
Here was our scenario : We had a UI5 application that dragged data from SAP into the browser. The user could change this, and save the changes back to SAP. So far so good...
except
when the user went out of the document, then back in again, they got the OLD version of the data. This took a bit of analysis to get to the bottom of.
Of course the first thing I tried was to put a breakpoint in the backend function, to see if that was even getting hit. It wasn't.
The next thing I tried was switching on debug mode (F12 in the browser - IE in my case) and using "Network"->"Monitor" to see what requests were going to the backend. Now, since my browser console is set to "Always refresh data from server" this then called SAP, and my breakpoint was hit...
The inconsistency here is really frustrating, as you can be debugging and see one set of results, tell your user that the problem is fixed, then have them see a different set of results.
So the issue here is that the oData results had been cached.
There were 2 ways round this... one "hackier" than the other...
1 : Spoof a filter option, that the backend then ignores...
This was a colleagues idea, and I liked it as it solved the problem without significant additional investigation. We included a dummy timestamped filter, which made the URL unique, and so the browser HAD to go to the backend because it couldn't find a cached result for that URL.
2: Switch off Caching :
https://blogs.sap.com/2014/05/28/disabling-cache-for-crudfi-odata-scenarios-for-a-ui5-application-using-ie/
Really liked this guys style!
