OData Online Apps or the Return of the Busy Indicator
Currently we are switching our SAP Mobile Platform (SMP) from Version 2.3 to 3.0. One result of developing for the new platform is that we have to redesign an Approval app built on Hybrid Webcontainer (HWC) using MBOs to a new design using Kapsel and an OData source. While MBOs and the HWC have their pro’s and con’s the data transmission worked really nice using Workflow DCN and RFC for the connection between SAP and the SMP. And you could use the app also offline due to the cached data.
Redesign for SMP 3.0 in this case means we have to rebuild the whole backend logic and application from scratch. Therefore I am digging me through example code in order to learn about the new programming paradigms.
You can easily experience this by yourself if you build a Workflow Starter Application using the SAP NetWeaver Gateway Productivity Accelerator (GWPA) based on the standard WFSERVICE. Of course this Starter App is only to see as a help to get started and no performance optimization is included there. But still the same mechanism is used in all Gateway Online apps and you cannot rely on good network coverage during daily use.
For my taste an app has to perform always well and I never want to see a Busy Indicator when I use an App. The only exception from this may be some Online transactions like bookings where I need to get a confirmation immediately.
Now what are you thinking about Gateway services and Online apps? Am I giving a theoretical example here because all apps out there are highly optimized or are using fast WiFi connections? Or maybe it does not annoy you if you see these fancy whirling Busy Indicators from time to time on your device? Or is this only a temporary problem until SMP 3.1 will offer Offline OData for Kapsel apps?
This review is really making me sad. I thought that SMP 3.0 will be the most stable platform compared to its older versions in terms of performance and development. A lot of busy indicators means poor performance that will definitely annoy the mobile app users. But I had used apps which are released by SAP using NW Gateway+SUP architecture those gave a better experience (again, I was in a wifi environment). Now my question is whether Odata really gonna increase the performance or decrease the performance ?
Btw, Are you using SMP 3.0 ramp up version? if no how can I get the software.
- Midhun VP
Midhun, thank you for your comment. Regarding the performance, if you follow these performance considerations and also build an offline OData app then I think you get a nice performing app. But for Kapsel the offline feature is not available until now.
For SMP 3, we are participating in Ramp-Up. While the whole design of the platform is much more streamlined I was somehow expecting more features included in this version. Seems like we have to wait for another year until you really gain some productivity.
Thanks for your comment Mark, Finally when we look at SUP as a platform most of the features are removed or replaced ( HWC with Kapsel, MBO with Odata) 😐 .
I have read that Kapsel has a plugin for encrypted data storage, when you say that offline is not supported by Kapsel why that plugin is for ?
Please share more information on SMP 3.0 ramp up experience.
- Midhun VP
Maybe you could build a caching mechanism on top of the encrypted storage plugin by yourself. At the moment I am a bit overwhelmed by all the new ways of working with SMP 3. Unfortunately in the Ramp-Up Knowledge Transfer all documentation regarding Migration is missing until now ('coming soon...'). Therefore I am not aware how to build an offline scenario with Kapsel efficiently.
In the native SDKs there are libraries for OData offline support available, but also here there seem to be some limitations.
Thanks for your valuable comments Mark.
btw, SMP3 related documents are available at infocenter.
I have downloaded the SMP 3.0 documentation from the following site: https://help.sap.com/mobile-platform/
Regarding the performance issues you are experience. When working on an Android app which was generated using the Gateway Productivity accellerator tools, I noticed that content-encoding / gzip compression was not being used by default. So I manually added that into the header request and then decoded the response. This made an extremely significant difference to the performance. It reduced the response by upto 40X. See a paste of some tests I ran at the time.
With GZIP Compression
Test 1 – Small response
Test 2 – Medium response
Test 3 – Large response
So as you can see, 31.88KB will download alot quicker than 1290KB even on a slow connection. And the above were based on XML responses. With SMP3.0 now offering JSON parsing the above response sizes would be around half the size if JSON was used.
Then there are also other things you can do, such as using $select to only return fields you need.
Also by implementing some sort of delta querying, if you were using offline capability, each subsequent loads after the initial load would not be as large.
I do believe that with a bit of performance optimizing the busy indicator wont be such a big problem.
Hope this helps.
thank you for this nice comparison. I will definitely implement all the performance tips. Therefore for my workflow app will hopefully hide the Busy Indicator mostly for me.
I still have to decide if I try to implement a Kapsel app and building offline functionality by myself or if I switch to native OData apps. As far as I can see now both paths will not lead me to a quick solution that I already had with the HWC.