Fiori Elements oder freestyle SAPUI5 – was passt wann?

In SAP-Projekten fällt die Entscheidung für Fiori Elements oder eine freestyle SAPUI5-Anwendung oft zu früh. Manchmal heißt es: „Mit Fiori Elements sind wir schneller.“ In anderen Fällen steht bereits fest, dass die Oberfläche individuell werden soll und deshalb nur freestyle infrage komme.

Beide Aussagen können richtig sein. Sie reichen für eine Architekturentscheidung aber nicht aus.

Der entscheidende Punkt ist nicht, welches Frontend-Modell mehr Möglichkeiten bietet. Entscheidend ist, wie gut der fachliche Prozess in ein standardisiertes Fiori-Muster passt. Eine objektzentrierte Anwendung mit Liste, Filterung, Detailseite und klaren Aktionen braucht selten ein vollständig individuelles Frontend. Ein stark geführter Arbeitsablauf mit visueller Planung, vielen Zwischenzuständen oder ungewöhnlichen Interaktionen kann dagegen schnell an die Grenzen eines Standard-Floorplans kommen.

Meine Empfehlung lautet deshalb: Fiori Elements sollte bei neuen, daten- und objektzentrierten Anwendungen die erste ernsthafte Option sein. Freestyle SAPUI5 ist sinnvoll, wenn der Prozess nachweisbar mehr Freiheit benötigt – nicht nur, weil individuelle Entwicklung vertrauter wirkt.

Fiori Elements und SAPUI5 sind keine Gegensätze

Fiori Elements ist selbst ein Framework auf Basis von SAPUI5. Die eigentliche Entscheidung lautet daher nicht „Fiori Elements oder SAPUI5“, sondern:

• Nutzt die Anwendung standardisierte Floorplans und Metadaten von Fiori Elements?
• Werden diese gezielt durch Erweiterungen oder Building Blocks ergänzt?
• Oder wird die Oberfläche weitgehend selbst mit SAPUI5 Views, Controllern, Controls und eigener Navigationslogik entwickelt?

Gerade bei Fiori Elements für OData V4 ist die Grenze weniger hart als früher. Neben Standard-Floorplans stehen Building Blocks, Custom Sections und Custom Pages zur Verfügung. Dadurch entsteht eine sinnvolle Zwischenstufe: Eine Anwendung kann die Vorteile des Frameworks nutzen und trotzdem an ausgewählten Stellen individuelle UI-Logik enthalten.

Das ist in vielen Projekten besser als die vorschnelle Entscheidung für eine vollständig freie SAPUI5-Anwendung.

Was Fiori Elements gut abdeckt

Fiori Elements spielt seine Stärken aus, wenn eine Anwendung mit etablierten SAP-Fiori-Mustern beschrieben werden kann. Typische Beispiele sind:

• Geschäftsdaten suchen, filtern und als Liste darstellen
• ein Geschäftsobjekt anzeigen oder bearbeiten
• Positionen oder Unterobjekte verwalten
• Aktionen auf einzelnen oder mehreren Objekten ausführen
• analytische Informationen mit Tabellen und Diagrammen kombinieren
• Entwürfe, Validierungen und transaktionale Bearbeitung abbilden

Dafür stehen unter anderem List Report, Worklist, Analytical List Page und Object Page zur Verfügung. Metadaten und Annotationen beschreiben Felder, Tabellen, Filter, Aktionen und Facetten. Das Frontend muss diese Strukturen nicht für jede Anwendung neu implementieren.

Das spart nicht nur initialen Entwicklungsaufwand. Der größere Vorteil zeigt sich oft später: Viele grundlegende Verhaltensweisen bleiben konsistent. Dazu gehören beispielsweise Tabellenfunktionen, Variant Management, Message Handling, Navigation und die responsive Darstellung. In einer freestyle App trägt das Entwicklungsteam für diese Themen deutlich mehr Verantwortung.

Fiori Elements passt besonders gut, wenn das Backend bereits sauber modelliert ist. Im ABAP-Umfeld ist die Kombination mit dem RESTful Application Programming Model (RAP), CDS Views, Behavior Definitions und OData V4 naheliegend. Die Oberfläche wird dann nicht zum Ort für fachliche Regeln, sondern konsumiert ein fachlich aussagekräftiges Geschäftsobjekt.

Genau hier liegt aber auch eine Voraussetzung: Ein schwaches Daten- und Servicemodell wird durch Fiori Elements nicht automatisch gut. Wenn Entitäten, Beziehungen, Aktionen oder Statusübergänge unsauber modelliert sind, landet die Komplexität später in Annotationen und Frontend-Erweiterungen.

Wann freestyle SAPUI5 die bessere Wahl ist

Freestyle SAPUI5 bietet maximale Kontrolle über Aufbau, Navigation und Interaktion. Diese Freiheit ist sinnvoll, wenn sie fachlich gebraucht wird.

Typische Fälle sind:

• grafische Planung oder Disposition mit Drag-and-drop
• Karten-, Kalender-, Timeline- oder Canvas-basierte Oberflächen
• stark geführte Abläufe mit mehreren voneinander abhängigen Schritten
• komplexe lokale UI-Zustände und Interaktionen vor der Persistierung
• besondere Visualisierungen oder Bedienkonzepte, die kein passender Floorplan abdeckt
• Anwendungen, deren Hauptaufgabe nicht das Anzeigen und Bearbeiten klassischer Geschäftsobjekte ist

Ein konstruiertes Beispiel wäre eine operative Plantafel, auf der Aufträge per Drag-and-drop Ressourcen und Zeitfenstern zugeordnet werden. Hier ist die Interaktion selbst ein wesentlicher Teil des Prozesses. Eine List Report/Object Page-Kombination könnte die Daten darstellen, aber nicht unbedingt den effizientesten Arbeitsablauf ermöglichen.

Freestyle bedeutet allerdings mehr als ein individuelles Layout. Das Team übernimmt zusätzliche Verantwortung für:

• View- und Controller-Struktur
• Routing und Navigation
• State Management
• Busy- und Message Handling
• responsive Darstellung
• Barrierefreiheit und Tastaturbedienung
• konsistente Verwendung der Fiori Design Guidelines
• Tests und Verhalten bei UI5-Upgrades

Diese Kosten entstehen nicht nur während der ersten Implementierung. Jede Sonderlogik muss später verstanden, getestet und weiterentwickelt werden. Deshalb sollte „Wir können dann alles selbst gestalten“ nicht das Hauptargument sein. Freiheit ist nur dann ein Vorteil, wenn die Anforderung sie tatsächlich benötigt.

Die oft bessere Zwischenlösung

Zwischen einem unveränderten Standard-Floorplan und einer vollständigen freestyle App liegt ein großer Gestaltungsspielraum.

Fiori Elements für OData V4 unterstützt wiederverwendbare Building Blocks und individuelle Erweiterungen. Eine Object Page kann beispielsweise um eine Custom Section ergänzt werden. Eine Custom Page kann Tabellen, Formulare oder Filterleisten als Fiori-Elements-Bausteine verwenden und zusätzlich eigenen SAPUI5-Code enthalten.

Damit lässt sich eine Anwendung stufenweise aufbauen:

1. Standard-Floorplan und Standardverhalten verwenden.
2. Fachliche Unterschiede möglichst über Datenmodell, Behavior und Annotationen ausdrücken.
3. Fehlende UI-Funktionen mit freigegebenen Erweiterungspunkten ergänzen.
4. Custom Sections oder Custom Pages einsetzen, wenn einzelne Bereiche individueller werden müssen.
5. Erst dann eine vollständige freestyle App wählen, wenn der Gesamtprozess nicht mehr sinnvoll in dieses Modell passt.

Diese Reihenfolge verhindert zwei typische Extreme: ein überladenes Fiori-Elements-Projekt mit zu vielen fragilen Eingriffen und eine freestyle App, die große Teile eines Standard-Floorplans teuer nachbaut.

Vergleich für die Architekturentscheidung

Kriterium	Fiori Elements	Erweiterter/hybrider Ansatz	Freestyle SAPUI5
Passender Anwendungstyp	daten- und objektzentriert	Standardprozess mit einzelnen Sonderbereichen	stark individueller oder interaktiver Prozess
UI-Aufwand	gering bis mittel	mittel	mittel bis hoch
Gestaltungsfreiheit	durch Floorplan begrenzt	gezielt erweiterbar	sehr hoch
UX-Konsistenz	weitgehend durch Framework	hoch, wenn Erweiterungen sauber bleiben	Verantwortung des Teams
Wartungsaufwand	meist geringer	abhängig von Art und Zahl der Erweiterungen	meist höher
Backend-Anforderungen	gutes Metadaten- und Servicemodell	gutes Modell plus klare Erweiterungsgrenzen	ebenfalls saubere Services, UI kann aber freier konsumieren
Geeignet für RAP/OData V4	sehr gut	sehr gut	möglich, aber mehr Frontendlogik
Hauptrisiko	Anforderungen werden in unpassenden Floorplan gezwungen	schleichende Ansammlung von Sonderlösungen	unnötiger Eigenbau von Standardverhalten

Die Angaben sind bewusst keine absolute Bewertung. Eine kleine freestyle App kann überschaubar sein. Ein schlecht geschnittenes Fiori-Elements-Projekt kann dagegen erheblichen Aufwand verursachen. Entscheidend sind Prozess, Version, Team und geplanter Lebenszyklus.

Sieben Fragen vor der Entscheidung

Ich würde die Technologieentscheidung nicht mit einem Komponentenvergleich beginnen, sondern mit folgenden Fragen.

1. Gibt es bereits eine passende SAP-Standard-App?

Bevor eine neue Anwendung geplant wird, sollte geprüft werden, ob eine Standard-Fiori-App den Prozess bereits abdeckt und erweitert werden kann. Eine Eigenentwicklung ist nicht automatisch besser, nur weil sie technisch möglich ist.

2. Welcher Floorplan passt zur Hauptaufgabe?

Sucht der Benutzer Objekte in einer Liste? Bearbeitet er ein einzelnes Geschäftsobjekt? Benötigt er eine analytische Übersicht? Wenn sich die Kernaufgabe klar einem Floorplan zuordnen lässt, spricht viel für Fiori Elements.

3. Sind die Sonderanforderungen fachlich notwendig?

„Die Tabelle soll anders aussehen“ ist noch kein ausreichender Grund für freestyle. Wichtiger ist, ob eine Abweichung den Prozess wirklich verständlicher oder schneller macht. Viele Wünsche lassen sich über Annotationen, Aktionen, Building Blocks oder Custom Sections umsetzen.

4. Wie komplex ist der UI-Zustand?

Je mehr lokale Zustände, parallele Bearbeitungsschritte und visuelle Abhängigkeiten eine Oberfläche verwalten muss, desto eher kann freestyle sinnvoll werden. Ein klassisches Geschäftsobjekt mit Draft Handling ist dagegen oft gut in Fiori Elements aufgehoben.

5. Wo liegt die fachliche Logik?

Validierungen, Berechnungen und Statuswechsel gehören grundsätzlich in eine belastbare Backend- oder Service-Schicht. Wenn eine Entscheidung für freestyle hauptsächlich damit begründet wird, dass fachliche Logik einfacher im Controller implementiert werden könne, ist das ein Warnsignal.

6. Welche Plattform- und Versionsgrenzen gelten?

OData V2 und OData V4 bieten in Fiori Elements nicht denselben Funktionsumfang. Auch die SAPUI5-Version des Zielsystems beeinflusst verfügbare Floorplans, Building Blocks und Erweiterungsmöglichkeiten. Die Entscheidung muss deshalb gegen die konkrete Systemlandschaft geprüft werden – nicht nur gegen die aktuelle Online-Dokumentation.

7. Wer wartet die Anwendung in drei Jahren?

Eine individuelle Oberfläche kann heute schnell gebaut sein und später teuer werden. Teamkenntnisse, Teststrategie, Releasezyklen und Betriebsverantwortung gehören deshalb von Anfang an in die Bewertung.

Drei typische Fehlentscheidungen

Fiori Elements nur wegen der Entwicklungsgeschwindigkeit wählen

Ein schneller Start hilft wenig, wenn der Prozess nicht zum Floorplan passt. Wer immer mehr Sonderfälle über Extensions abbildet, kann am Ende ein schwer verständliches Hybridprojekt erhalten. Der Standard sollte den größten Teil der Anwendung wirklich tragen.

Freestyle wählen, weil das Team es gewohnt ist

Vertrautheit ist ein legitimer Projektfaktor, aber keine ausreichende Architekturbegründung. Wenn eine App im Wesentlichen aus Liste, Filtern, Detailseite und Standardaktionen besteht, sollte das Team zumindest prüfen, wie viel eigenen Code Fiori Elements vermeiden würde.

Fachliche Probleme im Frontend lösen

Weder Fiori Elements noch freestyle kompensieren ein unklares Geschäftsobjekt. Fehlen eindeutige Statusübergänge, Berechtigungen oder transaktionale Regeln, wird auch die Oberfläche uneindeutig. Die UI-Entscheidung sollte deshalb erst nach einer belastbaren fachlichen und technischen Modellierung fallen.

Meine pragmatische Empfehlung

Für neue Anwendungen im S/4HANA- und RAP-Umfeld würde ich mit Fiori Elements für OData V4 beginnen, sofern die Zielplattform dies unterstützt und der Prozess zu einem Floorplan passt. Das gilt besonders für objektzentrierte Anwendungen mit Listen, Detailseiten, Aktionen und transaktionaler Bearbeitung.

Reicht der Standard nicht vollständig, würde ich nicht sofort auf freestyle wechseln. Zuerst sollte geprüft werden, ob Annotationen, Erweiterungspunkte, Building Blocks, Custom Sections oder eine Custom Page die Abweichung sauber abbilden können.

Freestyle SAPUI5 bleibt die richtige Wahl für Anwendungen, deren Nutzen wesentlich aus einer individuellen Interaktion oder einem besonderen Arbeitsablauf entsteht. Dann sollte die zusätzliche Freiheit aber bewusst bezahlt werden: mit einer klaren Frontend-Architektur, UX-Verantwortung, Tests und einer langfristigen Wartungsstrategie.

Die beste Lösung ist nicht die mit dem geringsten initialen Code und auch nicht die mit der größten Freiheit. Es ist die Lösung, die den fachlichen Prozess sauber trägt, im Projektteam beherrschbar bleibt und sich später noch wirtschaftlich ändern lässt.

Kurzcheck

Fiori Elements bevorzugen, wenn:

• ein Standard-Floorplan den Kernprozess abbildet,
• die Anwendung daten- oder objektzentriert ist,
• RAP oder ein sauberer OData-Service die Fachlichkeit bereitstellt,
• Konsistenz und Wartbarkeit wichtiger als individuelles UI-Verhalten sind.

Einen hybriden Ansatz prüfen, wenn:

• der Standard für den größten Teil der Anwendung passt,
• nur einzelne Abschnitte oder Seiten individuell werden müssen,
• Building Blocks und freigegebene Erweiterungspunkte die Lücke schließen können.

Freestyle SAPUI5 wählen, wenn:

• die Interaktion selbst den Prozess prägt,
• kein Floorplan die Hauptaufgabe sinnvoll unterstützt,
• das Team die zusätzliche Verantwortung für Architektur, UX, Tests und Wartung übernehmen kann.