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.
