Keep Mobile Simple
Introduction
When talking about Mobile apps with Offline capabilities and the capacity to run on different kind of devices, most customers automatically think these apps will cost a lot of money. Depending on the Use case this is not always true. Recently I received the question of one of my customer to renew a mobile App written in VB.NET using SOAP Services to access data from SAP. With SAP Gateway and Fiori, the customer wanted to make this mobile app completely with SAP Technology! The new app should also support multiple Devices with different OS types. (The old one only runs on Windows Phone 6.5). The two big challenges of this question are:
- Support multiple devices
- Offline capability
Support multiple devices
For supporting multiple devices, we’ve chosen to create a Hybrid Mobile app. With a Hybrid app you have only one Codebase to support multiple target devices. We followed SAP and used the SAPWebIDE which enables us to create Mobile Fiori apps based on Cordova. With Cordova we could transform a Web app (like Fiori) into a Mobile app. The SAPWebIDE has the ability to generate such a Cordova project from your Fiori project. You only have to install the Hybrid App Toolkit on your computer.
The Hybrid App Toolkit made it astonishing easy to support multiple devices. In the SAPWebIDE I could configure my Cordova project and select the target devices. When everything was configured, I could deploy my Fiori app to my local computer. On my local computer I could just run the generated Cordova project.
There is also the Fiori Mobile Service in the SAP Cloud Platform. With this Cloud service you even don’t need to install anything.
https://help.sap.com/viewer/57a7f2d613644550aeb3e5670b39f096/Cloud/en-US
This part was mainly covered thanks to the SAPWebIDE and the Hybrid App Toolkit. The only difficult part was the installation of the Hybrid App Toolkit. But there are some great blogs that explain everything step by step.
Offline capabilities
Offline capabilities in the app were another discussion. When we talk about offline we often think we need a middle layer and as SAP developers we think of the SAP Cloud Platform Mobile Services or SAP Mobile Platform. These platforms cost money. The question is, do we always need these platforms for offline?
In our case the Offline scenario was very basic.
- Get all the data in the morning
- Work all day on the offline data
Send back all the data of the device to the SAP system in the evening
With this simple offline scenario and if you know that this app will only be used in the private network, there is no need for SAP Mobile Platform or SAP CP Mobile Services.
Okay, we don’t use the SMP or CPms. This also means we cannot use the Kapsel plugins. Kapsel plugins are Cordova plugins created by SAP. Instead of using Kapsel plugins for offline storage we’ve used a free and open source Cordova SQLite plugin. With this plugin we can use the offline storage of the mobile device but we’ll have to implement the logic ourselves.
SQLite plugin: https://www.npmjs.com/package/cordova-sqlite-plugin
There are many more: https://cordova.apache.org/plugins/?q=sqlite&platforms=cordova-windows%2Ccordova-android%2Ccordova-ios
App setup
In the app, I separated the logic is multiple logical blocks to support offline and online capabilities. Here you have a short explanation about the most internal architecture of the app. The most important blocks for the offline and online part:
- Gateway service
- Database Service
- Database Helper
- Data Persistence Layer
Gateways service
This JavaScript object is used for all the communication between the app and the SAP Backend. It will fetch data and store it into the offline database of the mobile device (if it’s running on a mobile device). Therefore it will use the Database service. The service also contains a function to send data back to the SAP system.
Database service
As we used a Cordova SQLite plugin and not the Offline Kapsel plugin, I had to create my own service to handle the communication between the app and the local database of the device. The service contains multiple functions to access the data offline by using the Cordova SQLite plugin. The functions in this service are designed to create database queries by passing JSON objects with all the required specifications. For example we could just access a table by passing the table name and the SQL “where” condition as a JSON object. This made it easier in our Controllers to access the local database.
For generating all the SQL statements and the fields of a table we created a Database Helper. This helper object contains multiple conversion functions from JSON to SQL.
Data Persistence Layer
I created this layer to support devices that don’t support Offline, for example the web browser. This layer will check if it’s a mobile device. If it’s a mobile device, it will use the local database. When it’s not a mobile device, it will use the gateway service and access data from SAP real time. The controllers of the views just access the data persistence layer and this layer will handle the request. This enabled us to run the app as a normal Fiori app and as a mobile app.
In this project I also used a BarCodeScanner, you can read more about it on: https://blogs.sap.com/2017/02/18/custom-cordova-plugin-mobile-hybrid-app/
Conclusion
Mobile doesn’t have to be expensive or complex. Depending on the case you can do it cheap and simple. Don’t get me wrong, SMP and CPms are real good products but it’s just not always required. It may take some more time to develop the offline functionality but it will save you money on the long term. No monthly fee for CPms or hardware costs for SMP.
Device independent apps do not exist! We can adapt as many devices as possible but we need to test each device.
Last but not least, SAPWebIDE is a great tool for building Hybrid Mobile apps!.
Dear Lemaire,
Any Mobile Apps had two major bottlenecks - on supporting multiple OS & Offline features.
Thanks for suggesting workarounds on both these areas wherein we can bring in ROI to the Customers.
Looking forward to more blogs from you on this front.
Hi
always great posts thk you ! Have you try to simply use localstorage Javascript API in your projects to have offline capabilities in your ui5 app ? Is it a good idea ?
Xavier
I would not use the localstorage for offline support in mobile apps. localstorage is great but has some limitations..
Kr,
Wouter
I think this blog post deserves some clarification. I agree in that you can cut upfront investments by not using any Mobile infrastructure, but this works only once, perhaps twice. The issue that we typically see is that this is exactly where people start, and some months later they magically end up having dozens of unmonitored apps using their own point-to-point connections: One app on HANA XS here, another one on Gateway on-premise there, a third one built on proprietary protocols, and on it goes. This is an IT nightmare, data security is put at risk, and there is literally no way to monitor all of this. Who is accessing the data? Where does it go? And how is it secured? This is where dedicated infrastructure shines.
This also applies to the Offline example you were giving. Mobile frameworks give you a standardized way to take your apps offline, and someone else probably put some long thought into how it ought to be done properly. By running DIY Offline solutions you end up implementing a dedicated protocol per app, which is no good beyond the first prototype. Whatever you saved within the first few weeks is going to cost you later on in terms of knowledge transfer, monitoring, documentation, and so on.
On an unrelated note, I appreciate your statement regarding "device-independent apps". While Hybrid apps enable you to share a lot of code between platforms, you really need to test on all targeted platforms. Browsers behave slightly different on the various platforms, and there may be visual glitches and the like in some of them. Of course, this is not to say you should not build hybrid apps. This should ideally be a decision based on the specific use case at hand. Sometimes Hybrid is all you need, sometimes a web app or a native app will do a better job.
Hi Michael,
Thanks for your interesting comment. I have to agree with your arguments. It’s better to use mobile infrastructure. In this case the mobile app will only be used in the internal network so security was already covered by the security of the network. For the monitoring of the devices, they already used another tool. Monitoring of who is accessing the data can also be viewed in gateway. Not as detailed as in a Mobile infrastructure but they didn’t had that before
It’s not that we just created something. We have thought this through, created guidelines, documentation,..... If there would come new apps, they would be created following the same principle. All apps would connect to the same gateway system so it will not become an IT nightmare. Using a middle layer would (in this case) be overkill.
I just want to show that it can be done without a middelayer, not saying it’s the best approach.
Kr,
Wouter
Good Job Wouter!
Actualy I'm working in a SMP + SAPUI5 + SAP Gateway proyect and as you said every devices need some adaptations of your code to work fine. SMP is a good tool too, but not in all project is necesesary. You can use a SAP Gateway for Odata service and anoder persisten layer as pouchdb. Download Data in the morning when have access to company network and time after then upload new/modified records using same Odata services.
With SMP and Kapsel Tool you can save time with login process screens and access protocols, have stadistic numbers related with login by devices, users and requests. But it´s depend of your company and your security levels, audit. Information key for ones and no for another.
In SAPUI5 App, if app is simple is better. user experience better.
If SAP is not going to update the existing iViews, Pages, etc that are used in Business Packages, will SAP provide instructions to enable the customer to update SAP standard iViews, Pages used in Business Packages to render in STANDARDS mode? find my house google street view