Abap in der S/4-Hana-Ära

Der Hype um die Programmiersprachen der vierten Generation, kurz als 4GL (Generation Lan­guage) bezeichnet, reichte von etwa Mitte der 80ger-Jahren bis weit in die zweite Hälfte der 90er.

Ziel war vor allem, Entwickler bei der schnellen Erstellung vollständiger Applikationen nachhaltig zu unterstützen.

Mit etlichen offenen und proprietären 4GLs entwickelt, erblickten zahlreiche Anwendungen das Licht der Welt – und dienten als Basis oder Entwicklungsplattform für Standardsoftwaresysteme, so wie etwa der Walldorfer Erfolgsschlager SAP R/3.

Etwa Mitte der 90er-Jahre war es von SAP ein Ansatz, Abap (Advanced Business Application Programming) als generelle Entwicklungsbasis und 4GL breit im Markt zu etablieren. Promotet wurde seinerzeit die Abap-Workbench.

Etliche R/3-Kunden und SAP-Partner gingen bereits zuvor daran, mit der SAP-Workbench Anwendungen unterschiedlichster Art zu entwickeln. Teils als quasi Stand-alone-Systeme, teils als einbindbare R/3-Komponenten.

Parallel diente Abap insbesondere immer stärker bei SAP-Kunden dazu, R/3-Erweiterungen gemäß den unterschiedlichsten Unternehmensanforderungen (Stichwort: Intellectual Property) zu kreieren oder zu entwickeln, was heute noch in reger Art und Weise der Fall ist.

Abap, anfänglich als „Allgemeiner Berichtsaufbereitungsprozessor“ bezeichnet, hat sich im Laufe der Jahre verändert und weiterentwickelt. SAP hat dabei stets auf Kompatibilität geachtet, auch, als objekt­orientierte Programmierelemente (sowie -modelle) eingeführt wurden.

Eine wichtige Wegmarke erfolgte beispielsweise zu Beginn der 90er-Jahre, als der Walldorfer Softwarekonzern seit der NetWeaver-Einführung neben Abap eine Java-Ablauf- und -Programmierumgebung offerierte.

Eine andere: Seit etwas mehr als vier Jahren bietet SAP eine Abap-Entwicklungsumgebung auf der Grundlage von Eclipse an, einer Open-Source-Plattform.

Wobei es über die Zeit hinweg etliche Abap-Entwicklungsstufen gab. Die jedoch alle hier aufzuführen, würde den Rahmen sprengen.

Erwähnenswert ist auf jeden Fall noch: Abap fußt auf Syntaxelementen der Programmiersprache Cobol.

SAP wird sicherlich in der einen oder anderen Art und Weise stringenter Abap auf die Hana-Nutzung ausrichten bzw. dahingehend anpassen.

Standard hier, langlebiger Custom-Code dort

Man kann nur mutmaßen, wie viele Codezeilen oder kleine sowie größere Anwendungen/Anwendungszusätze mit der proprietären Programmiersprache Abap jemals rund um den Globus entwickelt wurden.

Sie gehen jedenfalls in die Milliarden. Und Abap-Custom-Code ist langlebig, sehr langlebig.

Viele SAP-Anwender mit Abap-Entwicklungen sowie etliche SAP-Partner, die auf der Basis von Abap Zusatz- oder auch Branchenlösungen entwickelt haben, stellen sich aktuell die Fragen:

• Lässt sich Abap-Code auch im S/4-Hana-Zeitalter nutzen?
• Was muss getan werden, um Abap-Programme in S/4  möglichst optimal einzusetzen?

Bekanntlich stellt S/4 eine neue Generation der Business Suite auf der Grundlage einer neuen Technologie dar. Wobei sich zum einen der Funktionsumfang stetig ändert, geschehen etwa im aktuellen Major-Release 1610 (gegenüber 1511).

Zum anderen überführt SAP zahlreiche Funktionen in den Standard. Ferner werden verschiedene Transaktionen zusammengefasst.

Ungeachtet dessen lässt sich Abap- oder Custom-Code generell auch in S/4 nutzen. Allerdings ist der Abap-Code dahingehend zu analysieren, ob er sich mit den vorhandenen und künftigen Programmteilen von S/4 und der Hana-Nutzung verträgt.

Eine Erstellung einer Art „Heat Map“ ist hier empfehlenswert, die beispielsweise Auskunft darüber gibt, welche Objekte auf welche Tabellen zugreifen, oder um zu prüfen, welche Prozesse und Daten quasi simplifiziert wurden und welche gegebenenfalls simplifiziert werden können oder auch zwingend müssen.

Oder: welche Programme in welchen Transaktionen wirken, und zwar aus Gründen der Identifizierung/Nachvollziehbarkeit.

Die Tools von Smart­shift sind in der Lage, auch derlei Analysen durchzuführen – als Grundlage für relevante und nachhaltige Code-Optimierungen.