SAP XSA as an alternative to ABAP?
If you were to believe the long-established SAP specialists, you would think that SAP and ABAP belong together like Bonnie and Clyde. Just like the gangster couple, the two go hand in hand and have done so for decades: ABAP was developed about 40 years ago for SAP R/2 and was named “Allgemeiner Berichts- und Auswerte-Prozessor” (“General Report and Evaluation Processor”) at that time; a programming language that was primarily intended for the creation of reports. Under SAP R/3, ABAP was renamed “Advanced Business Application Programming” and also received a massive functional upgrade. Over the years, ABAP was continuously developed further and, for example, supplemented by object-oriented language constructs that became available with the introduction of ABAP Objects in Release 4.6C.
SAP has always maintained strict downward compatibility with ABAP. As a result, many of the programs first implemented for SAP R/3, which form the classic SAP Application Components, can still be run on current SAP systems such as SAP ERP, except for minor adaptations. The new S/4HANA product also continues to support ABAP; customers have become accustomed to it because it covers the typical requirements in the ERP environment.
Limitations of ABAP in customer-specific requirements
Things get interesting when it comes to the realization of very special requirements. The intralogistics solution provider Flexus solves a whole series of these special, computationally intensive and performance-intensive requirements from the logistics environment for its customers, also known as NP-hard problems. This is where ABAP quickly reaches its limits. Flexus is therefore researching how logistical problems in the SAP environment can be solved in the future with modern SAP technologies beyond ABAP. The matter is analyzed using a concrete example: the assignment algorithm of the Transport Guidance System. From a mathematical point of view, this can be reduced to the NP-hard Vehicle Routing Problem which is related to the better known Travelling Salesman Problem.
Native development with XSA
With the introduction of HANA, SAP has opened up and offers native development in programming languages other than ABAP. The SAP HANA Development Metro Map offers no less than three models for the native development of services for SAP HANA: Extended Application Services (XS) Classic, its technologically highly revised successor XS Advanced Programming Model (XSA) and SAP Cloud Application Programming (CAP). XSA forms the technical foundation and provides an architecture that is available both in the Cloud and in On Premise HANA systems. In conceptual terms, this supports two approaches: Platform independence and the microservice idea.
But what can XSA do that previous ABAP competitors could not?
First of all, XSA follows the “Bring Your Own Language” (BYOL) paradigm, which means that several different programming languages are available on the platform and developers can implement applications in the programming language of their choice.
It is therefore possible to select a programming language that is appropriate for the problem at hand. SAP is already promoting this by offering AI services not in ABAP. Instead, the manufacturer itself implements them natively in Python.
This approach can also be applied to NP-hard problems in the logistics environment. These are traditionally implemented in resource-saving languages such as C++, which is made possible and easy to integrate with XSA. The framework program, which calls the compute-intensive program parts as an XSA web service, can, in this case, still be implemented in ABAP.
By opening up to popular programming languages, SAP has paved the way for a massive increase in the number of available program libraries and frameworks. No longer are ready-made solutions limited to the sparse range of ABAP classes and function modules delivered by SAP. Instead, the entire open source world is accessible. Many of the freely available modules are subject to the Apache 2.0 license which even permits free commercial reuse.
The fact that XSA does not have to be integrated as a new machine into the SAP landscape could prove to be strategically decisive factor. Customers migrating to S/4HANA cannot get around a HANA system anyway, which means XSA is “already there anyway”. Bearing in mind XSA also has access to the HANA database, other ideas come to mind: Why exchange data in JSON or XML format with the XSA web services via REST, why not simply implement the data exchange indirectly via a HANA database shared by XSA and S/4HANA?
While programming based on XSA will certainly not be the new ABAP, it does bring to the table an interesting implementation alternative for unusual requirements. The BYOL concept gives hope that SAP will continue to move away from the ABAP monopoly in the future and propagate ABAP as one of many equivalent programming languages for development in the world of SAP. The developer community, at least, would be pleased. And who knows – perhaps some die-hard Python or C++ developers would then be permanently drawn to the SAP environment?
Author – Bernd Neeser
Master Student in the Field of Optimization and Transport Guidance Systems
As part of his work at Flexus, he compares platforms to solve the Vehicle Routing Problem from a strategic point of view. These platforms are used in the intralogistics of our customers. Typical applications are efficient guidance systems for forklifts and tugger trains.