Die Entwicklung mit dem RESTful Application Programming Model (RAP) gehört mittlerweile zum Standard moderner SAP-Entwicklung. Viele Projekte starten mit großen Erwartungen: weniger Boilerplate-Code, Fiori-Anwendungen nahezu automatisch und eine saubere, serviceorientierte Architektur.

Die Realität in Projekten sieht allerdings häufig anders aus.

Nach mehreren RAP-Projekten im Umfeld von Logistik, Instandhaltung und individuellen Geschäftsanwendungen sind mir immer wieder dieselben Probleme begegnet. Viele davon werden in Tutorials oder Demos kaum behandelt, können in echten Projekten jedoch erheblichen Mehraufwand verursachen.

Hier sind zehn typische RAP-Fallen – und wie man sie vermeiden kann.

1. Draft-Verhalten wird unterschätzt

Draft klingt zunächst einfach: Benutzer können Änderungen speichern, ohne diese sofort zu aktivieren.

In der Praxis entstehen jedoch schnell Probleme:

• Fehlerhafte Navigation aufgrund fehlender IsActiveEntity
• Unerwartete Aktivierungen
• Inkonsistente Datenzustände
• Schwierigkeiten bei Side Effects und Determinations

Empfehlung

Draft nur einsetzen, wenn der fachliche Prozess tatsächlich Entwürfe benötigt.

Für einfache Stammdatenanwendungen oder kleine Pflege-Apps ist häufig eine Non-Draft-Anwendung die deutlich einfachere und wartungsfreundlichere Lösung.

2. Zu viel Logik in Determinations

Determinations sind extrem praktisch. Dadurch entsteht jedoch häufig die Versuchung, nahezu sämtliche Businesslogik dort zu implementieren.

Typische Folgen:

• unnötige Datenbankzugriffe
• schwer nachvollziehbares Verhalten
• Kaskaden von Determinations
• Performanceprobleme

Empfehlung

Determinations ausschließlich für klar definierte Ableitungen verwenden.

Komplexe Geschäftsprozesse gehören meist in Actions oder separate Serviceklassen.

3. Side Effects werden vergessen

Ein Klassiker.

Im Backend werden Felder korrekt ermittelt, im Frontend sieht der Benutzer jedoch keine Änderung.

Das Ergebnis:

„Die Anwendung funktioniert nicht.“

Obwohl die Daten korrekt berechnet wurden.

Empfehlung

Bereits bei der Entwicklung überlegen:

• Welche Felder ändern andere Felder?
• Welche Informationen müssen unmittelbar aktualisiert werden?

Die passende Definition von Common.SideEffects sollte frühzeitig erfolgen.

4. Businesslogik landet im Frontend

Viele Projekte blenden Aktionen oder Felder direkt in UI5 oder Fiori Extensions aus.

Das funktioniert zunächst – ist jedoch gefährlich.

Jeder OData-Aufruf kann die Aktion weiterhin technisch ausführen.

Empfehlung

Die eigentliche Steuerung gehört immer ins Backend.

Nutze:

• get_instance_features
• authorization checks
• Validierungen

Das Frontend sollte lediglich die Darstellung übernehmen.

5. BAPIs und RAP arbeiten nicht automatisch zusammen

Gerade bei älteren SAP-Objekten führt kaum ein Weg an klassischen BAPIs vorbei.

Typische Probleme:

• doppelte Änderungen
• unerwartete Commits
• mehrfach ausgeführte Logik
• Inkonsistente Partner- oder Statusdaten

Ich habe Projekte gesehen, bei denen dieselbe Änderung aufgrund mehrfacher Save-Zyklen mehrfach ausgeführt wurde.

Empfehlung

Die Verarbeitung genau analysieren:

• Wann erfolgt das Save?
• Welche Methoden werden mehrfach aufgerufen?
• Wer führt den Commit durch?

Gerade bei unmanaged Save-Szenarien ist ein tiefes Verständnis des RAP-Lifecycles notwendig.

6. Virtuelle Elemente werden zu komplex

Virtuelle Elemente sind hervorragend geeignet, um berechnete Informationen bereitzustellen.

In vielen Projekten werden dort jedoch umfangreiche Datenbankabfragen durchgeführt.

Das führt häufig zu:

• langsamen Listen
• hohen Datenbanklasten
• schlechter Skalierbarkeit

Empfehlung

Virtuelle Elemente möglichst leichtgewichtig halten.

Falls größere Datenmengen benötigt werden:

• Voraggregation
• zusätzliche CDS-Views
• Caching-Mechanismen

verwenden.

7. CDS-Modelle werden unnötig kompliziert

Viele Entwickler versuchen, sämtliche Informationen in einer einzigen CDS-View abzubilden.

Das Ergebnis:

• riesige Join-Konstrukte
• schlechte Lesbarkeit
• schwierige Wartung
• Performanceprobleme

Empfehlung

Lieber mehrere kleinere Views aufbauen:

• Interface Views
• Consumption Views
• klare Verantwortlichkeiten

Ein sauberes Modell zahlt sich langfristig aus.

8. Berechtigungen werden zu spät berücksichtigt

Häufig wird zunächst die Fachlogik umgesetzt.

Die Berechtigungen folgen erst kurz vor dem Go-Live.

Dann beginnt häufig die eigentliche Arbeit.

Empfehlung

Berechtigungen von Beginn an mitdenken:

• Wer darf lesen?
• Wer darf ändern?
• Wer darf Aktionen ausführen?

Nachträgliche Anpassungen sind häufig deutlich aufwendiger.

9. RAP ersetzt nicht automatisch gutes Design

RAP löst viele technische Probleme.

Es löst jedoch keine fachlichen oder architektonischen Probleme.

Schlechte Prozesse bleiben auch mit RAP schlechte Prozesse.

Empfehlung

Vor der Implementierung immer hinterfragen:

• Ist der Prozess sinnvoll?
• Ist die Datenstruktur sauber?
• Ist die Verantwortlichkeit klar definiert?

Technologie ersetzt keine Architektur.

10. RAP wird eingesetzt, obwohl klassisches ABAP ausreichend wäreNicht jede Anwendung benötigt RAP.

Manche Projekte bestehen lediglich aus:

• kleinen Reports
• einfachen Pflegeprogrammen
• Hintergrundverarbeitungen
• einmaligen Hilfswerkzeugen

Hier erzeugt RAP teilweise mehr Komplexität als Nutzen.

Empfehlung

Technologie immer anhand des Anwendungsfalls auswählen.

RAP ist ein hervorragendes Werkzeug – aber nicht die Lösung für jedes Problem.

Fazit

RAP ist aus der modernen SAP-Entwicklung kaum noch wegzudenken und bietet enorme Vorteile:

• saubere Servicearchitektur
• standardisierte Fiori-Integration
• klare Trennung von Verantwortlichkeiten
• Zukunftssicherheit im S/4HANA-Umfeld

Gleichzeitig bringt RAP neue Herausforderungen mit sich.

Viele Probleme entstehen nicht durch das Framework selbst, sondern durch fehlende Projekterfahrung und falsche Architekturentscheidungen.

Wer die typischen Stolperfallen kennt, kann Projekte deutlich effizienter umsetzen und spätere Probleme vermeiden.

Am Ende gilt – wie so oft in der Softwareentwicklung:

Nicht das Framework entscheidet über den Projekterfolg, sondern die Art und Weise, wie es eingesetzt wird.

Welche RAP-Herausforderungen sind euch in Projekten begegnet?

Ich freue mich auf den Austausch und weitere Erfahrungen aus der Praxis.