A guide to the mobile SAP strategy (Part I)

Mobile apps are no longer an innovation. They are part of everyday life and the smartphone has long since replaced the laptop as the most popular end device.

Nevertheless, in many companies we see that a mobile strategy rarely exists, especially in the SAP environment, and processes have not yet been optimized for mobile devices. Admittedly, SAP was long known for its nested, complex, but also confusing business applications. Transactions were overloaded with functions, which meant users needed extensive training and a long time to familiarize themselves. Is this idea something people find difficult to get away from?

The introduction of SAP Fiori

Since the introduction of SAP Fiori in 2013, SAP has been trying to counteract this and has made a paradigm shift.

Figure 1: SAP Fiori Overview Page

Complexity is being reduced deliberately, and SAP is focusing more on the real needs of the users. Although the company has been offering platforms to integrate mobile devices (e.g. SAP Netweaver Mobile and SAP Mobile Platform/Sybase Unwired Platform) for more than seven years, SAP Fiori enables simple, cross-device and cost-neutral implementation thanks to HTML5 – in the simplest case without additional licenses and infrastructures. Since then, SAP has significantly expanded its portfolio and now offers different frameworks for mobile app development (more on this in part 2).

In part 1, we will discuss web-based and hybrid apps first of all, before we move on to native apps in part 2 and draw a conclusion.

Figure 2: SAP Fiori Analytical List Page

Sap Fiori Web

SAP Fiori Web

With SAP Fiori Web we are referring to the web-based development of mobile apps within the context of SAP. This is the easiest way to adapt applications to mobile devices, but at the same time it offers the smallest range of functions, and can only be accessed via a browser. The surfaces are uniform, coherent and tidy. Design patterns and predefined floor plans also make it easier for developers to create transactional or analytical apps. The developer has the choice of using SAPUI5 to program the user interfaces in the traditional way, or using Fiori Elements, meta-language-driven development for the most common application patterns. The latter allows the surfaces to be generated accordingly.

Benefits:

Simple and fast implementation of mobile apps with minimal effort

Central access to the apps via the Fiori Launchpad

Customizable and role-based

Standard apps can be used in the SAP catalog

No additional licenses or infrastructure required

Consistent design and UX patterns

Compatible across platforms

Disadvantages:

Can only be accessed online via browser

No possibility to integrate the native functionalities of the end devices (push, camera, sensors etc.)

Increased HTTP traffic

Worthwhile use cases:

Native functionalities not required

Online access is sufficient

Central access to multiple apps from multiple backend systems

Apps should run on all platforms and end devices

Figure 3: SAP Fiori Object Page

Hybrid SAP Fiori App

Basically, a hybrid Fiori app is a native app container in whose core the web-based Fiori app runs. It thus contains a cross-section of the properties of native and mobile web applications, and it works on different platforms. Furthermore, the use of individual system functions is not restricted. This is made possible by the WebIDE Plugin Hybrid Application Toolkit, which supplements the application with Cordova and capsule plug-in APIs. The look & feel of the Fiori app is almost unchanged, but the functions are different. This is because a hybrid app makes the integration of some native functionalities possible. These include the camera, push notifications, offline mode, contacts, phone and calendar access. Unlike Fiori Web, you don’t access it via a browser, but via an app on an Android or iOS device. It comes much closer to the “app feeling” by removing superfluous elements, such as the browser address bar, and by presenting the app in full screen mode.

Benefits:

Offline access possible as well as utilization of the most common native functionalities, e.g. camera, phone, contacts, etc.

Rather obsolete, as the Mobile Development Kit is now preferred for cross-platform, native development

Further developments of the framework are not generally to be expected

Worthwhile use cases:

Existing Fiori Web apps are to be extended with native functions

Conclusion: SAP Fiori Web vs. Fiori Hybrid

Fiori Web can only be accessed online and offers relatively few mobile functions, but the interfaces are displayed optimally across different platforms and devices. SAP also offers many reusable templates and all apps can be integrated into the Fiori Launchpad (on premise or cloud) at a central location, role-based of course, for which the user is also authorized. Fiori Web has a very high degree of maturity and is standard in S/4 HANA environment.

Fiori Hybrid, on the other hand, is more of a special case. From our point of view, an obsolete model that we simply wanted to mention for the sake of completeness. When it comes to cross-platform developments that require native functionality, the Mobile Development Kit should be used instead. Nevertheless, Fiori Hybrid can be useful at one point or another, for example, if existing Fiori Web apps have to be subsequently enriched with native functions. But once again, the Fiori Web app must have been prepared beforehand and must run in stand-alone mode, otherwise the advantage is gone. All in all, we see very few corporate application cases for Fiori Hybrid.

In Part 2, we enter the native world of mobile developments in the SAP environment and compare all of the presented techniques in an evaluation matrix. So stay tuned!