ABAP (Advanced Business Application Programming, originally Allgemeiner Berichts-Aufbereitungs-Prozessor = general report creation processor) is a high level programming language created by the German software company SAP. It is currently positioned, alongside the more recently introduced Java, as the language for programming SAP’s Web Application Server, part of its NetWeaver platform for building business applications. Its syntax is somewhat similar to COBOL.History
ABAP is one of the many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of “generic report preparation processor”, but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
The ABAP programming language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP’s applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
SAP’s most recent development platform, NetWeaver, supports both ABAP and Java.
Where does the ABAP program run?
All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and ed with the ABAP Workbench tools, and generated code, a binary representation somewhat comparable with Java bytecode. ABAP programs execute under the control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button). A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements (”Open SQL”) into statements understood by the underlying DBMS (”Native SQL”). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of frequently accessed data in the local memory of the application server.
SAP has three different layers as presentation layer (GUI), application layer (programs run on this) and data base layer where all data is stored and retrieved from user driven conditions,commands given by end user programmer through presentation layer.
The ABAP language environment, including the syntax checking, code generation and runtime system, is part of the SAP Basis component. SAP Basis is the technological platform that supports the entire range of SAP applications, now typically implemented in the framework of the SAP Web Application Server. In that sense SAP Basis can be seen as the “operating system” on which SAP applications run. Like any operating system, SAP Basis contains both low-level services (for example memory management, database communication or servicing Web requests) and high-level tools for end users and administrators. These tools can be executables (”SAP kernel”) running directly on the underlying operating system, transactions developed in ABAP, or Web-based interfaces.
SAP Basis also provides a layer of abstraction between the business applications and the operating system and database. This ensures that applications do not depend directly upon a specific server or database platform and can easily be ported from one platform to another.
SAP Basis currently runs on UNIX (AIX, HP-UX, Solaris, Linux), Microsoft Windows, i5/OS on IBM System i (formerly iSeries, AS/400) and z/OS on IBM System z (formerly zSeries, S/390). Supported databases are DB2, Informix, MaxDB, Oracle and Microsoft SQL Server (support for Informix was discontinued in SAP Basis release 7.00).
SAP systems and landscapes
All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers (”instances”) accessing the data and programs in this database. A SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.
Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.
The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.
The normal way of executing ABAP code in the SAP system is by entering a transaction code. Transactions can be accessed via system-defined or user-specific, role-based menus. They can also be started by entering their transaction code (a mnemonic name of up to 20 characters) in the special command field, which is present in every SAP screen. Transactions can also be invoked programmatically by means of the ABAP statements CALL TRANSACTION and LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction. The term “transaction” must not be misunderstood here: in the context just described, a transaction simply means calling and executing an ABAP program. In application programming, “transaction” often refers to an indivisible operation on data, which is either committed as a whole or undone (rolled back) as a whole. This concept exists in SAP but is there called a LUW (Logical Unit of Work). In the course of one transaction (program execution), there can be different LUWs.
Let’s have a look at the different kind of transactions:
These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.
In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.
In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.
A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT—more to come on that.
A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.