How to Write Online Mobile Apps Consuming SAP Back End Systems
Table of Contents
- Purpose of this document
- The Big Picture
- Types of Mobile Apps
- Reusable Library
- How to Build an Odata Service Based on Sap Netweaver Gateway 2.0
- Publishing the App in the App Store
- Further Information
Purpose of this document
If you want to create a mobile app for SAP and need instructions how to do this, this “cookbook” is the right place for you. The emphasis of the cookbook is on online apps, meaning mobile apps that are always connected to a back-end system (usually a classical ABAP® system). The cookbook will also help you better understand how Sybase® Unwired Platform, SAP NetWeaver® Gateway technology, the SAP® Afaria® mobile device management solution, the back end, and various mobile operating systems work together.
The Big Picture
Types of Mobile Apps
There are various approaches for building mobile apps, some currently available and others that will be available in the near future. They can be distinguished according to two aspects:
Back-end communication pattern: The mobile infrastructure that is available today supports two models for the communication between mobile client and the application system in the back end. The first model is request/response-based, in which the client sends requests to the back end and receives a response based on it. The second uses data synchronization/replication, where data is transferred between the back end and the client before or after the app is or has been used.
The figure below lists all meaningful combinations based on these two aspects.
All of these approaches have benefits and drawbacks – there is no "one size fits all" solution. The approach that is best and will result in the best possible mobile app implementation depends on the specific use case.
UI technology: Native
Back-end communication pattern: Request/response
Online apps are built using the native technology of the specific mobile platform (such as Apple iOS or Google Android). For receiving data from the back end, the mobile apps send requests to the mobile infrastructure, which are then forwarded to the application system that is used as the back end. The Open Data Protocol (OData) is used for this data exchange. With that, the online apps follow the strategic SAP architecture: the UI always consumes restless OData services. The business logic is on the back-end system, the UI logic on the client, and the contract between both is OData.
A key aspect of this approach is that all exchange of data is triggered by the mobile app (client).
The programming model for online apps is well established and very mature. The majority of mobile apps that SAP shipped between the end of 2011 and mid-2012 follow this approach. Compared to other approaches, the programming model for online apps is relatively simple, since only UI logic must be covered by the front-end code. The business logic (such as transformation of data, computation of values, and advanced validity checks for data) is performed by the back-end application.
From the end user's perspective, the main advantage with online apps is that the data of the back-end system can be accessed directly – exactly as it is stored at the point in time when it is displayed on the device. This is especially important for data that changes frequently (such as with available-to-promise checks, room reservations, or leave requests from employees.).
Using native UI technology delivers the best possible user experience that can be achieved with online apps. All UI elements and effects that the platform has to offer are available. For native apps, access to the device hardware (such as the microphone, camera, and accelerometer) is supported in the best possible way, and all the platform’s public application programming interfaces (APIs), such as for a calendar or phone, are available. When done right, online apps make perfect use of the device capabilities and provide users with an experience that is well aligned with the UI paradigms of the mobile platform and intuitive to use.
Online apps require a connection to the back end to be fully functional. As with all mobile apps, online apps must not crash or become completely unusable if no connection to the back end can be established. However, they may only be able to show some cached data and present a warning to the user that data residing in the application system cannot be read or updated until the connection is established again. In this way, they behave like a mobile Web browser or the e-mail client on a mobile device.
As consequence of the native UI, online apps are platform-specific. This means that an app that has been built on one platform (Apple iPhone, for example) must be ported to another platform by re-implementing the code for the target platform. Between different mobile platforms, reuse is only possible on the conceptual level, not with respect to code, at least as far as the front end is concerned; back-end functionality can and should be identical, however.
The native programming model also has some limitations around extensibility, since programming code is compiled and changes cannot be made later on the basis of the executable format alone. Therefore extensibility must be built in into the app, for which several approaches exist today. However, extensibility causes additional implementation effort with native apps.
UI technology: Native
Back-end communication pattern: Synchronization
With respect to UI technology, offline and online apps are identical: both use the native UI technology of the mobile platform. Where online and offline apps differ is in the approach to exchanging data with the back end. Here, offline apps use the mobile infrastructure (Sybase Unwired Platform or the data orchestration engine) to copy all relevant data from the back-end system to a local database on the device. This is done when a fast and reliable connection between the mobile infrastructure and the mobile device is available – for instance, when users are in the office and can access a Wi-Fi connection. Offline apps are built to access the data in the local database directly.
In the case of updates, the offline app also directly manipulates the locally stored data. Later, when a good connection to the back end is available through the mobile infrastructure, the changes are replicated to the application system.
To describe which data should be exchanged between the mobile device and the back end, developers define so-called mobile business objects (MBOs). All data elements of an MBO are replicated to the device and stored in the local database. Thus, MBOs reflect the data model of the offline mobile application.
For some use cases, it is crucial that the mobile app is fully functional even if the back-end system cannot be reached. This can typically occur when the mobile device is used outside an urban environment, where the mobile network (3G/4G or UMTS/LTE) may not be available. In some scenarios, it is not sufficient simply to rely on cached data that has been read in a previous request; all relevant data must be locally stored on the device. So in situations where good network coverage is not likely, an offline app is probably the right approach.
Since data is stored locally, offline apps can work on large amounts of data efficiently – independently of the availability or speed of the wireless network. This is beneficial from a user-experience perspective.
Concerning UI technology, the benefits of offline apps are identical to those of online apps. All device features can be used in the optimal fashion, which enables developers to achieve the best-possible user experience.
The programming model of offline apps is more complicated than for online apps, since the app must be able to interpret database content correctly. This means that some of the business logic that has been implemented already as part of the back-end application must be part of the mobile app as well.
Synchronization issues can cause data to become outdated. For information that changes frequently (such as the number of items of a specific article stored in a warehouse), this can be problematic. For master data, which by definition changes less frequently (such as customer contact information or product descriptions), this is less of a problem.
Since updates are not done synchronously, parallel write operations can result in conflicts that must be resolved at a later point in time. The resolution of these issues may require manual work, because it can be impossible to decide programmatically which one of the conflicting updates is more relevant. In such situations it may be necessary for a user to merge changes manually. These problems are more likely to happen for data that can potentially be changed by several users in parallel. If technical or organizational measures can be taken to guarantee that only one person can update one instance of a data entity, this problem can be avoided.
It is not surprising that offline apps are often used in the sales area. Here, users need fast access to large amounts of data that does not change very often, such as product catalogs. Updates, such as a change in a customer’s contact information, happen rarely, and it is typically one specific person who is in charge of that set of data, which makes update conflicts unlikely.
Another area in which offline apps are popular is maintenance and asset management, because connectivity cannot always be taken for granted, and there is a high data volume as well.
While validations for online apps are done in the back end directly for each request, this is not the case for offline apps: due to the asynchrony, validations are either done when the data is synchronized or must be implemented on the client. This makes error handling much more complex, as dependent data may have changed in the meantime.
Like online apps, offline apps are also platform-specific. UI- and platform-related code cannot be reused on another platform. Since the various platforms also require different programming languages (such as Objective-C for iOS and Java for Android), even code that is not directly related to UI and platform APIs cannot be reused.
Offline apps and online apps share the same limitations with respect to extensibility. However, since offline apps typically cover a wider range of functionality than online apps (which has nothing to do with technology but is more a consequence of the use cases and scenarios for which offline apps are built), extensibility is an even hotter topic here. The more process steps an app covers, the likelier it is that the customer will need changes, because at least one process step will probably be different from what development team has foreseen.
Back-end communication pattern: Request/response
Mobile devices provide powerful Web browsers that fulfill or even push the latest Web standards (for example, HTML5). At least for iOS and Android, the platform-provided Web browsers Safari and Chrome are based on the same HTML-rendering engine (Webkit). In this, Safari and Chrome are very similar, which allows Web developers to define HTML-pages that are rendered similarly on the two leading smart phone platforms.
The major benefit of browser-based UIs is that they are platform neutral – the same UI can, for instance, be used for an iPhone and an Android smart phone. However, if smart phones and tablet computers are both supported, the layout of the page should adapt and make use of the tablet’s additional screen space; a “one size fits all” approach would lead to very poor user experience.
For browser-based UIs, it is not necessary to install additional software on the device. The user only needs to know the initial URL to start using the UI. Native apps, however, require an installation step, in which the user must visit the respective applications store (such as the Apple App Store or Google Play) and download the app. Especially in business-to-consumer scenarios, this may be perceived as a significant hurdle that prevents users from using the app.
Even though browsers run fast on modern mobile devices, they still cannot reach the performance of the native UI technology. This can impact user experience – for example, scrolling through lists of items may be slower in a browser than in a native app.
With respect to device integration, browser-based UIs have limitations because certain hardware components or platform APIs may not be accessible from within the browser’s sandbox.
Back-end communication pattern: Request/response + synchronization
The hybrid container is evolving technology provided by Sybase, an SAP company. It consists of a generic native app that serves as a runtime environment for HTML-based application UIs. In this, it is comparable to the platform-provided Web browser. However, the hybrid container offers more APIs than the standard Web browser, such as for exchanging data with the back end or using device-specific hardware (for example, in combination with Phone Gap).
As of June 2012, the hybrid container is still evolving, and a final assessment can only be done once a version is available that supports all required features. However, some benefits and drawbacks are discussed here based on an evaluation of the general approach.
By using HTML5 for the UI, apps using the hybrid container can be used on all mobile platforms for which the hybrid container is available – without porting efforts for the app development teams. Since additional APIs are available, these apps can provide functionality that is not available for browser-based apps.
The hybrid container must be installed, before the apps can be used – in this, they are similar to native apps. When it comes to user experience, apps running inside the hybrid container have some of the limitations of browser-based UIs; primarily, performance is not as good as with native applications.
If you want to develop an app based on the SAP Mobile Platform, you need development licenses for all relevant components. SAP offers a Mobile Apps Partner program which covers the packaged app certification, SAP Store participation and includes the developer user licenses for the required components.
For further details, visit:
SAP offers reusable libraries that enable you to:
Communicate with the Sybase Unwired Platform server
Handle OData connections
Parse OData XML documents
Where to Download
http://service.sap.com > Software Downloads > Search for Software Downloads > Search Term: “Sybase Unwired Platform”
Select Sybase Unwired Platform 2.1 Installation Product.
Download and unzip the Sybase Mobile SDK (File 51043534_3.zip).
…ODataSDK.zip: Libraries for OData handling:
libSDMConnectivity: Connection to an OData provider (such as SAP NetWeaver Gateway) directly
libSDMParser: Parsing of OData XML documents
libSDMSupportability: Logging and tracing features (e.g. sending of logging information via email)
…ODPSDK.zip: Libraries for communication to Sybase Unwired Platform server and optionally with SAP Afaria:
How to Build an Odata Service Based on Sap Netweaver Gateway 2.0
There are several possibilities for consuming SAP software systems using SAP NetWeaver Gateway 2.0. For the online approach, SAP recommends the OData Channel programming paradigm. This allows development of OData content and metadata in back-end components. In this case, no content needs to be developed or deployed on the SAP NetWeaver Gateway server, which substantially simplifies development, deployment, and maintenance and results in lower total cost of development and total cost of ownership.
The objective of what is often called “content development” is to expose data from the back-end server as OData services through the SAP NetWeaver Gateway server. Ideally, consumption should be easy, or at least easier than consuming existing back-end functionality, and exposed services should be designed outside-in to support specific mobile applications. Note that this means OData services are explicitly designed for specific mobile apps and not for general purpose or reuse. Existing functions of the back end in general do not fulfill the requirements of mobile online applications; they are either too complex, have too many fields and child nodes, are slow, or impose constraints regarding their transaction semantics. These issues also apply to service-oriented architecture (SOA) services, which is one of the reasons why it is not possible to simply reuse SOA for mobile apps. As a consequence, existing back-end functionality must be adapted for new OData service exposure.
SAP decided to use OData as an application protocol on HTTP for UI consumption in general and for mobile in particular. OData builds on the known ATOM/PUB standard (which is used for news feeds, among other things). Instead of hypertext, OData transfers the state representation of tables and resources by means of structured XML. Besides that, Gateway supports JSON as another format. OData services are representational state transfer or REST services.
Using OData Channel, an adaption happens completely on the back end, in a coded or generated component called the data adapter.
Detailed cookbooks can be found here:
The service builder, which was introduced with SAP NetWeaver Gateway SP04, is the recommended way to create OData services.
Publishing the App in the App Store
The SAP Store offers enterprise-ready apps in an environment that is as easy to use and familiar as a consumer app store but addresses the unique needs of enterprise customers. It's available as a Web site as well as in versions for iOS and Android devices. Customers can download and test apps before they buy. To publish your app in the SAP Store, your app must be a SAP certified mobile app (see here: http://www.sapmobileappspartnercenter.com/build).
The following technical requirements are checked as part of the certification process. The mobile app must:
Use one or more SAP mobile platform components
Not use competitive platform components
Be fully functional, based on RIM, Android, or Microsoft Windows Mobile, and able to be downloaded and installed “over the air”
Have standardized maintenance terms
Include a list of required software components and interfaces (including compatibility restrictions)
Have a demo mode with demo data or a similar presentation suited for an easy customer experience
Once your solution has been certified, send an e-mail to firstname.lastname@example.org to request your SAP Store listing. You will receive an invitation e-mail with detailed instructions on how to publish your solution on the SAP Store.
Information for partners: http://www.sapmobileappspartnercenter.com
Sybase Unwired Platform developer center: http://scn.sap.com/community/developer-center/mobility-platform
SAP NetWeaver Gateway developer center: http://scn.sap.com/community/developer-center/netweaver-gateway
Sybase Unwired Platform in general: http://www.sybase.com/products/mobileenterprise/sybaseunwiredplatform
SAP Store: http://store.sap.com