ABAP – Past, Present & Future. SAP

What’s in a name?

SAP is notorious for rebranding its own acronyms to meet market requirements.

The original meaning of ABAP was “Allgemeines Beleg AuswertungsProgramm” meaning “general program to evaluate documents”. Later on it was changed to “Allgemeiner Berichts-Aufbereitungs-Prozessor” which means “”generic report preparation processor” and nowadays we talk about “Advanced Business Application Programming”.

Early beginnings of ABAP

SAP R/1

SAP was founded in 1972 by 5 ex-IBM employees. Back in 1976 SAP had 30 employees supporting some 50 customers on the R1 system. At that time it was called RFM, a derivation for the RF (financial accounting) and RM (inventory management / invoice verification) module. R stands for “real-time processing”.

There was no office yet and SAP employees worked on site with the customer. They believe this was their strength, which is to build something that the customer needs and expand from there. Note for example that there was no sales module in R1.

The 1 refers to 1-tier meaning that the presentation, application and database layer were all on one server.

It’s in this year that we can find the first mention of ABAP. In those days it was nothing more than a selection of macros, purely to create reports based on the available master- and transactional data.

SAP R/2

In 1979, SAP released the second generation of their ERP system. ABAP played an important role here and, together with a debugger, screen editor (not graphical but command screens) and so on, had grown into a fully-fledged development environment. The interactive debugger as we still know it today was a great asset because it was not common at the time. About 50% of R2’s code was written in ABAP, the other half was still written in an assembly language.

In 1980 SAP had about 80+ employees who now moved to the new Walldorf office.

The 2 refers to 2-tier. There was one server for the presentation layer and a second for both the application and database, making R2 a mainframe solution.

SAP R/3

R3 was released in 1992. It was the client/server version of the SAP ERP system. It would become the most popular SAP version.

It’s interesting to hear how history repeats itself. The SAP community didn’t believe in R3, they were convinced that most customers, especially the big players, would stay with R2. Exactly the same discussion and doubts arose with the first release of S/4HANA in 2013.

The 3 refers to 3-tier, so a separate server for all three layers (presentation-application database).

Thanks to Windows, SAP has also introduced SAP GUI as user interface for R3.

ABAP Syntax

The ABAP syntax was heavily influenced by COBOL: keywords followed by parameters. Some statements, for example MOVE, MOVE-CORRESPONDING, ADD, ADD-CORRESPONDING etcetera have exact counterparts in COBOL.

However, the idea has always been to build a standalone language, not too close to an existing design. For example, the direct embedding of SQL in the ABAP core was a big difference from other languages ​​at the time. SAP has always been looking for innovation in the ABAP language with regard to the existing syntax. There was/is some criticism of that syntax which is still based on this reporting language from back in the day. SAP once had a big project to completely rewrite the ABAP syntax to make it more “C-like”, but it was never a real option as that would have implied that all existing client programs would have to be recreated.

The keywords are referring to macros encoded in the core written in C. As a customer or partner, you cannot create a macro with an existing keyword, but you can create one with a different naming convention. This is why it is very difficult for SAP to introduce new statements as the name must be unique to all existing SAP systems to avoid collusion.

ALV

Originally called the ABAP List Viewer and later renamed the SAP List Viewer, this tool was a huge improvement for ABAP developers, there is no faster way to build a list. There is not a single old-school ABAP developer who does not know in detail how ALV works. End users love it too.

Whenever SAP comes up with a new UI technology (Webdynpro, Fiori,…), there is always a need for an ALV alternative because otherwise the SAP community would not accept it by default.

ABAP and the younger generation

The question is often asked why today’s young generation should bother to work in ABAP with all these low-code tools and front-end development environments.

However, we find that we don’t have too many problems finding starters. People are easy to convince once they see what a huge customer base they can serve as an ABAP developer. Of course, today’s ABAP is nothing like the language of a few decades ago. It is a big challenge for SAP to keep updating the ABAP language with new innovations that are offered in other languages, but as we have seen in recent years, SAP succeeds very well in this.

It is also quite easy to learn ABAP, as the range of learning opportunities (books, lessons, online courses, …) is endless and there is a huge community (SDN, SAP Jam groups, SAP TechED, …) to support you in your ABAP struggles.

The future of ABAP

Today, SAP still works very closely with customers on new technologies such as ABAP in the Cloud to build first what the customer needs now.

The biggest innovations in ABAP are the interaction with the HANA database and the creation of new programming models to support the development of Fiori (or other web) applications. For this, SAP introduced the ABAP RESTful Programming Model. This is also the standard within SAP to create Fiori applications, which means that thousands of SAP developers use ABAP RAP every day, so it makes sense that you as a partner or customer also become familiar with it, as this is the way to build new or extend existing Fiori applications.

Another big change is everything around S/4HANA Cloud, where we have a strict “clean core” paradigm to ensure future upgrades and updates. As we know SAP sends all code, but developers can’t just use everything anymore. Development will focus on using public APIs and obvious extension points, which is already quite common in other environments. It is very important to note that this will also be the case for the on-premise environment in the (near) future! All this can already be experienced in the SAP BTP ABAP Environment or Steampunk.

The next big innovation is the move from the integrated development environment, the ABAP workbench aka SE80, to Eclipse with the ABAP Development Tools add-on. Most S/4HANA encryption is only possible in Eclipse. I’m thinking CDS views, ABAP RAP artifacts like behavior definitions, service bindings and so on. SAP only invests in Eclipse ADT for further innovation and development efficiency, so it makes sense that this will become your new standard development platform for ABAP. Nice to know is that SAP also uses APIs for communication between Eclipse and the SAP system (for example an API to create a class). This also makes it easier for SAP if they ever want to switch development environments again.

Source: sap.com