Teil 2: Native Apps und Fazit

In Teil 1 sind wir zunächst auf webbasierte und hybride Apps eingegangen – von uns als Fiori Web und Fiori Hybrid bezeichnet. Während Fiori Hybrid eher in Ausnahmefällen anwendbar ist, ist Fiori Web das Standardwerkzeug in S/4 HANA-Umgebungen und bietet somit eine Vielzahl an Anwendungsmöglichkeiten. Apps werden plattform- und endgerätübergreifend einheitlich dargestellt, viele Templates und Floorplans erleichtern die Entwicklung und die Integration in bestehende SAP on Premise und SAP Cloud-Lösungen sind klare Pluspunkte.

In diesem Teil gehen wir nun speziell auf native Apps ein, also Apps, die tiefer in die Endgeräte eingebettet sind, spezielle Funktionen nutzen und auf einen speziellen Anwendungsfall reduziert sind. Sämtliche nachfolgende Techniken oder Frameworks basieren dabei auf den SAP Cloud Platform Mobile Services. Dasbedeutet, dass zu deren Nutzung der Service auch eingekauft werden muss. Die Voraussetzungen, Details und Preise können hier nachgelesen werden: https://www.sapstore.com/solutions/40130/SAP-Cloud-Platform-Mobile-Services

Was man dafür als Konsument bekommt, zeigt vereinfacht folgende Ansicht:

Quelle: https://developers.sap.com/topics/mobile.html#details/cjma4l9o9dbmb0932rkx4wxo2

Wir haben uns das nun im Detail angeschaut und stellen die Besonderheiten kurz gegenüber und geben anhand einer Bewertungsmatrix ebenso einen Ausblick, wann welches Framework am erfolgversprechendsten ist.

Mobile Cards

Mit Mobile Cards hat SAP etwas im Portfolio, das gar nicht so wirklich App ist, sondern mehr wie ein Wallet oder Passbook daherkommt. Der Fokus liegt nicht auf den Apps an sich, sondern auf dem Content. Dieser wird  dem Benutzer relevant an einer zentralen Stelle gebündelt angezeigt. Die Inhalte sind benutzerbezogen und für den Benutzer jederzeit verfübar, ohne dass er dabei unterschiedliche Apps öffnen muss. Das Beste daran: Existieren bestehende Apps im Fiori Launchpad, die mit Fiori Elements umgesetzt wurden, kann man diese von dort automatisch zum Wallet hinzufügen. Das gleiche gilt auch für SAP Cloud-Lösungen wie beispielsweise SuccessFactors, Concur, Fieldglass etc.

Beispiele:

  • Meine letzten Zeitnachweise
  • Meine letzten Bestellungen
  • Meine offenen Genehmigungen
  • Mein Team
  • Meine Kundeninformationen

Vorteile:

  • Online als auch Offline verfügbar
  • Automatische Updates der Karten
  • Der Benutzer definiert seine Inhalte selbst
  • Apps basierend auf Fiori Elements können zum Wallet hinzugefügt werden
  • Content Integration aus SAP Cloud Systemen (z. B. SuccessFactors, Ariba, Concur, C/4 Hana und Fieldglass)
  • Plattformübergreifend verfügbar

Nachteile:

  • Keine Full-Stack Apps
  • Nur lesende Informationen
  • Kostenpflichtige Cloud Platform Mobile Services notwendig

Sinnvolle Use Cases:

  • Genehmigungs-Workflows
  • Lesende Information auf Inhalte, die man täglich benötigt (z. B. Kundenkarteien als Account Manager, Bestellübersichten als Einkäufer etc.)

Mobile Development Kit

Wenn man in der Vergangenheit native Apps entwickeln wollte, führte kein Weg daran vorbei, dies für sämtliche Plattformen separat zu entwickeln. Entwicklungs- und Wartungskosten potenzieren sich dementsprechend, ebenso benötigen die Entwickler plattformabhängiges Know-How. Mobile Development Kit (MDK) setzt genau hier an, indem es eine plattformübergreifende sowie native Entwicklung ermöglicht. Klingt spannend, ist es auch. Die App wird über Metadaten definiert. Dasbedeutet, dass sämtliche Pages, Actions etc. in Metadaten zentral definiert sind und verknüpft werden können. Sonderlogiken können in Javascript über Rules erweitert integriert werden. Die Metadaten werden beim Kompilieren der App dann in die entsprechende Zielplattform übersetzt.

Vorteile:

  • Plattformübergreifende native Entwicklung für Android und iOS
  • Flüssige, mobile User Experience
  • Keine Java, Kotlin oder SWIFT Kenntnisse notwendig
  • Automatische App-Updates
  • Nutzung nativer Funktionen (z. B. Push Notifications, Offline, Barcode Scanning, Kamera, Telefon, Kontakte, GPS)

Nachteile

  • Nicht alle nativen Funktionen des Endgerätes können genutzt werden (z. B. Sensoren für Beschleunigung, Temperatur oder Kompass)
  • Nicht für rechenintensive Apps geeignet (z. B. Grafiken etc.)
  • Kostenpflichtige Cloud Platform Mobile Services notwendig
  • Keine dynamische Benutzeroberflächen während der Laufzeit

Sinnvolle Use Cases

  • App soll ausschließlich für mobile Endgeräte laufen
  • Benötigte Plattformen sind Android und iOS
  • Keine speziellen native Funktionen benötigt (Sensoren für Beschleunigung etc.)

Cloud platform SDK für Android und iOS

Die Crème de la Crème der mobilen Apps im SAP Umfeld  ist die Mobile Cloud Platform SDKs für iOS und Android. Der Name zeigt eigentlich schon, was sich dahinter verbirgt: eine in Kooperation mit Apple und Google erstellte SDK für native Apps der jeweiligen Zielplattform. Design Sprachen beider Welten verschmelzen miteinander und lassen die Apps nahtlos in die Systemumgebung einbinden. Man erreicht den höchsten Integrationsgrad, sämtliche nativen Funktionen der Endgeräte können genutzt werden für eine bestmögliche mobile User Experience. Im Gegenzug muss man auch mit dem größtmöglichen Aufwand und Kosten rechnen, denn die Apps müssen für jede Plattform separat implementiert werden. Die WebIDE hat hier ausgedient, als Entwicklungsumgebung nutzt man die typischen Entwicklungsumgebungen für iOS und Android (Xcode und Android Studio), so dass sich die Entwickler mit Swift für iOS und Java/Kotlin für Android auseinandersetzen müssen.

Quelle: https://experience.sap.com/fiori-design-ios/

Vorteile:

  • Bestmögliche mobile User Experience
  • Bestmögliche Performance
  • Sämtliche nativen Funktionen verfügbar
  • Kaum Einschränkungen bzgl. Anforderungen und Umsetzbarkeit
  • SDKs können getrennt voneinander genutzt werden
  • Dynamische Benutzeroberflächen zur Laufzeit über APIs

Quelle: https://experience.sap.com/fiori-design-android/

Nachteile:

  • Kostenintensiv, da Entwicklung und Wartung plattformabhängig ist
  • Kostenpflichtige Cloud Platform Mobile Services notwendig
  • Zusätzliches Entwickler Know-How benötigt

Sinnvolle Use Cases:

  • Rechenintensive mobile Apps, z. B. für 3D-Engines, Grafiken etc.
  • Erweiterte native Funktionen notwendig
  • Anforderungen bestehen ausschließlich für eine Plattform
  • Die bestmögliche mobile User Experience wird benötigt

Bewertungsmatrix der unterschiedlichen Frameworks

Die einzelnen Frameworks bieten Vor- und Nachteile, es hängt also immer vom individuellen Anwendungsfall ab, wann welches Framework einzusetzen ist. Benötigt man Offline-Zugriff oder genügt eine Online-Nutzung? Werden native Funktionen benötigt? Wenn ja, bis zu welchem Grad? Fährt man eine Android- oder iOS- Strategie oder gar arbeitet gar plattformübergreifend? Das sind beispielhafte Fragestellungen, die eine Toolauswahl beeinflussen. Nachfolgende Bewertungsmatrix fasst die zentralen Eigenschaften nochmals zusammen und wir haben uns herangewagt, diese in unterschiedlichen Punkten zu bewerten.

Fazit

SAP bietet mittlerweile eine breite Produktpalette für die mobile Entwicklung an. Von wiederverwendbaren Templates über Low-Code Framework Entwicklungen bis hin zu OS-spezifischer Individualentwicklung stellt die SAP dabei sicher, dass die bewährten Fiori Design-Prinzipien eingehalten werden. Je nativer ein Framework wird, sprich, je mehr mobile Funktionen das Framework abdeckt, desto höher werden auf der anderen Seite aber auch die Entwicklungskosten.

Im Bereich der nativen Entwicklung fährt die SAP mit Mobile Cards einen besonderen Ansatz. Die im Passbook oder Wallet Style gehaltene App konsolidiert Informationen aus diversen Cloud Systemen oder Apps aus dem Fiori Launchpad an eine zentrale Stelle. Informationen sind so immer griffbereit und der Benutzer wird automatisch über Änderungen informiert bzw. neuester Content wird automatisch auf das Endgerät synchronisiert. Die Intention von Mobile Cards sind jedoch nicht Full-Stack Apps abzubilden, sondern Content schnell dem Benutzer zur Verfügung zu stellen. Gerade für Workflow-Szenarien interessant oder für Content der für den Benutzer für das tägliche Arbeiten und in seiner Funktion benötigt wird.

Werden Apps benötigt, die offline und mit gängigsten nativen Funktionen ausgestattet sein sollen und zudem plattformübergreifend kompatibel sein müssen, dann ist das Mobile Development Kit erste Wahl. Wir sind der Meinung, dass 80% der geschäftsprozessrelevanten Apps damit abgebildet werden können. Der Wartungsaufwand hält sich in Grenzen und Änderungen an der App werden auf den Endgeräten automatisch synchronisiert.

Wenn darüber hinaus weiterführende native Funktionen benötigt werden, beispielsweise der Zugriff auf Hardware-relevante Funktionen oder OS-spezifische Funktionen, dann sollte man hingegen zu den Cloud Platform SDKs für Android und iOS greifen.

Empfohlene Artikel

Data & Analytics

Das Enterprise Information Management mit Data as a Service (DaaS) neu aufstellen

Vor dem Hintergrund der voranschreitenden Digitalisierung und Themen wie Value-Driven Data Quality Management (VDQM) richten Datenverantwortliche ihre Aufmerksamkeit zunehmend auf den …

weiterlesen
Logistics

Supply Chain Visibility in der Versandhandel-Logistik

Sichtbarkeit in der Logistik von heute ist ein Punkt, der bei allen Supply Chain Managern auf der Tagesordnung steht. Das Bewusstsein …

weiterlesen
Logistics

Neue Akteure in der Pharmalogistik der „letzten Meile“

Jüngst haben einige Berichte über spannende Möglichkeiten für die Distribution auf der „letzten Meile“ (letztes Wegstück beim …

weiterlesen

Denken Sie Ihre Value Chain neu mit uns

Kontaktieren Sie uns