Die Fachabteilung braucht eine übersichtliche Freigabe-App. Im Backend existieren die Geschäftsdaten bereits, doch im Projektgespräch fallen SAPUI5, Fiori, Fiori Elements und Launchpad beinahe synonym. Gleichzeitig lädt der erste Prototyp langsam, und niemand weiß sicher, ob das Team an der Oberfläche, am Service oder an der Bereitstellung arbeiten sollte.

SAP UI5 und Fiori werden verständlich, wenn man die Entscheidungen nach Schichten trennt. Zuerst kommt die Aufgabe des Nutzers, dann die passende Oberfläche, anschließend der Datenvertrag und schließlich der Betrieb. Wer diese Reihenfolge einhält, kann Eigenentwicklung gezielt einsetzen, statt Standardfunktionen nachzubauen.

Begriffe, Ursprung und Einordnung

SAPUI5 ist das browserbasierte Web-Framework auf Basis von HTML5, CSS3 und JavaScript, SAP Fiori das Designkonzept samt rollenbasierten Apps, und Fiori Elements erzeugt standardisierte Oberflächen zur Laufzeit aus OData-Metadaten und Annotationen. Das Launchpad dient dabei als Einstiegspunkt für Anwendungen, nicht als Ersatz für deren Implementierung.

Die Begriffe beschreiben also keine konkurrierenden Produkte auf derselben Ebene. Ein Team kann eine Anwendung mit SAPUI5 entwickeln, dabei Fiori-Gestaltungsregeln einhalten und für geeignete Seiten Fiori Elements verwenden.

Begriffe rund um SAP UI5 und Fiori

Die Aufwandseinstufungen sind Orientierungshilfen, keine Projektschätzungen. Bei einer Standard-App können beispielsweise Berechtigungen und Integration anspruchsvoller sein als die sichtbare Anpassung.

Baukasten, Bauvorschrift und Fertighaus

Als Analogie hilft ein Bauprojekt: UI5 ist der Baukasten, Fiori die Bauvorschrift mit bewährten Grundrissen. Fiori Elements ähnelt einem Fertighaus, bei dem das Team einen passenden Grundriss wählt und vorgesehene Anpassungsmöglichkeiten nutzt, statt die Statik umzubauen.

Technisch interpretiert Fiori Elements Metadaten, Annotationen und Konfigurationen durch zentral bereitgestellte Views und Controller. Die Dokumentation zu SAP Fiori Elements beschreibt dieses Prinzip und die Möglichkeit gezielter Erweiterungen.

Eine Bestellübersicht mit Filtern und einer Detailansicht passt gut zu solchen Grundrissen. Eine interaktive Spezialvisualisierung mit ungewöhnlichen Bedienabläufen spricht eher für Freestyle-UI5. Mehr Freiheit bedeutet allerdings auch mehr eigene Verantwortung für Interaktion, Tests und Wartung.

Der eigentliche Wandel betrifft die Aufgabe

Laut dem SAP-Rückblick auf die Entwicklung von Fiori erschien die erste Version am 15. Mai 2013 mit vier Benutzerrollen und 25 häufigen Szenarien; ein Jahr und eine Woche später waren bereits mehr als 300 Apps verfügbar. Entscheidend war nicht die Zahl der Oberflächen, sondern die Ausrichtung an Aufgaben statt an technischen Transaktionen.

Für einen Einkäufer heißt das: Er soll offene Bestellungen prüfen können, ohne die interne Struktur des ERP-Systems kennen zu müssen. Das gelingt nur, wenn das Team Rollen bewusst gestaltet. Eine ungepflegte Rollenzuordnung erzeugt eine überladene Kachelsammlung statt eines brauchbaren Arbeitsplatzes.

SAPUI5 ist zudem nicht grundsätzlich auf SAP-Backends beschränkt. Ein großer Teil der zugrunde liegenden Technologie steht als OpenUI5 quelloffen zur Verfügung; der typische Unternehmenseinsatz bleibt dennoch eng mit SAP-Geschäftsprozessen verbunden. Wer die Browserperspektive vertiefen möchte, findet sie in der Erklärung, was eine Web-App ist.

Entscheidungsregel: Nicht zuerst nach dem Framework fragen, sondern danach, welche Ebene das Team selbst verantworten muss.

Braucht es eine vorhandene App, einen standardisierten Seitentyp oder eine eigenständige Interaktion? Davon hängen Entwicklungszeit, benötigte Fähigkeiten und Upgrade-Risiko ab.

So ist eine UI5-App zur Laufzeit aufgebaut

Ein Sachbearbeiter öffnet eine Bestell-App und klickt auf einen Eintrag. Bis die Detaildaten erscheinen, arbeiten Browser, UI5-Laufzeit und Backend zusammen. Die SAP-Dokumentation zur UI-Technologie beschreibt das Grundprinzip: Der Browser lädt die Anwendung, Views verwenden UI5-Bibliotheken, und ein Model beschafft typischerweise Geschäftsdaten aus dem Backend.

Die Abbildung zeigt diese Reihenfolge in vereinfachter Form.

Vom App-Start bis zum Datenbinding

Zunächst lädt der Browser die benötigten Anwendungsressourcen. Die Component bildet den Einstiegspunkt der UI5-Anwendung und verbindet deren technische Bestandteile. Anschließend baut UI5 die Oberfläche aus Controls wie Tabellen, Eingabefeldern und Schaltflächen auf.

Die Aufgaben im Frontend sind klar getrennt:

• View: Definiert Struktur und Darstellung, bei Freestyle-Anwendungen häufig in XML.
• Controller: Behandelt Ereignisse, etwa die Auswahl einer Tabellenzeile oder das Betätigen einer Aktion.
• Model: Stellt Daten bereit und verbindet sie über Bindings mit den Controls.
• manifest.json: Deklariert unter anderem Datenquellen, Modelle, Routing und Abhängigkeiten.

Das Manifest ist damit die zentrale Verdrahtung der Anwendung. Eine Service-Adresse gehört nicht verstreut in verschiedene Ereignisbehandlungen, wenn sie als Datenquelle deklariert werden kann. Ebenso sollte Navigation über das vorgesehene Routing laufen, statt Ansichten bei jedem Klick manuell zusammenzusetzen.

In einer Küchenanalogie sind Controls die Geräte, der Controller beschreibt die Abläufe und das Model hält die Vorratsliste bereit. Das Gateway übernimmt die Rolle des Lieferdienstes. Die Analogie hat eine wichtige Grenze: Geschäftliche Prüfungen und Berechtigungen gehören ins Backend, nicht ausschließlich in den sichtbaren Bedienablauf.

Vom Klick zum ABAP-Backend

Beim Öffnen einer Bestellung ändert die Anwendung beispielsweise die Bindung auf das ausgewählte Geschäftsobjekt. Das OData-Model fordert die benötigten Daten an, in einer klassischen SAP-Architektur über SAP Gateway beim ABAP-Backend. Dort verarbeitet die Geschäftslogik die Anfrage und liest die erforderlichen Daten.

Das Ergebnis gelangt als Antwort zurück zum Model. Über das Binding aktualisiert UI5 die betroffenen Controls. Der Controller muss deshalb nicht jede Feldanzeige selbst setzen.

Das Launchpad ist der umgebende Container und Einstiegspunkt. Nutzer öffnen Apps über die ihnen zugeordneten Einstiege; die Anwendung selbst erscheint nicht technisch innerhalb einer Kachel. Die Backend-Berechtigung muss unabhängig davon verhindern, dass unzulässige Daten abgerufen werden.

Ein ausgeblendeter Einstieg ist keine Zugriffssperre. Die Berechtigung muss auch beim direkten Service-Aufruf gelten.

Besonders kritisch sind Abhängigkeiten zwischen verwendeten UI5-Funktionen, Laufzeitversion und Service-Fähigkeiten. Auch Eingriffe in interne Implementierungen von Standardcontrols erschweren spätere Aktualisierungen.

Plant deshalb Feldnamen, Datentypen, Schlüssel, Fehlermeldungen und Änderungsoperationen als gemeinsamen Service-Vertrag. Wird ein gebundenes Feld ohne Anpassung der Verbraucher umbenannt, kann die Anzeige ausfallen. Service-Design gehört an den Projektanfang, weil spätere Änderungen Frontend, Backend und Tests gleichzeitig betreffen.

So läuft die Entwicklung mit den Fiori Tools ab

Fiori Tools unterstützen die Entwicklung, ersetzen aber keine fachliche Modellierung. Die SAP-Anleitung für Fiori Elements mit OData V4 beschreibt den Ablauf von den Voraussetzungen über Annotationen und App-Erzeugung bis zu erforderlichen Erweiterungen. Als Entwicklungsumgebung kommen SAP Business Application Studio und Visual Studio Code infrage.

Die Übersicht veranschaulicht den Weg von der Vorbereitung bis zur Bereitstellung.

Vom erreichbaren Service zur erzeugten App

1. Voraussetzungen klären. Prüft Backend-Zugriff, Service-Verfügbarkeit und Berechtigungen mit dem tatsächlich vorgesehenen Benutzer. Entscheidet anschließend zwischen Business Application Studio und Visual Studio Code anhand von Unternehmensrichtlinien, Verbindungen und lokalem Testprozess. Ein häufiger Fehler ist der erfolgreiche Test mit einem privilegierten Entwicklerkonto, während dem späteren Fachanwender Zugriffe fehlen.

2. UI-Annotationen vorbereiten. Legt fest, welche Felder als Filter, Tabellenspalten oder Objektinformationen erscheinen sollen und welche Aktionen angeboten werden. Annotationen können im Service oder ergänzend in lokalen Annotationsdateien liegen. Der Grund für die frühe Arbeit ist einfach: Ohne fachlich passende Metadaten erzeugt der Generator zwar ein Projekt, aber noch keine brauchbare Arbeitsoberfläche.

3. Anwendung mit den Fiori Tools erzeugen. Wählt den geeigneten Floorplan, etwa einen List Report mit Object Page, und verbindet ihn mit dem vorgesehenen Service. Der Generator legt die Projektstruktur und Konfiguration an. Prüft danach Datenquelle, Entitäten und Navigation, statt eine funktionierende Vorschau bereits als fachliche Abnahme zu behandeln.

4. Nur bei belegtem Bedarf erweitern. Nutzt zuerst Manifest-Einstellungen und Annotationen. Ergänzt Controller-Erweiterungen oder Custom Actions erst dort, wo das Standardmodell die Anforderung nicht abbildet. Dokumentiert für jede Erweiterung den fachlichen Grund und den verwendeten Erweiterungspunkt.

Standardverhalten nicht nachbauen

Eine typische Sackgasse beginnt mit fehlenden Annotationen. Das Frontend-Team baut Filterleiste, Tabelle und Navigation von Hand, obwohl eigentlich nur die beschreibenden Informationen fehlen. Damit übernimmt es dauerhaft die Pflege von Verhalten, das der Standard bereits bereitstellen könnte.

Fiori Elements ist der bevorzugte Ansatz für passende wiederkehrende Muster. Freestyle-UI5 bleibt sinnvoll, wenn die Interaktion tatsächlich davon abweicht. Eine ungewöhnliche Anforderung sollte jedoch konkret beschrieben werden, beispielsweise als benötigte Drag-and-drop-Interaktion, nicht bloß als Wunsch nach mehr Flexibilität.

Die folgende Videoeinbettung ergänzt den praktischen Einstieg.

Vor der Bereitstellung braucht es mehr als einen erfolgreichen Start. Prüft leere Ergebnisse, fehlerhafte Eingaben, verweigerte Zugriffe und die Navigation zurück zur Liste. Nutzt dafür nachvollziehbare Testdaten statt zufälliger Datensätze aus dem Entwicklungssystem.

Die Freigabeprüfung sollte mindestens diese Punkte enthalten:

• Service-Metadaten geprüft: Schlüssel, Datentypen und benötigte Operationen passen zum Anwendungsfall.
• Annotationen vollständig: Fachlich relevante Filter, Spalten und Detailbereiche sind beschrieben.
• Erweiterungsbedarf dokumentiert: Eigener Code hat einen nachvollziehbaren Zweck und einen Test.
• Bereitstellung geprüft: Zielumgebung, Verbindungen und Berechtigungen funktionieren auch außerhalb der lokalen Vorschau.

Performance und Bereitstellung als häufigster Engpass

Eine langsame Fiori-App ist nicht automatisch ein Problem des Frontend-Codes. Im dokumentierten SAP-Vergleich der Launchpad-Startmodi benötigte der In-Place-Start 15 Requests und etwa 486 KB, der Ex-Place-Start dagegen 51 Requests und rund 4,0 MB. Die folgenden Verhältnisse beziehen sich auf diesen konkreten Vergleich, nicht auf jede Fiori-Anwendung.

Initialer Netzwerkaufwand im Launchpad-Vergleich

Außerhalb des vorhandenen Launchpad-Kontexts müssen zusätzliche Ressourcen und Laufzeitkontexte geladen werden. Bei hoher Latenz oder begrenzter Bandbreite kann das den Start spürbar verzögern. Aus Request-Anzahl und Datenvolumen lässt sich allerdings keine allgemeingültige Ladezeit ableiten.

Die zusätzliche Visualisierung stellt Startvarianten gegenüber; ihre Zeitangaben sind keine belastbaren Zielwerte für das eigene System.

Erst messen, dann eingreifen

Die SAP-Empfehlungen zur End-to-End-Optimierung beziehen Netzwerk, Browser, Ressourcenbereitstellung, Launchpad und Backend ausdrücklich ein. Dazu gehören HTTP-Kompression, Bootstrap- beziehungsweise CDN-Platzierung, OData-Verarbeitung und CDS-Views bei großen Datenmengen.

Für eine belastbare Diagnose gilt diese Reihenfolge:

1. Vollständigen Performance Trace erstellen. Zeichnet den betroffenen Ablauf vom Start bis zur nutzbaren Anzeige auf.
2. Zeitanteile sichtbar machen. Verwendet sap-statistics=true, um Frontend-, Backend- und Netzwerkanteile in Millisekunden auszuwerten, soweit die jeweilige Antwort diese Statistik bereitstellt.
3. Engpassklasse isolieren. Trennt Ressourcenladen, Service-Verarbeitung, Übertragung und Rendering.
4. Gezielt ändern und nachmessen. Verändert nicht gleichzeitig Service, Oberfläche und Hosting, sonst bleibt die Ursache unklar.

Eine langsame CDS-Abfrage braucht eine andere Maßnahme als wiederholte Bibliotheksdownloads. Ebenso sollte das Team die Parallelisierung und Bündelung von OData-Anfragen prüfen, statt Requests ungeprüft zusammenzufassen. Eine systematische Performance-Optimierung beginnt deshalb mit reproduzierbaren Messbedingungen.

Betriebspflege gehört zur Diagnose

Haltet Kernel, Unified Rendering und SAPUI5 auf dem höchsten verfügbaren Patchstand der eingesetzten ABAP- und SAP_UI-Version. Lasst den SAPUI5 Application Index mit /UI5/APP_INDEX_CALCULATE als Hintergrundjob berechnen, damit seine Ermittlung nicht unnötig den interaktiven Start belastet.

Testet das Launchpad nicht ausschließlich im privaten Browsermodus, weil dort die vorgesehene Nutzung des statischen Caches eingeschränkt ist. Erfasst einen kalten Start und einen wiederholten Aufruf getrennt.

Benchmark-Minimum: Request-Anzahl, übertragenes Volumen, Netzwerk-Roundtrips und First-Load-Zeit separat dokumentieren.

Ergänzt Benutzerrolle, Datenumfang und Netzwerkbedingungen. Erst mit diesen Angaben kann ein anderes Team die Messung sinnvoll wiederholen.

Integrationsszenarien und Einsatz in verteilten Teams

Die Ausgangslage entscheidet über den passenden Ansatz. Ein vorhandener Standardprozess verlangt andere Arbeit als eine neue Fachanwendung oder eine Erweiterung mit unabhängigem Betrieb. Nicht jede neue Oberfläche rechtfertigt ein neues Entwicklungsprojekt.

Einsatzszenarien und passender Ansatz

Eine Anwendung außerhalb des Kernsystems ist besonders dann eine prüfenswerte Option, wenn sie einen eigenen Lebenszyklus benötigt. Die Entscheidung für SAP BTP sollte aber Bereitstellung, Identität, Verbindungen und Betriebsverantwortung einschließen. Der Hosting-Ort allein löst keine Integrationsfrage.

Bei einem B2B-Kundenportal mit ERP-Anbindung kommt zusätzlich eine andere Nutzergruppe hinzu. Externe Kunden brauchen andere Berechtigungsgrenzen und Abläufe als interne Sachbearbeiter, selbst wenn beide auf denselben Geschäftsobjekten arbeiten.

Eigenes Team oder gezielte Unterstützung

Entscheidend sind vorhandene UI5-Fähigkeiten, verfügbare Senior-Kapazität, Betriebsverantwortung und Zeitdruck. Ein internes Team ist gut aufgestellt, wenn es fachliche Entscheidungen und technische Wartung dauerhaft übernehmen kann. Externe Unterstützung eignet sich besonders für abgegrenzte Freestyle-Module, Architekturprüfungen oder messbare Performance-Arbeit.

Vergebt dabei kein unscharfes Paket namens Frontend fertigstellen. Beschreibt stattdessen Service-Grenzen, erwartetes Verhalten, Testumfang und Abnahmekriterien. So kann ein externer Entwickler als Teil des Teams arbeiten, ohne dass fachliches Wissen dauerhaft außerhalb der Organisation bleibt.

Auch ein gut ausgestatteter Remote-Arbeitsplatz ersetzt diese Vereinbarungen nicht.

Rollout ist mehr als Bereitstellung

Bei EWE NETZ wurden 2025 mehr als 2.000 Nutzer auf SAP Fiori aktualisiert, wie die Deutschsprachige SAP-Anwendergruppe im Projektbericht angibt. Die Größenordnung ist ein konkretes Rollout-Beispiel, aber kein Beleg für eine allgemeine Implementierungsdauer oder einen bestimmten Schulungsaufwand.

Für den eigenen Rollout sollten Projektleiter Schulung, Rollenpflege und Performance als eigenständige Arbeitspakete planen. Testet mit repräsentativen Fachanwendern, ob sie ihre Aufgaben finden und abschließen können. Eine technisch erreichbare App ist noch kein erfolgreich eingeführter Arbeitsplatz.

Das Übergabedokument für verteilte Teams braucht folgende Bestandteile:

• Service-Verträge: Entitäten, Operationen, Fehlerfälle und verantwortliche Ansprechpartner.
• Annotationen: Ablageort, fachliche Bedeutung und Zuständigkeit für Änderungen.
• Testdaten: Reproduzierbare Fälle einschließlich leerer Ergebnisse und abgelehnter Aktionen.
• Berechtigungsmatrix: Erlaubte Aufgaben und Datenzugriffe je Rolle.

Schneidet Remote-Arbeit an klaren Schnittstellen statt nur an Bildschirmseiten. Benennt für jedes Paket Verantwortliche für Implementierung, Prüfung und Betrieb. Vertragliche Haftungsfragen müssen dazu ausdrücklich geregelt werden, sie ergeben sich nicht automatisch aus der technischen Aufteilung.

Migration oder Neuentwicklung vor dem Pilot entscheiden

Eine gewachsene UI5-Anwendung besteht selten aus einem einheitlichen Block. Typisch ist ein Gemisch: Listen und Formulare, die Fiori Elements weitgehend selbst erzeugen könnte, daneben Freestyle-Dialoge mit eigener Interaktionslogik und OData-Services unterschiedlicher Reife. Die eigentliche Frage vor einem Pilot lautet daher nicht "alt oder neu", sondern welche produktiven Teile erhalten bleiben, welche standardisiert werden können und welche Abhängigkeiten eine Änderung riskant machen. Dass das Frontend älter geworden ist, rechtfertigt für sich allein keine komplette Neuentwicklung.

Im SAP Fiori Development Newsletter, Ausgabe 43 beschreibt SAP agentische Werkzeuge, MCP-Integration und KI-gestützte Tests sowie Werkzeuge zur Umwandlung bestehender JavaScript-UI5-Anwendungen in TypeScript; die Weiterentwicklung von SAPUI5 2.x wurde zugleich zunächst zurückgestellt, um die Ausrichtung auf KI-gestützte Entwicklung zu prüfen.

Für die eigene Planung ist das ein Anlass zur Bestandsaufnahme. Bewertet, ob das Team einzelne Module in Fiori Elements überführen kann, während besondere Interaktionen als Freestyle bestehen bleiben. Prüft OData-V2-Abhängigkeiten gesondert, bevor ihr eine Umstellung auf OData V4 einplant.

Kriterien statt Versionsreflex

Kriterien für Migration oder Neuentwicklung

Die Tabelle strukturiert die Prüfung, ersetzt aber keine Einzelbewertung. Fehlende Tests sprechen beispielsweise nicht bedingungslos für einen Neubau: Ohne dokumentiertes Verhalten kann das Team auch bei einer Neuentwicklung wichtige Sonderfälle übersehen, weil es nie erfahren hat, welche es gab.

Fehlende Testabdeckung ist zuerst ein Erkenntnisproblem. Vor dem Ersetzen muss klar sein, welches Verhalten erhalten bleiben soll.

Auch häufige Anforderungsänderungen rechtfertigen einen Neubau nur dann, wenn die bestehende Struktur diese Änderungen tatsächlich behindert. Ein stabiles Modul mit ungewöhnlicher Interaktion kann trotz seines Alters wirtschaftlich weiterbetrieben werden. Solche Module bleiben bewusst Freestyle, während die umliegenden standardisierten Listen und Formulare in Fiori Elements überführt werden.

Ein Pilot mit überprüfbarem Ergebnis

1. Code-Inventar erstellen. Erfasst V2-Abhängigkeiten, Erweiterungen, kundenspezifische Logik und Testlage. Trennt fachlich notwendige Sonderfälle von historisch gewachsenen Umwegen.

2. Pilotmodul begrenzen. Wählt einen fachlich abgeschlossenen Ablauf mit klaren Service-Grenzen. Eine reine Anzeigeseite reicht nicht, wenn die schwierigen Risiken in Änderungen, Validierungen oder Berechtigungen liegen.

3. Vorher und nachher messen. Dokumentiert Aufwand pro Maske, Fehlerquote und Performance unter vergleichbaren Bedingungen. Definiert vorher, was als Fehler zählt und welche Tätigkeiten in die Aufwandserfassung eingehen.

4. Über den restlichen Bestand entscheiden. Übertragt die Ergebnisse nur auf vergleichbare Module. Plant für abweichende Sonderbereiche eigene Bewertungen und haltet einen Rückweg für den Pilotbetrieb bereit.

Bewertet die eigene Anwendung anhand der Kriterien, benennt ein abgegrenztes Pilotmodul und legt Verantwortliche für Backend, Oberfläche und Abnahme fest. Fehlt Senior-Kapazität, ergänzt sie gezielt für die riskanten Entscheidungen, statt die gesamte Modernisierung als unbestimmtes Gesamtpaket auszulagern.

PandaNerds stellt geprüfte Senior-Entwickler bereit, die sich als feste Teammitglieder in bestehende Entwicklungsprozesse integrieren. Besprecht mit PandaNerds euren Stack, die kritischen Service-Abhängigkeiten und ein konkretes Pilotmodul, um passende technische Unterstützung einzuplanen.