RAP Standard Fiori App erweitern: Neue Felder und eigene Aktionen sauber umsetzen

Viele Unternehmen nutzen in S/4HANA bereits Standard Fiori Apps. In der Praxis reichen die ausgelieferten Funktionen aber oft nicht vollständig aus. Fachbereiche benötigen zusätzliche Felder, eigene Prüfungen oder individuelle Aktionen, die exakt zum internen Prozess passen.

Genau hier wird es spannend: Wie erweitert man eine RAP-basierte Fiori App sauber, ohne den Standard unnötig zu verbiegen?

Warum Standard Fiori Apps erweitert werden

SAP liefert mit Fiori Apps bereits viele moderne Benutzeroberflächen aus. Sie sind rollenbasiert, browserfähig und eng in S/4HANA integriert.

Trotzdem entstehen in Projekten häufig Anforderungen wie:

• zusätzliche Felder auf der Oberfläche
• kundeneigene Statusinformationen
• eigene Buttons und Aktionen
• Validierungen vor dem Speichern
• automatische Feldableitungen
• Prozessschritte, die nicht im Standard enthalten sind

Der entscheidende Punkt ist: Nicht jede Erweiterung sollte direkt als Modifikation oder komplette Eigenentwicklung umgesetzt werden.

Erweiterung statt Neuentwicklung

Eine bestehende Standard App zu erweitern ist oft wirtschaftlicher als eine komplette Neuentwicklung. Die Grundfunktionalität bleibt erhalten, Updates bleiben besser beherrschbar und der Fachbereich arbeitet weiterhin in einer vertrauten Oberfläche.

Typische Erweiterungsmöglichkeiten sind:

Neue Felder ergänzen

Zusätzliche Felder können über CDS Views, Custom Fields oder Erweiterungsstrukturen bereitgestellt werden. Wichtig ist dabei, dass die Daten nicht nur technisch sichtbar sind, sondern auch fachlich sinnvoll in den Prozess eingebunden werden.

Ein Feld auf der Oberfläche allein schafft noch keinen Mehrwert. Es muss klar sein:

• Woher kommt der Wert?
• Wer pflegt ihn?
• Wird er gespeichert oder berechnet?
• Gibt es eine Wertehilfe?
• Muss das Feld in Folgeprozessen berücksichtigt werden?

UI-Anpassungen über Annotationen

In Fiori Elements werden viele Oberflächenelemente über Annotationen gesteuert. Felder, Gruppen, Tabellen, Aktionen und Seitenelemente lassen sich dadurch strukturiert definieren.

Das reduziert individuellen UI5-Code und sorgt für eine konsistente Benutzerführung.

Typische Annotationen betreffen:

• Feldpositionen
• Field Groups
• Line Items
• Identification Bereiche
• Value Helps
• Header Informationen
• Aktionen auf Objekt- oder Tabellenebene

Eigene Aktionen in RAP

Ein großer Vorteil von RAP ist die Möglichkeit, fachliche Aktionen direkt am Business Object zu modellieren.

Beispiele aus der Praxis:

• Auftrag freigeben
• Status zurücksetzen
• Objekt sperren oder entsperren
• technische Prüfung starten
• Prozessschritt abschließen
• Folgebeleg erzeugen

Solche Aktionen werden nicht einfach als Button auf die Oberfläche gesetzt. Sie gehören fachlich in das Verhalten des Business Objects.

Dafür wird im Behavior Definition Layer festgelegt, welche Aktionen verfügbar sind und wie sie technisch verarbeitet werden.

Aktionen nur anzeigen, wenn sie fachlich erlaubt sind

Besonders wichtig ist die dynamische Steuerung der Aktionen. Ein Button sollte nur dann aktiv sein, wenn der aktuelle Objektstatus die Aktion auch erlaubt.

Beispiel:

Ein Auftrag darf nur freigegeben werden, wenn er noch nicht technisch abgeschlossen ist. Eine Stornierung darf nur möglich sein, wenn bestimmte Folgeprozesse noch nicht gestartet wurden.

In RAP wird das typischerweise über Instance Features gelöst. Dadurch kann je Objektinstanz entschieden werden, welche Aktion aktiv, deaktiviert oder ausgeblendet wird.

Das verbessert die Prozessqualität deutlich, weil Fehlbedienungen bereits in der Oberfläche reduziert werden.

Validierungen und Determinations

Neben sichtbaren Feldern und Aktionen spielen auch Validierungen und automatische Ableitungen eine zentrale Rolle.

Validierungen prüfen, ob eine Eingabe fachlich zulässig ist. Determinations ergänzen oder berechnen Werte automatisch.

Typische Beispiele:

• Pflichtfelder abhängig vom Status
• automatische Ableitung von Werk, Kunde oder Verantwortlichem
• Prüfung auf widersprüchliche Eingaben
• Berechnung von Statusinformationen
• Vorbelegung von Feldern aus Stammdaten

Gerade hier zeigt RAP seine Stärke: Die Logik wird nah am Business Object implementiert und nicht verteilt über verschiedene UI-Komponenten.

Wann ist eine Erweiterung sinnvoll?

Eine Erweiterung ist sinnvoll, wenn der SAP-Standard grundsätzlich passt, aber einzelne Felder, Aktionen oder Prüfungen fehlen.

Sie ist besonders geeignet, wenn:

• der bestehende Prozess weitgehend erhalten bleibt
• nur gezielte Zusatzinformationen benötigt werden
• die Standard App weiterhin genutzt werden soll
• Wartbarkeit und Updatefähigkeit wichtig sind
• keine komplett neue Benutzerführung erforderlich ist

Wann ist eine eigene App besser?

Eine eigene Fiori App kann sinnvoller sein, wenn der Prozess stark vom Standard abweicht oder die Oberfläche komplett anders aufgebaut sein muss.

Das gilt zum Beispiel bei:

• komplexen Sonderprozessen
• sehr individuellen Workflows
• mehreren kombinierten Objekten
• stark vereinfachten Benutzeroberflächen für bestimmte Rollen
• Anforderungen, die im Standardmodell nicht sauber abbildbar sind

Die wichtigste Regel lautet: Nicht gegen den Standard entwickeln. Wenn die Erweiterung zu viele Umgehungslösungen benötigt, ist eine eigene App oft die bessere Architekturentscheidung.

Praxisempfehlung

Bei jeder Erweiterung sollte zuerst geprüft werden, ob die Anforderung über den vorgesehenen Erweiterungsmechanismus abbildbar ist.

Ein sinnvoller Ablauf ist:

1. Standardprozess verstehen
2. Erweiterungspunkt identifizieren
3. Datenmodell prüfen
4. Feld oder Aktion fachlich bewerten
5. RAP Behavior sauber erweitern
6. UI über Annotationen integrieren
7. Berechtigungen, Statuslogik und Folgeprozesse testen

So entsteht keine technische Bastellösung, sondern eine stabile Erweiterung mit klarer fachlicher Verantwortung.

Fazit

RAP-basierte Fiori Apps bieten eine moderne Grundlage, um SAP-Prozesse gezielt zu erweitern. Neue Felder, eigene Aktionen, Validierungen und automatische Ableitungen lassen sich sauber im Business Object verankern.

Der größte Mehrwert entsteht, wenn Erweiterungen nicht isoliert betrachtet werden, sondern als Teil des gesamten Prozesses.

Eine gute RAP-Erweiterung ist nicht nur technisch korrekt. Sie macht den Prozess für den Anwender einfacher, sicherer und transparenter.