SAP XSA als Alternative zu ABAP?

Glaubt man den alteingesessenen SAP-Spezialisten, dann gehören SAP und ABAP zusammen wie Bonnie und Clyde. Genau wie das Gangster-Pärchen gehen die zwei Hand in Hand und das schon seit Jahrzehnten: ABAP wurde vor etwa 40 Jahren für SAP R/2 entwickelt und hieß damals noch „Allgemeiner Berichts- und Auswerte-Prozessor“, eine Programmiersprache, die primär für die Erstellung von Reports vorgesehen war. Unter SAP R/3 erhielt ABAP den Namen „Advanced Business Application Programming“ und wurde auch funktional massiv aufgestockt. Über die Jahre wurde ABAP kontinuierlich weiterentwickelt und z. B. um objektorientierte Sprachkonstrukte ergänzt, die mit der Einführung von ABAP Objects zu Release 4.6C Einzug erhielten.

SAP hat mit ABAP stets eine strenge Abwärtskompatibilität gewahrt. Dadurch sind viele der für SAP R/3 erstmals implementierten Programme, die die klassischen SAP-Anwendungskomponenten bilden, bis auf kleinere Anpassungen auch auf aktuellen SAP-Systemen wie SAP ERP noch lauffähig. Auch das neue Produkt S/4HANA unterstützt weiterhin ABAP, die Kunden haben sich daran gewöhnt, weil es die typischen Anforderungen im ERP-Umfeld abdeckt

Grenzen von ABAP bei kundenindividuellen Anforderungen

Interessant wird es, wenn es um die Realisierung sehr spezieller Anforderungen geht. Der Intralogistik-Anbieter Flexus löst gleich eine ganze Reihe dieser speziellen, rechenintensiven und performancelastigen Anforderungen aus dem Logistik-Umfeld für seine Kunden, die auch als NP-schwere Probleme bekannt sind. Hier stößt ABAP schnell an seine Grenzen. Flexus untersucht deshalb, wie logistische Probleme im SAP-Umfeld zukünftig mit modernen SAP-Technologien jenseits von ABAP gelöst werden können. Untersucht wird der Sachverhalt an einem konkreten Beispiel, dem Zuteilungsalgorithmus des Staplerleitsystems. Aus mathematischer Sicht lässt sich dieses auf das NP-schwere Vehicle Routing Problem reduzieren, das mit dem besser bekannten Travelling Salesman Problem verwandt ist.

Native Entwicklung durch XSA

Seit der Einführung von HANA hat SAP sich geöffnet und bietet native Entwicklung auch in anderen Programmiersprachen als ABAP an. Die SAP HANA Development Metro Map bietet gleich drei Modelle für die native Entwicklung von Services auf SAP HANA: Extended Application Services (XS) Classic, dessen technisch stark überarbeiteten Nachfolger XS Advanced Programming Model (XSA) und SAP Cloud Application Programming (CAP). XSA bildet die technische Basis und bietet eine Architektur, die sowohl in der Cloud, als auch auf On Premise HANA-Systemen zur Verfügung steht. Konzeptionell werden damit zwei Ansätze unterstützt: Plattformunabhängigkeit und der Microservice-Gedanke.

Was aber kann XSA, das bisherige ABAP-Konkurrenten nicht konnten?

Flexus AG SAP Intralogistik Partner für EWM - S/4HANA XSA

Einerseits verfolgt XSA das „Bring Your Own Language“-Paradigma (BYOL), d. h. es stehen mehrere verschiedene Programmiersprachen auf der Plattform zur Verfügung und Entwickler können Anwendungen in der Programmiersprache ihrer Wahl implementieren. 

Derzeit werden C++, Java, JavaScript und Python unterstützt, weitere Programmiersprachen lassen sich aber zukünftig leicht ergänzen, es muss nur eine entsprechende Runtime zur Verfügung gestellt werden.

Damit kann eine für die Problemstellung angemessene Programmiersprache ausgewählt werden. SAP selbst macht dies bereits vor, indem KI-Services nicht in ABAP angeboten werden, sondern vom Hersteller selbst nativ in Python implementiert werden.

Der Denkansatz kann auch auf NP-schwere Probleme im Logistik-Umfeld angewendet werden. Diese werden traditionell gerne in ressourcensparenden Sprachen wie C++ implementiert, was durch XSA möglich und leicht einbindbar ist. Das Rahmenprogramm kann dabei weiterhin in ABAP implementiert sein, das die rechenintensiven Programmteile als XSA-Webservice aufruft.

Durch die Öffnung für populäre Programmiersprachen, steigt auch das Angebot an Programmbibliotheken und Frameworks massiv an. Fertige Lösungen beschränken sich nicht mehr auf das spärliche Angebot der von SAP ausgelieferten ABAP-Klassen und -Funktionsbausteine. Stattdessen steht die komplette Open Source Welt offen. Viele der frei verfügbaren Bausteine unterliegen der Apache 2.0 Lizenz, die sogar eine kostenlose kommerzielle Weiterverwendung erlauben.

Zukunftsausblick

Strategisch entscheidend könnte sein, dass XSA nicht als neue Maschine in die SAP-Landschaft eingebunden werden muss. Kunden, die auf S/4HANA migrieren, kommen ohnehin nicht an einem HANA-System vorbei, XSA ist also „sowieso schon da“. Bedenkt man, dass XSA auch Zugriff auf die HANA-Datenbank hat, kommen weitere Ideen in den Sinn: Warum mit den XSA-Webservices über REST Daten im JSON- oder XML-Format austauschen, warum nicht gleich indirekt über eine von XSA und S/4HANA gemeinsam genutzte HANA-Datenbank den Datenaustausch realisieren?

Mit Sicherheit wird die Programmierung auf Basis von XSA nicht das neue ABAP sein, es stellt aber für außergewöhnliche Anforderungen eine durchaus interessante Implementierungsalternative dar. Das BYOL-Konzept lässt hoffen, dass SAP sich zukünftig weiter vom ABAP-Monopol verabschiedet und ABAP als eine von vielen gleichwertigen Programmiersprachen für die Entwicklung in der SAP-Welt propagiert. Die Entwicklergemeinde jedenfalls würde es freuen. Und vielleicht würde es dann sogar den einen oder anderen eingefleischten Python- oder C++-Entwickler dauerhaft ins SAP-Umfeld verschlagen?


Bernd Neeser von der Flexus AG

Autor – Bernd Neeser

Masterand im Bereich Optimierung und Transportleitsysteme

Im Rahmen seiner Tätigkeit bei Flexus verglich er Plattformen zur Lösung des Vehicle Routing Problems unter strategischen Aspekten. Die Plattformen kommen in der Intralogistik unserer Kunden zum Einsatz. Typische Anwendungen sind effiziente Leitsysteme für Stapler und Routenzüge.