SAP Cloud Platform Mobile Services offer a lot different options to build applications. As a developer or architect it is hard to make the right decision. Following options are currently available:
Every option has its pros and cons, but as we often have to deal with integration of 3rd party functionality e.g. for OCR the available options are reduced to native apps and Fiori Mobile if the 3rd party functionality is available as Cordova plugin. In typical SAP Apps there is always a requirement to integrate the backend which is usually done via OData Services - that is the place where the SAP Cloud Connector enters the stage.
The scenario that is showcased in this blogpost is a real-life scenario from one of our customer projects where we had to integrate the best-in-class OCR technology from Anyline for "reading" information from IDs (passport, personal ID, driving license) into a mobile application. If you check the official developer documentation you will find out that they support the typical cross platform technologies Cordova, Xamarin and React-Native. Additionally native iOS, Android and Windows SDKs are supported. This means that the before mentioned app-types are reduced to the following scenarios:
The SAP Cloud Platform Mobile Services is a pure cloud offering on Neo and Cloud Foundry Stack. As the graphic shows the mobile devices are not calling the SAP Systems directly, but using the Mobile Services. Even though this approach is coming with license costs, it is the best way to go from a security point of view if you want to access the SAP Systems from a public network. The reason for this recommendation is obvious as the SAP Cloud Platform is the first line of defense. SAP has a deep knowledge in operating Cloud Systems and they care about DDoS Attacks, Malware detection, virus scan, intrusion detection etc. If customers use the Mobile Services the also get an additional security layer.
The SAP Cloud Connector plays a vital role in integrating the SAP Cloud Platform (Neo and Cloud Foundry) with the OnPremise landscape. You can compare the SAP Cloud Connector with a reverse proxy. The SAP Cloud Connector opens a TLS tunnel to the SAP Cloud Platform Subaccount, that all the traffic Cloud-2-OnPremise is routed through. If you are interested in a deep dive into the SAP Cloud Connector you can join the SAP Training WDECPS.
This is a question of faith. If you are experienced in SAPUI5 Development it is easy to get started with the hybrid approach. Your JavaScript skills are absolutely sufficient. You don't need any native development skills with Swift or Kotlin/Java. But there are also some drawbacks with the hybrid approach e.g. that you need a plugin for every OS feature you would like to access. The next graphic shows the difference between native an hybrid apps.
A native app is developed with the programming language supported by the OS Vendor - namely Swift and Objective-C for iOS (Apple) and Kotlin / Java for Android (Google). Using this approach you can access all functions offered by the operating system. If you would like to support both iOS and Android you need skilled developers in both areas.
A hybrid app is basically a webapplication that runs in a dedicated container - typically cordova. The container can be enhanced with functionality by the usage of plugins. A plugin is a translator between JavaScript calls from the webapplication (SAPUI5 / Fiori) and the native OS functions.
SAP WebIDE offers templates for creating Hybrid Apps. I have written a dedicated SCN blogpost on this topic. The main advantage of this approach is that no local build infrastructure i.e. a device running on MacOS is required. You can facilitate your existing SAPUI5 / Fiori development knowledge. SAP ships multiple plugins out-of-the-box and also allows to integrate 3rd party corodva plugins. But there are some restrictions when using 3rd party plugins e.g. plugins requiring any additional npm or cocoa dependencies is not supported. Cocoa dependencies are not uncommon. You don't see this restriction when adding the plugin. It first shows up in the logs of the failed build. In our case with integrating Anyline this could have been the end of the project. When we talked to Anyline about this limitation they immediately created a version without cocoa dependencies. We were pretty happy when the build was successfully completed and we were able to install the app. BUT the plugin was not working as we had forgotten an important step in the WebIDE. From a license point of view most 3rd party plugins are linked with the unique App identifier. The WebIDE build creates a random identifier so we had to override the App identifier with the one used in the license. After this small change and a new build the plugin worked like a charm.
Of course you have to think about the distribution of the Apps. If it is an enterprise App you can distribute the App with your EMM solution. If it is a public App you must go via the Google Play Store or the Apple App Store.
The disadvantage of this solution is that it does not work with the Fiori Launchpad i.e. you have to create a dedicated hybrid app for every Fiori App that facilitates the 3rd party framework.
If you would like to use the SAP Fiori Launchpad as central entry point to all of your Fiori Apps you can either access the launchpad directly from your browser or you can use the SAP Fiori Client. Both options require a direct connection to the underlying SAP System. This means the system must be accessible from the internet. But you can also create a custom SAP Fiori Client based on your needs. The SAP Cloud Platform Mobile Services can be used to create a custom Fiori Client. The usage of plugins is currently limited to the SAP Standard plugins (Kapsel). 3rd party plugins are not supported. This is was no viable option for the Anyline integration. So we decided to use the SAP Mobile SDK which allows customers to create a Custom Fiori Client locally. Using this approach you can add 3rd party plugins - again with some restrictions, but basically possible. If you would like to build apps for the iOS operating system you need a device running on MacOS and skills in building (not developing) iOS Apps, which is also the main disadvantage of this approach. But on the other hand you can ship the familiar Fiori UX to your users. You can even develop a single app for both desktop and mobile users, offering the 3rd party functionality, in our case the Anyline OCR, only if the app is running in the Fiori Client on a mobile device.
Before you start developing Fiori Apps, please do your users and yourself an favour and study the Fiori Design Guidelines.
SAP Fiori offers a great user experience, but when it comes to requirements like offline data storage SAP Fiori might not be the best choice. Based on the great customer feedback on SAP Fiori, SAP decided to launch a dedicated SDK for native iOS and Android Apps. The main advantage of the SAP Cloud Platform SDK for iOS and Android is that you get a lot of controls that expedite the development process and allow you to ship a great native UX. Have a look on the following screenshots to so the controls in action on both iOS and Android. Please read the iOS SDK Documentation and/or the Android SDK Documentation for further information.
A sample control from the iOS SDK:
A sample control from the Android SDK:
As Anyline offers a native SDKs for both iOS and Android the integration was straight forward. For iOS we created a cocoapod based project and included the SAP Frameworks and the Anyline SDK. We then used the Fiori Mentor App on an iPad to speed up the development process and get the required code snippets.
No matter if you want to provide hybrid or native apps, it depends on the offering of the 3rd party framework vendor to decide which option is viable for you. Based on our experience with integrating Anyline I hope that you were able to see that all options might be possible and that it is not really difficult to integrate native OS and 3rd party framework functionality to SAP Apps.
- Fiori Mobile / Hybrid Apps
- Mobile Development Kit
- Mobile Cards
- Native Apps (SAP Cloud Platform SDK for iOS/Android)
Every option has its pros and cons, but as we often have to deal with integration of 3rd party functionality e.g. for OCR the available options are reduced to native apps and Fiori Mobile if the 3rd party functionality is available as Cordova plugin. In typical SAP Apps there is always a requirement to integrate the backend which is usually done via OData Services - that is the place where the SAP Cloud Connector enters the stage.
The scenario that is showcased in this blogpost is a real-life scenario from one of our customer projects where we had to integrate the best-in-class OCR technology from Anyline for "reading" information from IDs (passport, personal ID, driving license) into a mobile application. If you check the official developer documentation you will find out that they support the typical cross platform technologies Cordova, Xamarin and React-Native. Additionally native iOS, Android and Windows SDKs are supported. This means that the before mentioned app-types are reduced to the following scenarios:
- Fiori Mobile App with Cloud Build
- Fiori Mobile Client with Custom Plugins
- Native Apps using the SAP Cloud Platform SDK
General Architectural Overview
The SAP Cloud Platform Mobile Services is a pure cloud offering on Neo and Cloud Foundry Stack. As the graphic shows the mobile devices are not calling the SAP Systems directly, but using the Mobile Services. Even though this approach is coming with license costs, it is the best way to go from a security point of view if you want to access the SAP Systems from a public network. The reason for this recommendation is obvious as the SAP Cloud Platform is the first line of defense. SAP has a deep knowledge in operating Cloud Systems and they care about DDoS Attacks, Malware detection, virus scan, intrusion detection etc. If customers use the Mobile Services the also get an additional security layer.
The SAP Cloud Connector plays a vital role in integrating the SAP Cloud Platform (Neo and Cloud Foundry) with the OnPremise landscape. You can compare the SAP Cloud Connector with a reverse proxy. The SAP Cloud Connector opens a TLS tunnel to the SAP Cloud Platform Subaccount, that all the traffic Cloud-2-OnPremise is routed through. If you are interested in a deep dive into the SAP Cloud Connector you can join the SAP Training WDECPS.
Mobile Architecture
Going Hybrid or Native ?
This is a question of faith. If you are experienced in SAPUI5 Development it is easy to get started with the hybrid approach. Your JavaScript skills are absolutely sufficient. You don't need any native development skills with Swift or Kotlin/Java. But there are also some drawbacks with the hybrid approach e.g. that you need a plugin for every OS feature you would like to access. The next graphic shows the difference between native an hybrid apps.
A native app is developed with the programming language supported by the OS Vendor - namely Swift and Objective-C for iOS (Apple) and Kotlin / Java for Android (Google). Using this approach you can access all functions offered by the operating system. If you would like to support both iOS and Android you need skilled developers in both areas.
A hybrid app is basically a webapplication that runs in a dedicated container - typically cordova. The container can be enhanced with functionality by the usage of plugins. A plugin is a translator between JavaScript calls from the webapplication (SAPUI5 / Fiori) and the native OS functions.
Native vs Hybrid App
Option 1 - Fiori Mobile with Cloud Build
SAP WebIDE offers templates for creating Hybrid Apps. I have written a dedicated SCN blogpost on this topic. The main advantage of this approach is that no local build infrastructure i.e. a device running on MacOS is required. You can facilitate your existing SAPUI5 / Fiori development knowledge. SAP ships multiple plugins out-of-the-box and also allows to integrate 3rd party corodva plugins. But there are some restrictions when using 3rd party plugins e.g. plugins requiring any additional npm or cocoa dependencies is not supported. Cocoa dependencies are not uncommon. You don't see this restriction when adding the plugin. It first shows up in the logs of the failed build. In our case with integrating Anyline this could have been the end of the project. When we talked to Anyline about this limitation they immediately created a version without cocoa dependencies. We were pretty happy when the build was successfully completed and we were able to install the app. BUT the plugin was not working as we had forgotten an important step in the WebIDE. From a license point of view most 3rd party plugins are linked with the unique App identifier. The WebIDE build creates a random identifier so we had to override the App identifier with the one used in the license. After this small change and a new build the plugin worked like a charm.
Of course you have to think about the distribution of the Apps. If it is an enterprise App you can distribute the App with your EMM solution. If it is a public App you must go via the Google Play Store or the Apple App Store.
The disadvantage of this solution is that it does not work with the Fiori Launchpad i.e. you have to create a dedicated hybrid app for every Fiori App that facilitates the 3rd party framework.
Option 2 - Fiori Mobile Client with Custom Plugins
If you would like to use the SAP Fiori Launchpad as central entry point to all of your Fiori Apps you can either access the launchpad directly from your browser or you can use the SAP Fiori Client. Both options require a direct connection to the underlying SAP System. This means the system must be accessible from the internet. But you can also create a custom SAP Fiori Client based on your needs. The SAP Cloud Platform Mobile Services can be used to create a custom Fiori Client. The usage of plugins is currently limited to the SAP Standard plugins (Kapsel). 3rd party plugins are not supported. This is was no viable option for the Anyline integration. So we decided to use the SAP Mobile SDK which allows customers to create a Custom Fiori Client locally. Using this approach you can add 3rd party plugins - again with some restrictions, but basically possible. If you would like to build apps for the iOS operating system you need a device running on MacOS and skills in building (not developing) iOS Apps, which is also the main disadvantage of this approach. But on the other hand you can ship the familiar Fiori UX to your users. You can even develop a single app for both desktop and mobile users, offering the 3rd party functionality, in our case the Anyline OCR, only if the app is running in the Fiori Client on a mobile device.
Before you start developing Fiori Apps, please do your users and yourself an favour and study the Fiori Design Guidelines.
Option 3 - Native Apps using the SAP Cloud Platform SDK
SAP Fiori offers a great user experience, but when it comes to requirements like offline data storage SAP Fiori might not be the best choice. Based on the great customer feedback on SAP Fiori, SAP decided to launch a dedicated SDK for native iOS and Android Apps. The main advantage of the SAP Cloud Platform SDK for iOS and Android is that you get a lot of controls that expedite the development process and allow you to ship a great native UX. Have a look on the following screenshots to so the controls in action on both iOS and Android. Please read the iOS SDK Documentation and/or the Android SDK Documentation for further information.
A sample control from the iOS SDK:
A sample control from the Android SDK:
As Anyline offers a native SDKs for both iOS and Android the integration was straight forward. For iOS we created a cocoapod based project and included the SAP Frameworks and the Anyline SDK. We then used the Fiori Mentor App on an iPad to speed up the development process and get the required code snippets.
Conclusion
No matter if you want to provide hybrid or native apps, it depends on the offering of the 3rd party framework vendor to decide which option is viable for you. Based on our experience with integrating Anyline I hope that you were able to see that all options might be possible and that it is not really difficult to integrate native OS and 3rd party framework functionality to SAP Apps.
- SAP Managed Tags:
1 Comment
