ABAP unter S/4HANA ist alt?

ABAP unter S/4HANA ist alt? Nur wenn es so behandelt wird.

In vielen Brown- oder Bluefield-Projekten wird im Zuge der S/4HANA-Conversion eine gezielte Auswahl der unter S/4HANA weiterhin benötigten ABAP-Artefakte vorgenommen. Programme, Reports und Erweiterungen werden bewertet und ggf. so technisch angepasst, sodass sie auf S/4HANA lauffähig sind.

Was jedoch häufig passiert: Die Entwicklungen bleiben im Wesentlichen unverändert, wenn es keine technische Notwendigkeit zur Optimierung gibt.

Das System ist damit zwar S/4HANA – der Code dahinter fühlt sich aber oft noch stark nach ECC an. Dabei liegt genau nach der Migration enormes Potenzial, ABAP gezielt weiterzuentwickeln. Nicht als Selbstzweck, sondern dort, wo messbarer Mehrwert für Betrieb, Performance und Fachbereiche entsteht. Aus Projektsicht kristallisieren sich dabei sechs Themenfelder heraus, die sich besonders lohnen und folgend beschrieben sind.

1. Reporting und Datenanalyse: weg vom klassischen ABAP-Report

Viele ABAP-Reports für Analysezwecke sind historisch gewachsen: komplexe SELECTs, eigene Verdichtungslogik, ALV-Ausgaben oder Excel-Exporte. Mit S/4HANA bietet sich die Möglichkeit, diese Logik in ABAP Core Data Services (CDS) zu verlagern und auf virtuelle Datenmodelle zu setzen.

Der Vorteil liegt nicht nur in der Technik. Fachlich sauber modellierte CDS-Views reduzieren Eigenlogik, erhöhen Wiederverwendbarkeit und machen dieselben Daten gleichzeitig in verschiedenen Frontends nutzbar – etwa in Fiori, SAC oder externen Analytics-Tools. Datenanalysen werden so auf eine zeitgemäße Basis gestellt und komplexitätsaufwände individuell entwickelte ABAP-Reports zur reinen Datenanalyse sinken.

2. Umstellung auf die neuen Datenstrukturen von S/4HANA

Kompatibilitätsviews und Side Tables erleichtern den Umstieg auf S/4HANA – sind aber keine langfristige Lösung für einer verständlichen und weiterentwickelbaren ABAP-Architektur.

Viele kundeneigene Programme greifen auch nach der Migration weiterhin auf alte Tabellenstrukturen BKPF/ BSEG im Finance oder COEP/COSP im Controlling zu, obwohl mit Universal Journal (ACDOCA) oder Material Journal (MATDOC) längst vereinfachte, konsolidierte Datenmodelle zur Verfügung stehen (in der die meisten der relevanten Datenfelder vorhanden sind).

Der Wechsel auf diese Kernstrukturen erfordert Anpassungen im ABAP-Code, zahlt sich aber mehrfach aus: weniger Tabellenzugriffe, klarere Logik, weniger Sonderfälle. Gleichzeitig wird sichergestellt, dass Entwicklungen auch in zukünftigen Releases stabil bleiben und nicht auf technisch „auslaufenden“ Konstrukten basieren.

3. Laufzeitoptimierung durch moderne Datenbankzugriffe

In vielen ABAP-Programmen erfolgt der Datenbankzugriff noch nach klassischen Mustern – funktional korrekt, aber nicht optimal für HANA. S/4HANA eröffnet hier deutlich mehr Möglichkeiten: modernes Open SQL, CDS-basierte Zugriffe, AMDPs oder Table Functions (verwaltet durch AMDP). Auch Native SQL kann in Einzelfällen sinnvoll sein.

Wichtig ist bei dieser Optimierung ein strukturiertes und nutzenorientiertes Vorgehen, da nicht jedes Programm optimiert werden muss. Über Laufzeitanalysen lassen sich gezielt Hotspots identifizieren, die anschließend refactored und mit dem Ansatz von Regressionstests geprüft werden. Das Ergebnis sind kürzere Dialogzeiten, stabilere Massenläufe und insgesamt besser skalierende Anwendungen.

4. Parallelisierung großer Verarbeitungsaufgaben

Viele Eigenentwicklungen sind historisch seriell aufgebaut – insbesondere im Hintergrund. Mit steigenden Datenmengen wird das zunehmend zum Problem. S/4HANA bietet die technische Basis, um Verarbeitungen sinnvoll zu parallelisieren: etwa über asynchrone RFCs, parallele (ABAP-)Verarbeitung oder datenbankseitige Parallelisierung.

Richtig eingesetzt lassen sich damit Laufzeiten deutlich reduzieren und gleichzeitig Sperrzeiten auf kritischen Objekten minimieren. Gerade für buchungsnahe oder massenintensive Prozesse ist das ein spürbarer Stabilitätsgewinn im Tagesgeschäft.

5. Eventbasierte Verarbeitung statt zeitgesteuerter Jobketten

Klassische ABAP-Landschaften sind häufig von zeitgesteuerten Jobs geprägt, die regelmäßig oder auf Basis von Statusabfragen (Polling) Daten sammeln, Daten verarbeiten, Daten exportieren oder Folgeprozesse anstoßen. Über die Jahre entstehen so komplexe Jobketten, die schwer zu überblicken, aufwendig zu betreiben und fehleranfällig sind.

Mit S/4HANA bietet sich die Möglichkeit, solche Szenarien ereignisgetrieben umzusetzen. Fachlich relevante Events lösen Folgeaktionen gezielt aus – genau dann, wenn sie benötigt werden.

Architektonisch ist das in vielen Fällen der sauberere Ansatz: Prozesse werden klarer modelliert, unnötige Systemlast entfällt und Reaktionszeiten verkürzen sich.

Gleichzeitig darf man den betrieblichen Aufwand nicht unterschätzen. Eventmodelle müssen sauber definiert werden, Monitoring und Nachvollziehbarkeit aktiv mitgedacht werden und auch das Debugging wird anspruchsvoller. Der Mehrwert entsteht daher nicht automatisch, sondern durch einen bewussten, gut vorbereiteten Umbau bestehender Programme.

6. Schrittweise Annäherung an das Ziel „Clean Core“

„Clean Core“ ist kein Schalter, den man umlegt, sondern ein Zielbild. Für ABAP bedeutet das vor allem: Modifikationen reduzieren, Erweiterungspunkte nutzen und kundeneigene Logik klar kapseln. Ob über In-App-Extensions, Side-by-Side-Ansätze oder perspektivisch BTP – wichtig ist, dass neue oder angepasste Entwicklungen upgrade-stabil und möglichst cloud-fähig aufgebaut werden. CDS spielt hier ebenfalls eine Rolle, ist aber nur ein Baustein unter mehreren.

Fazit: Wer diese Themen gezielt angeht, modernisiert ABAP nicht um der Technik willen. Stattdessen entstehen stabilere Prozesse, bessere Laufzeiten, kürzere Entwicklungszyklen – und eine Codebasis, die auch in den kommenden Jahren tragfähig bleibt.

ABAP ist somit per se nicht „alt“. Alt wird es nur, wenn es nicht weiterentwickelt wird und stehen bleibt!

Autor: Michael Natterer

ABAP unter S/4HANA ist alt?