MAUI – Mehr als eine Insel

Im Mai 2020 hat Microsoft eine neue, vereinheitlichte UI-Plattform für alle Systeme unter dem klangvollen Namen MAUI bzw. in voller Länge „.NET Multi-Platform App UI“ vorgestellt, die voraussichtlich im November 2021 auf den Markt kommen wird. Doch was genau verbirgt sich hinter diesem Namen? Diese Frage soll in diesem Artikel beantwortet werden. Dabei sollen die Plattform vorgestellt, die technischen Hintergründe erläutert und vor allem auch das Potential der Technologie herausgestellt werden.  

Um MAUI als Plattform zu verstehen, muss man zunächst Xamarin kennen. Xamarin (und im speziellen Xamarin.Forms) ist eine Plattform zur Entwicklung von nativen Apps für iOS, Android und UWP mit C#, XAML und .NET. Man kann dabei aus einer Code-Basis für alle unterstützten Betriebssysteme eine App erzeugen. Somit ist der Aufwand für die Entwicklung für verschiedene Betriebssysteme im Vergleich zur nativen Codierung der Anwendungen deutlich geringer. Aktuell sind tatsächlich die diversen SPA-Frameworks für den Browser die einzige Technologie, welche vergleichbare Portabilität bei ähnlichem Gesamtaufwand bieten. 

Schematische Darstellung von MAUI
Abbildung 1: Mit Xamarin.Forms kann man aus einer Code-Basis native Apps für alle unterstützten Betriebssysteme erzeugen. MAUI wird der direkte Nachfolger von Xamarin.Forms.

Aber was ist nun dieses geheimnisvolle MAUI und was hat es mit Xamarin zu tun? Diese Frage lässt sich recht simpel beantworten: MAUI ist das neue Xamarin oder, präziser ausgedrückt, dessen direkter Nachfolger, der erstmals mit .NET 6 ausgeliefert wird. 

Genau wie mit Xamarin.Forms lassen sich mit MAUI aus einem Projekt und mit derselben Code-Basis Apps für alle unterstützten Betriebssysteme erstellen. Aus dem Code werden Installationspakete generiert, die dann auf den verschiedenen Plattformen installiert werden können. Offiziell werden von Microsoft Android ab Version 10, iOS, macOS und natürlich Windows, sowohl nativ als auch als UWP-App, unterstützt. Zudem soll es eine Community-Implementierung für Linux-Betriebssysteme sowie eine von Samsung zur Verfügung gestellte Implementierung für deren Tizen-Plattform geben.  Das Projekt- und Build-System wird für alle Plattformen vereinheitlicht und das Erzeugen der Apps wird sowohl über Visual Studio als auch das .NET CLI möglich sein. 

Ein weiteres Feature wird die geteilte Nutzung von Ressourcen wie Bildern oder Übersetzungen sein. Diese sollen von MAUI automatisch in die entsprechenden nativen Formate umgewandelt und in die erstellten Pakete integriert werden können. Außerdem wird man jederzeit auf die APIs des jeweiligen Betriebssystems zugreifen können. Hierzu soll es im Projekt einen speziellen Ordner geben, unter dem man die nativen Code-Hooks ablegt und die dann beim Kompilieren automatisch ins Paket integriert werden.  

Alle im .NET-Standard verfügbaren Funktionalitäten wie zum Beispiel Dependency Injection sollen dabei auch für eine MAUI-App genutzt werden können. Durch die Verwendung von C# und XAML wird auch die Nutzung entsprechender Entwurfsmuster wie dem viel genutzten MVVM-Pattern möglich sein. Neu ist zudem der Support für das Model-View-Update-Pattern, ein von Elm entliehenes Muster, mit dem man einen unidirektionalen Datenfluss analog zu Redux abbilden können soll. Auch Microsofts webbasierte Client-Technologie Blazor soll unterstützt werden. 

Leider wird MAUI erst mit der Einführung von .NET 6 im November 2021 offiziell zur Verfügung stehen. Zudem wurden Teile des Frameworks nach .NET 7 und damit ins Jahr 2022 verschoben. Hier sind vor allem der offizielle Support für Blazor und das MVU-Pattern zu nennen. Da MAUI der offizielle Nachfolger von Xamarin ist, wird dieses auch mit dem Release von .NET 6 noch für ein Jahr unterstützt und dann eingestellt.  

Damit scheint Microsofts Strategie für die Zukunft der UI-Entwicklung mit dem .Net-Framework klar zu sein: MAUI ist der neue „First Class Citizen“, wenn es um die Erstellung von nativen User Interfaces geht.  

Das klingt zunächst alles danach, dass Microsoft eine native Cross Platform-Unterstützung ins .NET-Framework integrieren möchte. Dieser Plan wird jedoch nur aufgehen, wenn MAUI von den Entwicklerinnen und Entwicklern akzeptiert wird. Durch das sehr späte Release und einer Menge hervorragender Open Source-Alternativen wie Uno könnte sich MAUI am Ende eventuell nicht etablieren. Aktuell kann man deshalb nur abwarten und sehen, was die Zukunft bringt. Die Migration von bestehenden WPF-Anwendungen gestaltet sich beispielsweise schwierig, da der ersehnte XAML-Standard, der eine Vereinheitlichung der Elemente und Tags für alle XAML-Dialekte definieren sollte, scheinbar wieder verworfen wurde und sich MAUI und WPF wegen unterschiedlicher Elemente nicht übergangslos austauschen lassen werden.

Wenn die Technologie aber tatsächlich hält, was sie verspricht, die Entwicklerinnen und Entwickler sie breitflächig einsetzen und MAUI so hochklassig wird, wie Microsoft es in Aussicht stellt, könnte hier eine Cross Platform-Revolution unter .NET in den Startlöchern stehen.

SAP Fiori: Eigentümerwechsel einer Verbrauchsstelle mit SAP IS-U, ODATA und SAPUI5 (Teil 3)

Fiori Apps sind aus der modernen SAP-Entwicklung nicht mehr wegzudenken! Sie dienen der Umsetzung anwenderfreundlicher SAP-Oberflächen und bieten mehr Möglichkeiten bzgl. moderner Usability. Die dahinter liegenden Technologien OData und SAPUI5 sollen im Folgenden näher betrachtet werden.
Im ersten Teil der Blogreihe wurde der Use Case eines Eigentümerwechsels im SAP IS-U System vorgestellt. Davon ausgehend wurde in einem ersten Schritt die Erstellung des OData-Services beschrieben, welcher die zur Anforderung passenden Informationen bereitstellt. Darauf aufbauend konnte im zweiten Teil der Blogreihe die umgesetzte UI5-Anwendung vorgestellt werden. Diese nutzte den im ersten Teil beschriebenen OData-Service, um bestimmte Daten aus dem SAP-System zu lesen, zu aktualisieren und neue Datensätze zu erstellen.

Vorbetrachtung des dritten Parts

Im dritten und letzten Teil der Blogbeitragsreihe werden die alte und die neue Welt auf Prozessebene gegenübergestellt und es wird auf das User Centered Design (UCD) mit Hilfe von Fiori eingegangen, welches den Anwender für die Erstellung effizienter Software in den Vordergrund rückt. Doch zuvor soll in einem ersten Schritt auf das SAP-Bypassing eingegangen werden, welches die Art und Weise der Anwendungsentwicklung für SAP-Systeme neu charakterisiert.

SAP-Bypassing mit OData

In der heutigen Zeit besitzen Unternehmen eine Vielzahl verschiedener Systeme zur Bewältigung unterschiedlichster Aufgaben. Im Kontext einer SAP-Systemlandschaft gibt es also Unternehmen, welche verschiedene SAP-Systeme, z.B. für die Ressourcenplanung oder für B2B-, B2C- und B2E-Szenarien, betreiben. Dies bringt verschiedene individuelle oder gesetzliche Anforderungen mit sich, die in einem System oder über eine Systemlandschaft hinweg umzusetzen sind.

Arten von Anforderungen an ein System
Abbildung 1: Arten von Anforderungen an ein System

Im Laufe der Zeit entstehen somit viele verschiedene Anforderungen an ein System. Mit der Umsetzung nehmen die Komplexität und die Verzahnung mit anderen Komponenten im System sowie mit Kommunikationspartnersystemen stetig zu.

Die Anpassungen und Eigenentwicklungen verkomplizieren die Systemabläufe und sind teilweise extreme Performancekiller.

Die Ergebnisse sind unter anderem:

  • Immer längere Ladezeiten
  • Hoher und komplexer Wartungsaufwand und
  • Unzufriedene Nutzer
Nachteile vieler umgesetzter Anforderungen
Abbildung 2: Nachteile vieler umgesetzter Anforderungen

Hier kommt das Bypassing ins Spiel. Dessen Kernziel ist es, das System möglichst nahe am Standard zu belassen und die Umsetzung verschiedener Anforderungen aus dem SAP-System herauszulösen.

Um dies zu realisieren, bietet das SAP-System das Werkzeug der OData-Service-Entwicklung, welches bereits im ersten Teil der Blogreihe gezeigt wurde. Mit Hilfe des Open Data Protokoll (OData) ist es also möglich, eine standardisierte Schnittstelle zum SAP-System bereitzustellen. Die Umsetzung der gestellten Anforderungen kann somit nun vom System getrennt werden und es entsteht eine modulare Architektur, welche kombiniert, ausgetauscht, erweitert oder verändert werden kann.

Auslagerung der Anforderungen aus dem System
Abbildung 3: Auslagerung der Anforderungen aus dem System

Damit entstehen für das System und die Anwendungsentwicklung weitere Vorteile, wie in Abbildung 4 „Vorteile der Komponententrennung“ zu sehen ist.

Vorteile der Komponententrennung
Abbildung 4: Vorteile der Komponententrennung

Der Eigentümerwechsel in der alten Welt

Im SAP-System werden Funktionalitäten in Transaktionen abgebildet, welche über sogenannte Transaktionscodes aufgerufen werden. Das Problem ist jedoch, dass viele Transaktionen mit Funktionalitäten überladen sind. So kann es vorkommen, dass es in einer Transaktion vielleicht zehn Reiter für verschiedene Anforderungen gibt, der Nutzer jedoch nur einen oder zwei Reiter für seine spezielle Aufgabe benötigt und der Rest ungenutzter Ballast ist. Dies führt, gerade bei neuen Mitarbeitern, zu einem Mehraufwand in der Einarbeitung oder schreckt diese auf Grund der Komplexität direkt ab.

Beim Vergleich des Showcases aus dem ersten und zweiten Teil der Blogreihe wurden die einzelnen Schritte zum Ändern eines vorhandenen Geschäftspartners im SAP-System in der folgenden Abbildung dokumentiert. Dabei fällt auf, dass neben der bereits erwähnten Überladung mancher Transaktionen, drei verschiedene Modi erzeugt werden mussten, um die Anforderung umzusetzen.

Prozessschritte Eigentümerwechsel in der alten Welt
Abbildung 5: Prozessschritte Eigentümerwechsel in der alten Welt

Wenn der Nutzer also in seiner Transaktion jedes Mal von vorn beginnen möchte, ist er gezwungen in mehreren Fenstern zu arbeiten und sich lange, nichtssagende Nummern zu merken oder in den Zwischenspeicher zu legen. Dies ist wenig intuitiv und bietet neben einer schlechten User Experience eine große Angriffsfläche für Fehler.

Fortfolgend wird der gleiche Prozess noch einmal betrachtet, jedoch dieses Mal unter Nutzung des SAP-Frontend-Frameworks SAPUI5.

Schöne neue Welt

Mit ihrer neuen Frontend-Technologie legt die SAP ihre eingestaubten Transaktionen für die Nutzer ab und verschlankt diese. So werden die ehemals funktional aufgeblähten Transaktionen in kleinere Anwendungen (UI5-Apps) aufgeteilt. Dabei übernehmen diese Anwendungen verschiedene Teilaufgaben eines ganzheitlichen Szenarios und ermöglichen dem Nutzer eine intuitive und effiziente Arbeit ohne unnötigen Ballast.

Prozessschritte Eigentümerwechsel in der neuen Welt
Abbildung 6: Prozessschritte Eigentümerwechsel in der neuen Welt

Der Nutzer im Vordergrund der Anwendungsentwicklung

Neben der Einführung in die Neuerung der Anwendungsentwicklung auf dem SAP-Stack gibt es noch einen weiteren Teil, den es zu beleuchten gibt. Die User-Experience-Strategie „SAP Fiori“.

Was ist Fiori?

Während SAPUI5 als Web-Framework Entwickler bei der Umsetzung moderner Enterprise-Anwendungen auf dem SAP-Stack unterstützt, legt Fiori die Design-Prinzipien fest.

SAP Fiori Design Guidelines
Abbildung 7: SAP Fiori Design Guidelines – Bildquelle: Fiori Design Guidelines

Anhand der Fiori Design Guidelines erhalten Entwickler ein Nachschlagewerk für die visuelle Umsetzung der Anwendung, um die höchstmögliche, von der SAP vorgesehene Anzahl an Vorteilsmerkmalen für die Anwendung zu erreichen.

Fiori Merkmale
Abbildung 8: Fiori Merkmale – Bildquelle: Fiori Design Guidelines

Fazit

Mit der Kombination aus OData, SAPUI5 und Fiori geht die SAP einen neuen Weg und verabschiedet sich vom Grau ihrer monolithischen ERP-Lösungen.  Durch die Eigenschaften von OData können Anwender nun (z.B. anhand von im Unternehmen verfügbarem Know-how) freier entscheiden, welche Frontend-Technologie sie einsetzen möchten. Gleichzeitig ermöglicht diese Komponententrennung und die Auslagerung von Funktionalitäten aus dem SAP-System eine besser wartbare und austauschbare Systemlandschaft.

Frontend-seitig rückt der eigentliche Anwender in den zentralen Blick der Anwendungsentwicklung. Musste sich ein Anwender vorher in überladene Transaktionen einarbeiten, werden diese Funktionalitäten jetzt in viele kleinere Anwendungen aufgeteilt und für eine bestmögliche Effizienz und Effektivität für den Nutzer entworfen.

Die Entwickler erhalten mit dem SAPUI5 Demo Kit, den Community-Foren und den Fiori Design Guidelines eine umfangreiche und ausführliche Dokumentation an die Hand, welche die Entwicklung moderner Webanwendungen auf dem SAP-Stack deutlich verbessert.