RAP-Applikation im S/4-Stack
RAP (ABAP RESTful Application Programming Model) als Werkzeug für Erweiterungen, die eng am S/4-Standard-Datenmodell hängen und im Mandanten leben sollen. Wir entwickeln Business Object Erweiterungen, Custom-CDS-basierte Apps und Standard-Erweiterungs-Patterns – versioniert, Lifecycle-fähig, ATC-konform. Wann RAP, wann CAP auf BTP, beantworten wir gemeinsam pro Erweiterung, nicht pauschal.
RAP in einer Sentence
RAP – das ABAP RESTful Application Programming Model – ist das moderne Werkzeug, mit dem Sie im S/4HANA-Mandanten neue Apps und Erweiterungen bauen, ohne den Standard zu deformieren. Kein Custom- Mod, keine Z-Tabelle die Standard-Daten redupliziert: Custom-CDS- Views liegen über Standard-Tabellen, eine Behaviour Definition regelt was lesend, schreibend und mit Draft-Status passiert, Fiori Elements rendert die UI auf Basis der Annotations.
Wann RAP – und wann CAP
Wir treffen die Entscheidung pro Erweiterung. Die Regel ist:
- RAP, wenn die Erweiterung im S/4-Mandanten leben muss: Verlängerung von Business Objects, kundenspezifische Felder im Standard-Beleg, eng am S/4-Datenmodell hängende Workflows, Custom-Apps für Power-User die Standard-Daten edit-fähig brauchen. Lifecycle = Lifecycle vom S/4-Release.
- CAP auf BTP, wenn der Lifecycle eigenständig sein soll: Drittsystem-Integration, AI-/ML-Service-Wrapper, kundenspezifische Microservices, Erweiterungen mit Releases unabhängig vom S/4- Update-Zyklus. Lifecycle = eigene Versionierung.
Diese Trennung ist nicht philosophisch – sie ist Lifecycle-Pragmatik. Eine RAP-App leidet, wenn sie zu nahe an einem Drittsystem hängt (jeder S/4-Upgrade trifft die Schnittstelle). Eine CAP-App leidet, wenn sie zu nahe am S/4-Datenmodell hängt (jede Standard-Tabellen- Erweiterung muss nachgezogen werden).
Aufbau einer typischen RAP-App
Custom Entity oder Custom-CDS
Wir definieren die Datenstruktur – entweder als Custom-CDS-View auf Standard-Tabellen oder als eigene Custom-Entity wenn neue Felder ergänzt werden müssen. Annotation-getrieben, mit klaren Bezugsfeldern zum Standard.
Behaviour Definition
Die Behaviour Definition (BDEF) regelt das Verhalten: welche Aktionen sind erlaubt (read, create, update, delete), welche Validierungen laufen, welche Authorization-Checks gelten, ob Draft-Handling aktiv ist. Hier liegt die Geschäftslogik – versioniert, ATC-prüfbar, mit Unit-Tests abdeckbar.
Behaviour Implementation
Die Implementation (BHV) setzt die Aktionen um – typisch als
ABAP-Klasse mit ~~~determinations, ~~~validations, ~~~actions.
Hier docken wir auch BAdI- und Standard-Logik an, wo sinnvoll.
Service Definition + Binding
Wir definieren den OData V4-Service (welche Entitäten werden exponiert, welche Aktionen sind aussen sichtbar) und binden ihn via OData V4 Service Binding. Damit ist der Service automatisch über die SAP-Gateway-Infrastruktur erreichbar.
Fiori Elements UI
Die UI entsteht weitgehend automatisch aus den UI-Annotations in der Custom-CDS. Listenpage, Object-Page, Filter-Bar, Sortier- Defaults – alles deklarativ. Custom-Logik in der UI bleibt eine bewusste Ausnahme, nicht die Regel.
Standard-Patterns die wir mitbringen
Wir nutzen wiederkehrende RAP-Patterns aus unserer Praxis:
- Custom Field & Logic Pattern – neue Felder auf Standard- Beleg, mit Determinations für abgeleitete Werte
- Custom Workflow Pattern – Genehmigungsworkflows mit RAP- Aktionen + SAP Build Process Automation als Trigger
- Custom Reporting Pattern – Analytical RAP für KPI-Dashboards in Embedded Analytics
- Custom Mass-Edit Pattern – Listen-Editing mit Draft-Handling für Power-User-Szenarien
Diese Patterns werden im abapGit-Repository mit Code-Beispielen, ATC-Regelsätzen und Testfällen gehalten – wir bauen nicht jeden Workflow von Grund auf neu.
Trade-offs ehrlich genannt
RAP hat klare Grenzen:
- Lifecycle ist S/4-gebunden: ein Upgrade kann RAP-Spec- Änderungen mitbringen, die Apps anfassen. CAP wäre dort unabhängiger.
- Cross-System-Integration ist mühsam: RAP lebt im Mandanten, Drittsystem-Calls über destinations sind möglich, aber CAP/BTP ist dort natürlicher.
- UI-Customizing-Grenzen: Fiori Elements deckt ~80 % der Fälle ab. Wenn Sie hochspezifische UX brauchen, geht das mit Freestyle- UI5 – dann verlieren Sie aber den Annotation-Vorteil.
Wer mit uns arbeitet
Dieses Angebot richtet sich an ABAP-Leads und Tech-Architekten, die eine Erweiterungs-Strategie definieren wollen – pro Anforderung die richtige Wahl zwischen RAP und CAP. Eine Architektur-Review (30 Min) auf eine konkrete geplante Erweiterung ist der schnellste Einstieg.
