Individualentwicklung auf der ABAP Platform
Manche Anforderungen sind kein Add-on am Standard, sondern eine eigene Anwendung. Die Frage ist dann nicht ob, sondern wo: im ABAP-Stack, wo Daten, Berechtigungen und Betrieb schon vorhanden sind — oder daneben auf der BTP.
Wenn die Anwendung nah an die SAP-Daten muss
Es gibt Fachanwendungen, die zwar nicht zum SAP-Standard gehören, aber ohne SAP-Daten sinnlos wären: Genehmigungsprozesse mit Bezug auf Belege, aktenbasierte Anwendungen, Spezialkalkulationen, Planungs- oder Erfassungswerkzeuge. Für sie lohnt sich der Blick auf die SAP ABAP Platform — die technische Basis, auf der Ihr SAP-System ohnehin läuft.
Der Grund ist unspektakulär, aber wirtschaftlich: Ein skalierbarer Anwendungsserver, ein durchdachtes Berechtigungs- und Sicherheitskonzept, Transportwesen, Mandantentrennung, Protokollierung und Betrieb sind bereits da und werden ohnehin gepflegt. Wer daneben eine eigene Plattform aufbaut, bezahlt das alles ein zweites Mal — inklusive der Schnittstelle zurück zu den Daten, um die es eigentlich geht.
Technisch bauen wir heute mit dem RESTful Application Programming Model (RAP), CDS-Views als Datenmodell und Fiori Elements als Oberfläche. Wo Bestandsanwendungen laufen, betreuen wir auch die klassischen Technologien weiter — Web Dynpro und BSP verschwinden nicht dadurch, dass sie nicht mehr im Rampenlicht stehen. Für Geschäftsregeln nutzen wir BRFplus, für Abläufe die Workflow-Engine, für aktenbasierte Szenarien das Folder Management.
Die ehrliche Abgrenzung gehört dazu: Nicht alles gehört in den ABAP-Stack. Wo eine Anwendung überwiegend eigene Daten hält, externe Dienste nutzt oder von SAP-Releasezyklen unabhängig bleiben soll, ist der Weg über die SAP BTP die sauberere Antwort — Stichwort Clean Core. Diese Entscheidung treffen wir mit Ihnen vor der ersten Zeile Code.
Auf einen Blick
- Eigenständige Fachanwendungen statt Modifikation
- RAP, CDS-Views & Fiori Elements
- Workflow, Ad-hoc-Workflow & Folder Management
- BRFplus für Geschäftsregeln ohne Coding
- Berechtigungs- und Sicherheitskonzept von Anfang an
- Eigener registrierter CaRD-Namensraum
Was die Plattform mitbringt
Die Gründe, warum sich der Bau im Stack häufig rechnet.
- Skalierbarer Anwendungsserver für Unternehmens- und Web-Anwendungen
- Berechtigungs- und Sicherheitskonzept bereits vorhanden
- Transportwesen, Mandantentrennung, Protokollierung
- Direkter Zugriff auf die Geschäftsdaten ohne Schnittstelle
- Betrieb, Monitoring und Backup laufen ohnehin
Womit wir bauen
Aktuelle Technologien — und die bestehenden, wo sie im Einsatz sind.
- RESTful Application Programming Model (RAP)
- CDS-Views als Datenmodell, Embedded Analytics
- SAP Fiori / Fiori Elements als Oberfläche
- ABAP-OO als Grundlage
- Web Dynpro und BSP für Bestandsanwendungen
Prozesse & Regeln
Was eine Fachanwendung neben Masken und Tabellen braucht.
- Workflow und Ad-hoc-Workflow
- BRFplus für Geschäftsregeln per Customizing
- Folder Management für aktenbasierte Anwendungen
- Status- und Berechtigungssteuerung
- Anbindung an Archiv und Dokumentenmanagement
Wann besser nicht
Die ehrliche Gegenprobe, bevor gebaut wird.
- Überwiegend eigene Daten ohne SAP-Bezug
- Starke Abhängigkeit von externen Diensten
- Unabhängigkeit von SAP-Releasezyklen gefordert
- Dann: Side-by-Side auf der SAP BTP
- Clean Core bleibt in beiden Fällen die Leitlinie
Vorgehen
Vom Bedarf zur betriebsfähigen Anwendung.
- Anforderungen und Datenbezug klären
- Entscheidung ABAP-Stack oder BTP — begründet
- Datenmodell, Berechtigungen und Prozessfluss entwerfen
- Umsetzung mit Reviews, Dokumentation und Tests
- Übergabe an Ihr Team oder Wartung durch uns
Häufige Fragen
Worin unterscheidet sich das von Ihrer SAP-Entwicklung?
Auf der Seite SAP Entwicklung geht es um Zusatzentwicklungen am und um den SAP-Standard: Reports, Enhancements, Schnittstellen, kleine Werkzeuge. Hier geht es um eigenständige Fachanwendungen mit eigenem Datenmodell und eigener Oberfläche, die auf der Plattform laufen — ein anderer Zuschnitt, dieselben Entwickler.
Ist das nicht das Gegenteil von Clean Core?
Nein — Clean Core heißt, den SAP-Standard nicht zu modifizieren, nicht, im Stack nichts zu bauen. Eine eigenständige Anwendung im eigenen Namensraum verändert keinen Standardcode und bleibt upgradefähig. Entscheidend ist die saubere Trennung, nicht der Ort.
Wann empfehlen Sie stattdessen die SAP BTP?
Wenn die Anwendung überwiegend eigene Daten hält, stark von externen Diensten abhängt oder bewusst unabhängig von den SAP-Releasezyklen bleiben soll. Dann ist der Side-by-Side-Ansatz auf der BTP die sauberere und langfristig günstigere Wahl.
Können wir die Anwendung später selbst weiterentwickeln?
Ja, das ist ausdrücklich vorgesehen. Wir entwickeln im eigenen Namensraum, dokumentieren Datenmodell und Logik und übergeben an Ihr Team. Ob Sie danach selbst weiterarbeiten oder uns die Wartung überlassen, entscheiden Sie.
Passt das zu Ihrem Vorhaben?
Sprechen Sie direkt mit unseren Beratern – ohne Umwege.