Introduction
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 in an RFM function brochure
Purchase Order screen in RFM
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.
R/2 Data Dictionary
ABAP/4 Debugging in R/2
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.
Saptemu
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.
SAP GUI for Windows
ABAP/4 Debugger in R/3
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.
ABAP/4 Development Workbench - Repository Browser
ABAP/4 Debugger in R/3
Where-used list
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.
The Internet
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.
Object orientation
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 new design of the ABAP Workbench
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.
SAP NetWeaver
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.
2-process debugger
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.
SAP S/4HANA Cloud ABAP Environment (Embedded Steampunk)
- SAP Managed Tags:
43 Comments
