Design of Data Model in Mobile projects – is caching an issue?
It is Thursday and another day of SAP TechEd and Sybase TechWave is over. I like these events, cause you learn a lot, get an overview about all the new topics in the business and it is the best area for networking and meet people face to face you usually contact by mail only.
I have given a speech about Mobile projects and how to convert your existing mobile projects to Sybase SUP without loosing the already taken investments. At the end of this a lady had a question and I would like to share this with you, cause I think it is a common problem in the market.
She asked me, how the caching of data and the given latency effects the data on the device, cause it will always be in an old state……..
Well, this is a typical problem clients run into: data model design. Everybody wants to have the latest information on the device. If I go about 6 – 10 years back, I was working inside SAP to develop SAP Mobile Infrastructure 2.5 at that time. We had a SyncBO of type 2way, that was able to connect directly to the backend at every sync to get the latest information. We used this for example to get Orders and Notifications for each user down to the device. Unfortunately this was one of the bad things in MI2.5, cause it had a big negative effect on sync times. Anyway, this was not clear to me at that time. I loved that approach, cause it gave me the feeling, the user always had the latest available information on his device after he had done a proper synchronisation.
At that time I went to CeBit in Hannover. One of the largest IT fairs in the world. I went to all the big players like Oracle, IBM, …. and had a look on their mobile solutions. None of these had a 2Way approach available – and I thought SAP is miles ahead of the competitors.
Well, a while later I was called to a client. He had a big issue on sync performance and he blamed everything from network to the mobile device for this. We did analyze the issue and found, the runtime taken to select the actual orders and notifications at each sync was the killer. It took about 6 mins each time to get this data selected – not calculated any delta calculation and data transfer. So we tuned the backend and it was much better – but still not acceptable.
That raised the first time the question in my head, if the 2way approach is really a good thing. Today we would solve this issue perhaps by installing HANA and reduce the selection time to a few seconds. But is that really the solution – would it not be better to solve this issue at the design time of the data model?
With Netwevaer Mobile 7.1 the 2Way approach was removed and so we had to think about a different solution.
Okay, so lets start to think about what is really necessary. We need to have the most actual dataset on the device. This for sure. The very good thing: while dealing with SAP we already have change listeners and we can enhance the save routines with our own developments.
To give you an example: whenever we change an order in IW32 and press save, an event is thrown inside the SAP system. We now can write some code to take the order ID and send this orderID to the NWM server where a process starts to get the latest order information from the backend server. This is an already available service we can use. At the end another process starts to find out which devices need to get this new data and puts just the relevant changes of the data into the outbox of the device. Effectively: once you press save on the order change in the backend, the delta information is available for the device just a few seconds later.
Can you see the difference? This has a dramatic impact on Sync times and on the load of the backend system.
In the past, whenever you did run a sync on the device, we had to go to the backend, ask for our order data, had to calculate on any delta changes and once done send the delta changes to the device. All this did happen at each sync, even if there had not been any order changes at all we did a complete call.
With the better approach, we only have to check our outbox and get the latest data. If there was no data change – there is not processing time and no data flow necessary.
Do we have a problem on the device with old data? Absolutely not – even better, we have much better sync performance.
Can we use this approach with SUP? Yes, off course we can – and we should use this approach for sure!
And then there is one thing I would like to clarify: there is not really a caching of data in the NWM or SUP server. They both have a consolidated data storage in place, but this should have the actual data in place and have a positive impact on sync times. If the request is to have actual data on the device, we do not need to call handlers in the backend at sync time, but use this consolidated data storage and push any change of data.
If we need to have the results on extensive calculations in BI scenarios or to calculate actual pricing information – yes, off course we have to call into the backend and to the calculation there and we have all options on using Gateway, RFC calls and HANA for better performance. But this is a totally different scenario then I have spoken about in this blog.
I hope this helps you to design your data model in a better way. At least it shows one thing for sure: if you plan a mobile project, make sure you have experienced people on board in the design phase and do not run into the issues I was running into a few years back with a lack of experience.