Evolution of ABAP
The year 2022 is quite remarkable for SAP’s history since a couple of anniversaries coincide that are of great relevance for the evolution of ABAP. First and foremost, SAP is now 50 years old and without any exaggeration this period stands for 50 years of ongoing success in enterprise software. Another important milestone was the introduction of the SAP R/3 system 30 years ago. And finally, fair enough to be stated in this context, ABAP Development Tools for Eclipse (ADT) have been introduced 10 years ago offering a tools alternative to the classical ABAP Workbench (transaction SE80).
In this blog I want to take you on a journey through all these years from an ABAP developer’s perspective. I know that this can only strive some of the important milestones during the evolution of ABAP towards what it is today: the technology foundation for SAP S/4HANA and S/4HANA Cloud and an extensibility platform to build side-by-side extensions with SAP BTP ABAP Environment (Steampunk) and on-stack extensions on top of the SAP S/4HANA Cloud Stack with SAP S/4HANA Cloud ABAP Environment (embedded Steampunk).
It turns out that the historical resources somehow vanish over time although the Internet never forgets. Several new generations of developers have grown up working with the up-to-date ABAP versions and the older colleagues enjoy their well-deserved (early) retirement and focus on other priorities in the meantime.
When I joined SAP in early 1992 my first training experience was a delta course describing the differences between ABAP/4 in R/2 and R/3. This was kind of interesting because I had no pre-knowledge in R/2 at all. Luckily the ABAP programming model of R/2 and R/3 had great similarities and my manager at that time, Gerd Oswald, not yet member of SAP’s Executive Board, but on a straight way to it, was very thoughtful to send me to a couple of R/2 ABAP courses to quickly fill my knowledge gaps. SAP was a company of roughly 2500 employees serving 2000 R/2 customers. R/3 was not yet introduced to the market but early adopters such as Würth, the first R/3 customer, were already heavily testing the new “client server” enterprise software offered by R/3.
ABAP/4 in R/2
But before we go into the details of R/3 let us first investigate the roots of ABAP in R/2. The exact origin of ABAP is somehow a bit vague. Probably the first reference of ABAP occurs in a functional brochure of the RFM system (today sometimes referred to as “R/1”) which was the predecessor of the R/2 system. RFM was developed by the five founders (Dietmar Hopp, Hasso Plattner, Klaus Tschira, Hans-Werner Hector, Claus Wellenreuther) as a realtime system for financials and materials management. Realtime stands for a system where data was input directly at terminals connected to an IBM mainframe. Data could be input and analyzed in real time, interactively at the screen, rather than being printed out using punch cards with the batch systems that were in use. Consequently, reporting capabilities were in need. In the function brochure SAP introduces the term ABAP mentioned as a tool to easily create reports based on the transactional data stored in the RFM system. The brochure dates from 1976 where around 30 SAP employees served 50 customers. The business processes of the RFM system were driven by Dynpros meaning the concept of Dynpro is older than ABAP but we will investigate the relationship between the two later in more detail.
One of the fundamental characteristics of the RFM system was the introduction of the document principle. This means that all financial and materials management transactions were saved as documents so that users could always drill down to the original data before they were booked in the financial accounting structures in contrast to most of the early batch systems where documents existed on paper which was thrown away after the financials booking was complete. Technically the RFM system already offered sessions through OK code handling running transactions in an interleaved way.
ABAP served as concept and tool for reporting. One of the founders, Klaus Tschira, had created a set of assembler macros for input and database selection as well as list formatting. To simplify the recurring reporting tasks Gerd Rodé invented his own reporting syntax and programming environment for the R/2 system in the early 80’s. In the first implementation approach the new ABAP syntax (RSYN = Report Syntax) was translated into the former macros leading to a two phase ABAP (macro generation and execution). Later the ABAP compiler generated the control blocks for direct interpretation: The ABAP processor was born. From then on Gerd Rodé started to hire new developers and continued to lead the ABAP team until he left the company in the late 90s.
REPORT RFBILA00 LINE-COUNT 65(0) LINE-SIZE 132 NO STANDARD PAGE HEADING. SEGMENTS: SA, SB, SC. TABLES: BHDGD, SELC, T001, T010, T011, T013, T001G. FIELD-GROUPS: HEADER, KONTEN, TRIGGER. INSERT SORT-BUK1 " Buchungskreis SORT-GSB1 " Geschaeftsbereich SORT-LIST " Listenteil SORT-BIL1 " Stufe 1 SORT-BIL2 " Stufe 2 SORT-BIL3 " Stufe 3 SORT-BIL4 " Stufe 4 SORT-BIL5 " Stufe 5 SORT-VERD " Verdichtungsschluessel SORT-KTNR " Sachkonto SORT-BUK2 " Buchungskreis (KONS) SORT-GSB2 " Geschaeftsbereich (KONS) INTO HEADER. GET SA. CHECK SELECT-OPTIONS. CLEAR: GTAB. REFRESH GTAB. GET SB. CHECK SELECT-OPTIONS. * Bilanz-Steuerung (Unterkonten auslassen) CHECK SB-BSTEU NE 'U'. CLEAR: H. READ TABLE T001 WITH KEY SB-BUKRB. * Bilanzschluessel gemaess Version merken CASE VERSION. WHEN '011 '. BILSCHL-SOLL = SA-BISS1. BILSCHL-HABEN = SA-BISH1. BILSCHL-VERD = SA-VRS11. WHEN '012 '. BILSCHL-SOLL = SA-BISS2. BILSCHL-HABEN = SA-BISH2. BILSCHL-VERD = SA-VRS21. WHEN '013 '. BILSCHL-SOLL = SB-BISS3. BILSCHL-HABEN = SB-BISH3. BILSCHL-VERD = SB-VRS31. WHEN '014 '. BILSCHL-SOLL = SB-BISS4. BILSCHL-HABEN = SB-BISH4. BILSCHL-VERD = SB-VRS41. ENDCASE.
The new ABAP syntax in R/2
Evolution after all is a big competition. Many inventors and teams start in parallel. Many teams also in the applications provided their own frameworks. Historically the DYNP team claimed to deliver the technology foundation for developing apps. The concept of Dynpro offered a lot of angles for data transfer (batch input) or for testing applications (CATT). But the associated programming logic had to be implemented in Macro assembler. ABAP on the other hand offered a language level, in-process debugger that greatly simplified fast development and prototyping.
ABAP borrowed some syntactical conventions from Cobol (statements start with a key-word and end with a period). But it was more flexible and creative using the colon, comma logic to abbreviate code and some of the syntax was also influenced by Software AG’s Natural such as list processing and treating SQL as part of the language. SAP was criticized to implement too much in Assembler at that time and a 4GL environment was certainly a way out of this dilemma. The unique strength of ABAP definitely also lied in its ability to manage large volumes of data not only on the database level but also in the application using the concept of internal tables. In the late R/2 versions roughly half of the transactions and reports were developed in Assembler and the other half in ABAP/4. It was possible to define an internal table in ABAP and to call an Assembler macro from within ABAP to process the internal table and vice versa.
Common data definitions were kept in the Data Dictionary and actively referred to in the ABAP program establishing the self-compiling nature of ABAP. When a central data element or structure was changed the referring ABAP program was automatically recompiled on execution.
Client/server architecture with R/3
The decision to develop a new generation of enterprise software, namely the R/3 system was taken in response to IBM’s SAA initiative. To better manage and streamline the software portfolio IBM had introduced a couple of standards such as CUA for common user access (think of the standard F-key settings) and inter process communication (CPIC, APPC). The more foundational requirements were the clear focus on relational databases and the usage of the programming language C for system level development. The success of the UNIX operating system and the decline of the IBM mainframe has had a great deal to accelerate this overall transformation process. The notion of “client-server” based systems where clients on UNIX workstations connect to central resources such as a relational database system over standardized networks (TCP/IP) took off. The R/3 project was born with the goal to reach new mid markets running midsize machines like the AS/400. However, this approach failed and therefore the R/3 project was retargeted towards UNIX. The SAP Kernel had to be implemented in C and all applications had to be implemented in ABAP/4. From an architecture perspective the R/3 Kernel inherited a lot from its R/2 predecessor, namely the task handler, the DYNP, the ABAP processor and the database interface, but the R/2 kernel was implemented in Assembler so the R/3 Kernel had to be reimplemented in C. After first performance tests it also became clear that not each session could be allocated its own Work process. Rather a transaction monitor (represented by CICS in the mainframe world) namely the dispatcher had to be introduced to distribute the end users’ work to the available free work processes. This runtime architecture is well established and performance-proof. It has seen a lot of refinements over the years to cope with the latest technology innovations but it is still valid also in the latest Cloud deployments and recent adaptations of the ABAP platform for K8S based environments.
The initial user interface of R/3 was called saptemu and like its name suggests it was basically a terminal emulator. End users could logon and run terminal sessions against R/3 and R/2 systems. Saptemu ran on UNIX workstations and connected X terminals. The terminal screen for each main mode was represented as a main window on the screen decorated with pull down menus and function key settings. Meanwhile the personal computer had conquered the office desk with Windows becoming the dominant operating system for all end users in the enterprise. To address the end users’ needs SAP started a new development initiative: SAP GUI was born. Besides Windows also other platforms were supported such as MOTIF on UNIX and even Macintosh in the early days. But only the Windows version survived as native SAP GUI implementation and is alive and well until today. The other frontend platforms were served by the platform independent Java GUI later.
SAPGUI delivered a state-of-the-art visual representation with a fresh look and feel and added graphical capabilities such as check and radio buttons, push buttons and frames for structuring field groups on the screen.
On the R/3 server side a lot of innovations had to be delivered. Initially only Oracle was supported as the underlying relational database. For maximum throughput a cursor cache was implemented in the Kernel to save the costly PREPARE operations when executing SQL commands over and over again (think of nested SELECT statements when processing logical databases etc).
The DBSL library was introduced as a database abstraction layer and other database from IBM and Microsoft were enabled. Roughly at the same time the RFC protocol was introduced. RFC allowed to call a function module in a remote ABAP-based system passing parameters and returning results. RFC development was easy since remote debugging was supported from the first day on. Additional protocol features were added such as dialog processing and asynchronous handling of calls. The Kernel was optimized with extended memory management keeping user sessions in shared memory rather than copying user context each time the user continues to process the next screen. Another important improvement was the introduction of long repository names for artefacts such as programs (8 characters at that time 4 of which were consumed by the prefix SAPM for module pools), transaction codes (4 characters etc). Many of the limitations stem from the R/2 times. In addition, name spaces were introduced so that different partners could deploy their solutions without ending up in name conflicts. On the ABAP language side structured data types were introduced for better consistency and safety.
ABAP/4 Development Workbench
On the tools side the ABAP Workbench served to speed up the developer productivity. The idea to build tools with the help of the ABAP language itself was already present in R/2. The advantage of this approach is quite obvious: ABAP developers don’t need to drill down to the lower levels and can build tools in a fast and efficient way using the capabilities of the ABAP platform. The approach leads sometimes to chicken and egg problems (how do you fix the ABAP editor if the ABAP editor is written in ABAP but has unfortunately a syntax error). To better integrate the various tools the Repository Browser was introduced displaying all of the artefacts of a program or package (at that time called a development class) in a hierarchical tree from which you could invoke the corresponding tool by simply double clicking the name similar like you would double click a file in the Windows file manager and invoke the suitable office application. Navigation was a superior feature inside the Workbench. At every usage of a development object (Selecting a table, calling a function, using a field you could navigate to its definition and if the object was not yet existent the Workbench would ask you to create it on the fly. In addition, you could create a where used list that shows all the references throughout the whole system. The underlying Workbench indices were updated incrementally. The graphical screen painter was added to offer WYSIWYG capabilities also in the tooling environment.
Meanwhile, R/3 took off and sold very successfully especially in the US market. The ability to run integrated business processes like order fulfillment based on the innovative client/server approach was exactly what customers had been waiting for. The dramatic increase of the R/3 adoption set the primary focus on managing the lifecycle of R/3 in an efficient way. Already in R/2 customers were used to modify SAP applications. This behaviour did not change in R/3. To better support the handling of modifications the Modification Assistant was introduced. Each modification was surrounded with special comments and defined at special places (begin of a structure, end of structure or modularization unit) to make the adaptation process much easier after an upgrade or support package implementation.
While R/3 was ramping up quickly a new phenomenon showed up affecting the whole IT business until today. The world wide web reached the enterprise and new home pages mushroomed everywhere without a clear idea how this could help in enterprise applications. Traditionally, enterprises ran their business processes behind “large fire walls” meaning they did not have an Internet gateway at all. I remember a town hall meeting where the Board announced an Internet gateway for every SAP employee and at home most people suffered from 14k modem lines.
A project (SAP@Web) was started to bring R/3 to the Internet. The decision was taken to build an SAP Internet gateway (Internet Transaction Server) managing browser connections of end users with R/3 transactions running on the R/3 backend. This external Internet transaction server would open a new session driving the SAP GUI programmatically via the SAP GUI API, load a predefined HTML template corresponding to a running dynpro screen and render the actual fields of the current dynpro into the template and finally display it in the browser. The corresponding dynpro screens had to follow certain development guidelines (so-called Internet application components). Later, the ITS was integrated into the SAP Kernel. The Web GUI uses the session management and rendering capabilities of the ITS and serves as an alternative to SAP GUI in purely browser based user environments until today.
After the initial success of R/3 the pressure was constantly high to level up the user experience. Office applications on the PC showcased high user interface sophistication. New graphical development tools showed up in the market like Visual Basic and Powerbuilder where coding seemed to be a simple click and drag exercise. Object orientation was perceived as the magic word to enable these new graphical capabilities.
The R/3 programming model was somehow locked in the Dynpro boundaries at that time. To enable a new GUI element such as the table control in Dynpro all software layers (DYNP, ABAP, SAP GUI) had to be updated simultaneously limiting the speed of innovation.
In addition to the user interface technology new object standards emerged such as CORBA and Java. Internally at SAP, the Workflow team created the Business Object Repository to wrap all existing R/3 transactional logic into a hierarchy of Business Object types, methods and events that could generically be used in Workflow definitions. The SAPGUI team had demonstrated that sophisticated GUI controls (based on the OCX specification) could be embedded into the GUI screen using OLE automation as programmatic interface.
Consequently, SAP decided to start a new development project to add object orientation to the existing ABAP/4 language and programming environment. The approach was very pragmatic: ABAP classes should be able to use all the existing ABAP/4 language elements such as internal tables, both in the implementation logic but also on the structural level. Objects were consistently treated as references following the Java design approach. The advantage of this approach was clear: introduce object orientation as a major programming methodology to improve interfacing, software contracts etc without loosing the interoperability to traditional 4GL constructs in ABAP such as SQL and the corresponding data types in ABAP. ABAP developers could incrementally make themselves familiar with object oriented principles. It was not intended to convert all existing SAP software layers (e.g. classical Dynpro, Dictionary, RFC) into a purely object oriented design philosophy. The runtime environment (class loading, garbage collection) was heavily optimized for optimal performance.
Object orientation was immediately used to build complex frameworks such as the new GUI controls. GUI controls could be freely embedded in and docked to Dynpros. The event logic of the new controls was implemented using event handler classes of ABAP Objects.
For the ABAP Workbench ABAP Objects and the UI controls greatly helped to refine the user interface using tree controls for the object lists, edit controls for the ABAP editor etc. The central Workbench manager is a good example of object-oriented design: It invokes the various Workbench tools through well-defined interfaces and keeps track of the user navigation. Due to its new design the Workbench also served as a role model for the R/3 applications. In a joint project in 1999 (enjoySAP) the R/3 applications adopted the new graphical capabilities which they could see and study in their tooling environment.
The Enterprise Portal
Meanwhile a new concept emerged from the Internet that strongly influenced the technical evolution. Web sites were not only a nice collection of HTML pages containing text, pictures and links to other pages. Instead, the idea of a Workplace was born allowing the end user to customize and personalize the appearance and behaviour of a web presence to the end user’s needs. Web sites like Yahoo allowed to adapt and change the standard layout of their home page and offered a portal to their web applications and content.
It is interesting to note that SAP had already pioneered an early personalized, role based access with a SAP GUI companion called the Session Manager. This frontend managed the sessions spreading multiple R/3 systems with a central user access. Now, the Internet browser should be the central point of access with seamless access into any backend system using single-sign-on. SAP delivered the mySAP Workplace based on the Internet transaction Server offering a browser-based access with drag and relate capabilities. However, the market demanded a solution on more open standards. Therefore, SAP started the Enterprise Portal project and acquired a J2EE server for the implementation. In the following the SAP board heavily pushed the adoption of Java technology. The SDN (SAP developer network) was kicked off to build a community for sharing knowledge and helping each other. SAP showed up at the JavaOne conference in San Francisco joining the various standardization committees of the Java community.
SAP Web Application Server
To participate in the rapid evolution of Internet technologies it was very important not to fall behind. Consequently, a project was started to offer direct support of HTTP in the ABAP Kernel. The ICMan (Internet communication manager) would handle incoming HTTP requests based on a multi-threaded implementation approach and forward the execution to the R/3 basis. The Internet communication framework (ICF) served to configure and map incoming URLs to their supporting HTTP handler class. A suitable web programming model was in need and Business Server Pages (BSP) were offered that rendered HTML pages based on embedded programmatic logic in ABAP. For the first time in history the R/3 basis was delivered independently of the R/3 applications as the SAP Web Application Server (Release 6.10). Another important necessary precondition to play in the Internet arena was the Unicode enablement of ABAP which took place in parallel.
In 2004 SAP introduced SAP NetWeaver to the market as the technology platform for people integration (Enterprise Portal), information integration (Business Warehouse), and Process Integration. The NetWeaver usage types were running on top of the NetWeaver application servers ABAP and Java. From a life cycle management perspective it was desirable to manage and monitor both stacks in parallel in a dual stack setup. Later this setup was dropped to allow for a more independent evolution of the stacks.
First ideas to enrich the page-oriented web development models led to the concept of Web Dynpro: Combine the original dynpro capabilities such as layout and design, input validation, data binding and navigation with the rendering capabilities of modern web browsers. The NetWeaver Developer Studio was introduced for Java development based on Eclipse allowing developers to take benefit of a native developer experience powered by the creativity of the Eclipse ecosystem. The tool infrastructure was accompanied by lifecycle management infrastructure consisting of a designtime repository, component build server including transport mechanism making the Java infrastructure ready for enterprise scale.
In the meantime, the ABAP stack introduced a series of innovations such as support for Web Dynpro ABAP which was conceptually equivalent to the Java variant but properly embedded into the ABAP Workbench. ABAP debugging was significantly enhanced by the introduction of a 2-process debugger which separated debugger and debuggee into two separate work processes. In addition, a new ABAP editor was introduced supporting syntax coloring and code completion. Internet technologies such as XML and XSLT (CALL TRANSFORMATION) were included into the ABAP development model. The syntax of ABAP was enhanced offering expressions and powerful operators as well as inline declarations which leads to more compact and concise code.
SAP Business Suite
Soon after the introduction of SAP NetWeaver the new platform was adopted by the SAP Business Suite. The Business Suite adopted the Java stack to deliver a new generation of ESS and MSS scenarios. The Business Suite content was integrated into the Enterprise Portal, but the core implementation remained on the ABAP backend. To deliver innovations without disrupting the core business processes new Suite deliveries were bundled into enhancement packages that could selectively be activated at the customer. In parallel the SAP board decided to reintegrate the industry solutions into the core ERP. Traditionally industry solutions were developed in parallel to the ERP core. Some of the industry solutions like IS-OIL had modified the core which led to a tremendous amount of adaptation efforts for each release delivery. The switch and enhancement framework was introduced to maintain all industry solutions directly in the core and activate the desired industry flavor in a given customer installation.
On the tool side ABAP in Eclipse was introduced with tool support for repository access, editing ABAP programs and classes and ABAP debugging from the very beginning thanks to the 2-process debugging interface. The coverage of ABAP artefacts with native editors has increased continually with an embedded SAP GUI as fallback option.
SAP HANA and SAP S/4HANA
The introduction of SAP HANA was probably the most important milestone in recent years for the further evolution of the ABAP technology stack. ABAP’s Open SQL was always optimized for the various database platforms but had to follow a least common denominator approach to be 100% portable. With SAP HANA and the decision to develop SAP S/4HANA on top ABAP could leverage the underlying HANA capabilities to the maximum extent. The idea to introduce a virtual data model for S/4HANA based on so-called core data services was a major innovation driver. Core data services were represented in a new syntax based on SQL and allowed to establish a semantic data model that could be investigated without writing actual ABAP code like in the traditional Business Suite. CDS entities could refer to each other by means of associations and could be annotated and exposed as OData services for consumption in Fiori template applications. The core data services also form the basis for the ABAP RESTful application programming model (RAP) which includes transactional services, locking, draft support and many other features on top.
Steampunk and the Future of ABAP
After this long journey we have finally arrived in the here and now. The most recent innovation with a lot of potential for the future was the enablement of the ABAP stack for SAP BTP (project Steampunk). With Steampunk (official brand: SAP BTP ABAP Environment) customers and partners can build Cloud applications and loosely coupled side-by-side extensions for SAP’s flagship solutions S/4HANA and S/4HANA Cloud. With the Embedded Steampunk approach tightly coupled extensions can be built that run directly on top of the S/4HANA Cloud technology stack using public local APIs offered by the S/4HANA business objects. They are upgrade-safe avoiding the typical adaptation efforts that can occur in classical ABAP developments. In conjunction with the well-known key user extensibility customers and partners can combine these extensibility options to build applications and extensions in ABAP that are ready for the Cloud and fully optimized for SAP HANA. The ABAP RESTful Application Programming Model (RAP) is at the heart of each application development and extension project.
I hope you liked this journey and did not get completely lost under way, thanks a lot for your patience. I could only strive the major milestones and inflection points that had a strong influence on the evolution of the ABAP technology. Topics such as lifecycle management, monitoring, reuse services etc play a substantial part in any ABAP project. If I missed an important point here, please jump in and comment. Evolutionary processes have many different facets and perspectives. I put the emphasis on the period which is probably less known to the younger fans in the ABAP developer community. The creativity of developers and architects have made the ABAP stack what it is today: a thorough foundation for S/4HANA and S/4HANA Cloud with a very strong focus on supportability and extensibility at enterprise scale. ABAP has evolved and mastered the technological challenges over the last decades. It was, is and continues to be a major pillar in SAP’s technology portfolio for the years to come.
Thanks Karl for the outline! Happy to be on board here with MDG!
Agreed very very nice summary.
Thanks to IBM's mainframe VM/CMS system (open source code from 1967 or so) later used and sold by VMware I can now easily run multiple ABAP demo versions on my home PC. Maybe you can get that old R/2 system back up and running for a fun project, too. (CICS runs under VM).
N.B. the word that you want is "losing" and not "loosing". Personal pet peeve of mine.
Many thanks, Karl. How did you manage to get the screenshots from those vintage systems?
Valid question, Guido.
I used all resources I could get: old conference and documentation CDs, an old running 4.0 mini basis, articles, brochures, PPTs etc.
I was awaiting for this blog post after watching video on 'ABAP – Past, Present & Future' from Karl Kessler and Team last week. And now we have it documented for the generations
Great work and contribution to SAP community.
Amazing journey, congrat's !
Excellent Blog. Long live ABAP!
Amazing journey, Viva ABAP !
Thank you it was very interesting!
Thanks for that history, really enjoyed it.
I started in 2001 as an ABAP Developer so I heard a fair amount of this info from more senior developers. It was nice to see it written down like this. I think there might even be a book in there. 🙂
Very interesting post, thank you.
But I have a question after read it about the new ABAP development model on SAP Rise and maybe someone here could help me. Is it possible to deploy new customized solutions in a S/4HANA Cloud without using the extensibility tools?
I love history! What a great history of ABAP! Thanks Karl.
Thinking of the days when Steampunk, Fiori and eclipse will look as outdated as the 1990s SAPGUI... 😅
Thanks for this awesome blog. There's a lot of work to be done to set the foundation for next 50 years. Really happy that ABAP now has it's own space.
With best wishes,
Prasenjit Singh Bist
I started ABAP programming at the same time you did and I remember the switch from Cobol on Siemens mainfraim to ABAP in R/2 was a real wau experience and the switch to R/3 was incredible.
I also remember a time about 15-20 years ago, when the rumors said that ABAP was dead and the future was Java.
I must admit that I have been skeptical about new tools like CDS, Fiori and RAP - and why on earth put ABAP in Eclipse!
Now with your historical perspective I suddenly realize - of course ABAP must evolve. If we were stuck with ABAP from 1992 it was dead many years ago.
In the times in early 2000s as you mention, it was not only rumours about the soon end of ABAP.
Beside the push from board, like Karl says, there were also several activities to increase the relevance of Java: hiring Java developers, educating Java to ABAP developers, attempts to bring the ABAP and Java languages closer together on the technical level, like the VM Container and also the SAP own Java Virtual Machine.
I think, now we are lucky to still have the strong and stable ABAP code base and also community on one side, but also a wider choice of languages in the cloud not limited to Java as well.
The evolution goes on 😉
I really enjoyed this reading. Tnx.
Such a joy to read, and so well written, thanks Karl. This brings back many memories for me. I started on an SAP R/2 system at a customer (Esso Petroleum) in the UK in 1987 and mostly worked on R/2 in assembler. I remember the advent of ABAP for us there and it was indeed exactly how you describe it, as a report writing language (that you fed in to batch programs as "data" provided via the SYSIN DD cards in the JCL).
I also remember calling ABAP routines from the assembler that powered the transactions; in fact, I remember building an extension to an RK (CO in R/3 terms) transaction by jumping from assembler to ABAP and back; I did this as a sort of favour for a female colleague that I ended up becoming very good friends with (ahem) and it made it into production too.
Anyway, thanks again for compiling this in such great detail.
dj (aka "Q-MACRO")
This is similar to my start in October 1988, @dj.adams.sap. Made my first ABAP development with the first release of the data dictionary in R/2 4.3c and CPIC (another new technology at this time) to exchange working plans to PCs and vice versa. The next project was to modify transaction TE21 (today ME21N) in SAP Assembler to make it possible to copy existing purchase orders. Then an ABAP report to mass change material master data using READ LINE ... SY-LISEL .... Horrible! But it worked :).
Thank you for this time travel. I have been part of the ABAP team since R/2 4.2. - And I still like to do that very much!
Thanks for you contribution to the ABAP legacy Karl.
It's actually a nice story manuscript for the young ABAP developers.
Knowing the roots and history of the platform is something great and intersting as it makes you think about how strange and futuristic must have been each phase of evolution to the people working with SAP at the time, and makes you wonder what is expecting us ahead.
Thank you Karl !! This is great, for someone who has started working with ABAP few years back the context and history really helps. I am excited about the future of ABAP !!
I did not get to work in R/2 but in wang teams with cobol that was similar
Thank you Karl! great !
I'm wondering if you have always a running system R/2 to be able to make print screen of these Green/Black screen!! ( that I use to see!).
Thanks Karl, great blog!
You omitted one point though: with the introduction of the "nice and fancy" enjoy controls one lost the possibility to re-connect to an existing user session after the connection between SAP GUI and server was lost due to network issues. I was always fascinated watching the lost GUI windows popping up again automatically at the screen exactly at the point where they had been when the network broke down. A feature I have never seen again anywhere else up to today!
Yes, I was also really sorry to lose that option, but on the other hand, loosing network connection happened much more often in those days.
Thanks for the trip down memory lane, Karl!
I didn't start with ABAP until '97, straight onto R/3 2.2D, so it was great to see some screenshots of the old debugger from then and being reminded of field groups (uurgh!). Fast forward to 2007 and I was fully into WDA which I really enjoyed and now like many I have high hopes for Steampunk and eSteampunk. Will ABAP ever feature in Kyma with serverless functions perhaps?!
Great blog and outlining the history Karl Kessler ! For millennials this should certainly be a holy guide on the evolution not just on ABAP but technology as a whole. Very well articulated.
Hello Karl Kessler
Ist is still amazing what ABAP (Allgemeiner Bericht Aufbereitung Prozessor) did a journey no one would estimated before. Like the ITS (Internet Transaction Server) which was dead before born, showed that it last forever, when Rüdiger Kretschmer showed my the technology the first time.
Unfortunately, my ABAP knowledge is limited by using tx. SNOTE and CTRL-H ... 😉
Like the "Peter-Principle" tells us: Everyone/thing is reaching finally it place of inability of use. We (SAP) call this "Steampunk" or (official brand: SAP BTP ABAP Environment).
Yet, another SAP Cloud in the Sky ... Blog - why SAP BW/4HANA?
All the best Roland
Nice work! It's good to remember that! I'm convinced that ADT is much better than SE80, but I have to confess that I kind of miss the SE80 days...
What a journey for ABAP! I taught ABAP classes from 2007 and 2013, and I didn't have even one class which some student asked me about the dead of ABAP of if ABAP will be replaced by Java.
ABAP today: in your face 🙂
Long live to the Chief!
A very nice read. Feels a bit like browsing the family album 😉
Great for me: you taught me the first concepts of ABAP and R/3 when I started, now you bring me this nice history lesson. Danke!
Really enjoy the reading, thanks for sharing Karl!
Hi Karl. Great article. It was nice to see some of my own history with ABAP (kernel, ABAP Objects) in the blog and to remember the old times when we worked together.
ABAP is alive and well and moving forward!
Respect for the effort you put into this blog. Very impressive!
Honestly, I had forgotten about saptemu despite using it. In my team, we called it "3270 with push-buttons".
Thanks for capturing this remarkable journey!
Nice blog, but help, I worked with all the products and recognize the different screens you showed in this blog. Starting with R/2 4.4 and just did a steampunk implementation.
I'm getting old, man
Thanks! Very helpful!