ABAP · Lablypedia

ABAP was originally an acronym for Allgemeiner Berichts-Aufbereitungs-Prozessor ("generic report preparation processor" in German), but was rebranded as Advanced Business Application Programming in 1996.

ABAP was advertised as fourth-generation programming language (4GL). 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.

The ABAP 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 was geared towards more technical customers with programming experience.

ABAP remains as 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 current development platform NetWeaver supports both ABAP and Java.

ABAP has an abstraction between the business applications, 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 Netweaver 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 HANA, SAP ASE (formerly Sybase), IBM Db2, Informix, MaxDB, Oracle, and Microsoft SQL Server (support for Informix was discontinued in SAP Basis release 7.00).

ABAP Runtime Environment

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 edited 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); in this respect it can be seen as a Virtual Machine comparable with the Java VM. 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 tables and frequently accessed data in the local memory of the application server.

SAP Systems and Landscapes

All SAP data exists and all SAP software runs in the context of a 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' knowledge 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, which is called "SAP GUI", or via a Web browser.

Software Layers

ABAP software is deployed in software components. Examples for these are:

SAP_BASIS is the technical base layer which is required in every ABAP system.
SAP_ABA contains functionalities which is required for all kinds of business applications, like business partner and address management.
SAP_UI provides the functionality to create SAP UI5 applications.
BBPCRM is an example for a business application, in this case the CRM application

10 more chapters are free with a Lably account.

Transactions

A transaction in SAP terminology is the execution of a program. The normal way of executing ABAP code in the SAP system is by entering a transaction code (for instance, VA01 is the transaction code for "Create Sales Order"). The common transaction codes (T-codes) used by ABAP developer are SE38, SE09, SE10, SE24, SE11, SE16N, SE80, SE37, ST22 etc. Transactions can be called via system-defined or user-specific, role-based menus. They can also be started by entering the transaction code directly into a 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. The general notion of a transaction is called a Logical Unit of Work (LUW) in SAP terminology.

Types of ABAP programs

As in other programming languages, an ABAP program is either an executable unit or a library, which provides reusable code to other programs and is not independently executable.

ABAP distinguishes two types of executable programs:

Reports
Module pools

Reports follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g., a selection over a subSET of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The term "report" can be somewhat misleading in that reports can also be designed to modify data; the reason why these programs are called reports is the "list-oriented" nature of the output they produce.

Module pools define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the user sees. Each screen also has a "flow logic", which refers to the ABAP code implicitly invoked by the screens, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its flow logic.

The non-executable program types are:

INCLUDE modules – These get included at generation time into the calling unit; it is often used to subdivide large programs.
Subroutine pools – These contain ABAP subroutines (blocks of code enclosed by FORM/ENDFORM statements and invoked with PERFORM).
Function groups – These are libraries of self-contained function modules (enclosed by FUNCTION/ENDFUNCTION and invoked with CALL FUNCTION).
Object classes – These are similar to Java classes and interfaces; the first define a set of methods and attributes, the second contain "empty" method definitions, for which any class implementing the interface must provide explicit code.
Interfaces – Same as object classes
Type pools – These define collections of data types and constants.

ABAP programs are composed of individual sentences (statements). The first word in a statement is called an ABAP keyword. Each statement ends with a period. Words must always be separated by at least one space. Statements can be indented as you wish. With keywords, additions and operands, the ABAP runtime system does not differentiate between upper and lowercase.

Statements can extend beyond one line. You can have several statements in a single line (though this is not recommended). Lines that begin with asterisk * in the first column are recognized as comment lines by the ABAP runtime system and are ignored. Double quotations marks (") indicate that the remainder of a line is a comment.

Development environment

There are two possible ways to develop in ABAP. The availability depends on the release of the ABAP system.

ABAP Workbench

The ABAP Workbench is part of the ABAP system and is accessed via SAP GUI. It contains different tools for editing programs. The most important of these are (transaction codes are shown in parentheses):

ABAP Editor for writing and editing reports, module pools, includes and subroutine pools (SE38)
ABAP Dictionary for processing database table definitions and retrieving global types (SE11)
Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment) (SE41)
Screen Painter, a screen generator for designing screens and flow logic (SE51)
Function Builder for function modules (SE37)
Class Builder for ABAP Objects classes and interfaces (SE24)

The Object Navigator (transaction SE80) provides a single integrated interface into these various tools.

ABAP Development Tools

The ABAP Development Tools (ADT), formally known as "ABAP in Eclipse", is a set of plugins for the Eclipse IDE to develop ABAP objects.

In this scenario, the ABAP developer installs the required tools on their computer and works locally, whereas a continuous synchronization with the backend is performed.

ABAP Dictionary

The ABAP Dictionary contains all metadata about the data in the SAP system. It is closely linked with the ABAP Workbench in that any reference to data (e.g., a table, a view, or a data type) will be obtained from the dictionary. Developers use the ABAP Dictionary transactions (directly or through the SE80 Object Navigator inside the ABAP Workbench) to display and maintain this metadata.

When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.

A brief description of the most important types of dictionary objects follows:

Tables are data containers that exist in the underlying relational database. In the majority of cases there is a 1-to-1 relationship between the definition of a table in the ABAP Dictionary and the definition of that same table in the database (same name, same columns). These tables are known as "transparent". There are two types of non-transparent tables: "pooled" tables exist as independent entities in the ABAP Dictionary but they are grouped together in large physical tables ("pools") at the database level. Pooled tables are often small tables holding for example configuration data. "Clustered" tables are physically grouped in "clusters" based on their primary keys; for instance, assume that a clustered table H contains "header" data about sales invoices, whereas another clustered table D holds the invoice line items. Each row of H would then be physically grouped with the related rows from D inside a "cluster table" in the database. This type of clustering, which is designed to improve performance, also exists as native functionality in some, though not all, relational database systems.
Indexes provide accelerated access to table data for often used selection conditions. Every SAP table has a "primary index", which is created implicitly along with the table and is used to enforce primary key uniqueness. Additional indexes (unique or non-unique) may be defined; these are called "secondary indexes".
Views have the same purpose as in the underlying database: they define subsets of columns (and/or rows) from one or – using a join condition – several tables. Since views are virtual tables (they refer to data in other tables) they do not take a substantial amount of space.
Structures are complex data types consisting of multiple fields (comparable to struct in C/C++).
Data elements provide the semantic content for a table or structure field. For example, dozens of tables and structures might contain a field giving the price (of a finished product, raw material, resource, ...). All these fields could have the same data element "PRICE".
Domains define the structural characteristics of a data element. For example, the data element PRICE could have an assigned domain that defines the price as a numeric field with two decimals. Domains can also carry semantic content in providing a list of possible values. For example, a domain "BOOLEAN" could define a field of type "character" with length 1 and case-insensitive, but would also restrict the possible values to "T" (true) or "F" (false).
Search helps (successors to the now obsolete "matchcodes") provide advanced search strategies when a user wants to see the possible values for a data field. The ABAP runtime provides implicit assistance (by listing all values for the field, e.g. all existing customer numbers) but search helps can be used to refine this functionality, e.g. by providing customer searches by geographical location, credit rating, etc.
Lock objects implement application-level locking when changing data.

ABAP syntax

This brief description of the ABAP syntax begins with the ubiquitous "Hello".

Hello world

<span id="mw3A"></span><span class="k" id="mw3Q">REPORT</span><span class="w" id="mw3g"> </span><span class="nv" id="mw3w">TEST</span><span class="p" id="mw4A">.</span> <span class="k" id="mw4Q">WRITE</span><span class="w" id="mw4g"> </span><span class="s1" id="mw4w">'Hello, World!'</span><span class="p" id="mw5A">.</span>

This example contains two statements: REPORT and WRITE. The program displays a list on the screen. In this case, the list consists of the single line "Hello, World!". The REPORT statement indicates that this program is a report. This program could be a module pool after replacing the REPORT statement with PROGRAM.

Chained statements

Consecutive statements with an identical first (leftmost) part can be combined into a "chained" statement using the chain operator :. The common part of the statements is written to the left of the colon, the differing parts are written to the right of the colon and separated by commas. The colon operator is attached directly to the preceding token, without a space (the same applies to the commas in the token list on, as can be seen in the examples below).

Chaining is often used in WRITE statements. WRITE accepts just one argument, so if for instance you wanted to display three fields from a structure called FLIGHTINFO, you would have to code:

<span id="mw8w"></span><span class="k" id="mw9A">WRITE</span><span class="w" id="mw9Q"> </span><span class="nv" id="mw9g">FLIGHTINFO</span><span class="o" id="mw9w">-</span><span class="nv" id="mw-A">CITYFROM</span><span class="p" id="mw-Q">.</span> <span class="k" id="mw-g">WRITE</span><span class="w" id="mw-w"> </span><span class="nv" id="mw_A">FLIGHTINFO</span><span class="o" id="mw_Q">-</span><span class="nv" id="mw_g">CITYTO</span><span class="p" id="mw_w">.</span> <span class="k" id="mwAQA">WRITE</span><span class="w" id="mwAQE"> </span><span class="nv" id="mwAQI">FLIGHTINFO</span><span class="o" id="mwAQM">-</span><span class="nv" id="mwAQQ">AIRPTO</span><span class="p" id="mwAQU">.</span>

Chaining the statements results in a more readable and more intuitive form:

<span id="mwAQk"></span><span class="k" id="mwAQo">WRITE</span><span class="p" id="mwAQs">:</span><span class="w" id="mwAQw"> </span><span class="nv" id="mwAQ0">FLIGHTINFO</span><span class="o" id="mwAQ4">-</span><span class="nv" id="mwAQ8">CITYFROM</span><span class="p" id="mwARA">,</span><span class="w" id="mwARE"> </span><span class="nv" id="mwARI">FLIGHTINFO</span><span class="o" id="mwARM">-</span><span class="nv" id="mwARQ">CITYTO</span><span class="p" id="mwARU">,</span><span class="w" id="mwARY"> </span><span class="nv" id="mwARc">FLIGHTINFO</span><span class="o" id="mwARg">-</span><span class="nv" id="mwARk">AIRPTO</span><span class="p" id="mwARo">.</span>

In a chain statement, the first part (before the colon) is not limited to the statement name alone. The entire common part of the consecutive statements can be placed before the colon. Example:

<span id="mwAR4"></span><span class="k" id="mwAR8">REPLACE</span><span class="w" id="mwASA"> </span><span class="s1" id="mwASE">'A'</span><span class="w" id="mwASI"> </span><span class="k" id="mwASM">WITH</span><span class="w" id="mwASQ"> </span><span class="s1" id="mwASU">'B'</span><span class="w" id="mwASY"> </span><span class="k" id="mwASc">INTO</span><span class="w" id="mwASg"> </span><span class="nv" id="mwASk">LASTNAME</span><span class="p" id="mwASo">.</span> <span class="k" id="mwASs">REPLACE</span><span class="w" id="mwASw"> </span><span class="s1" id="mwAS0">'A'</span><span class="w" id="mwAS4"> </span><span class="k" id="mwAS8">WITH</span><span class="w" id="mwATA"> </span><span class="s1" id="mwATE">'B'</span><span class="w" id="mwATI"> </span><span class="k" id="mwATM">INTO</span><span class="w" id="mwATQ"> </span><span class="nv" id="mwATU">FIRSTNAME</span><span class="p" id="mwATY">.</span> <span class="k" id="mwATc">REPLACE</span><span class="w" id="mwATg"> </span><span class="s1" id="mwATk">'A'</span><span class="w" id="mwATo"> </span><span class="k" id="mwATs">WITH</span><span class="w" id="mwATw"> </span><span class="s1" id="mwAT0">'B'</span><span class="w" id="mwAT4"> </span><span class="k" id="mwAT8">INTO</span><span class="w" id="mwAUA"> </span><span class="nv" id="mwAUE">CITYNAME</span><span class="p" id="mwAUI">.</span>

could be rewritten in chained form as:

<span id="mwAUY"></span><span class="k" id="mwAUc">REPLACE</span><span class="w" id="mwAUg"> </span><span class="s1" id="mwAUk">'A'</span><span class="w" id="mwAUo"> </span><span class="k" id="mwAUs">WITH</span><span class="w" id="mwAUw"> </span><span class="s1" id="mwAU0">'B'</span><span class="w" id="mwAU4"> </span><span class="k" id="mwAU8">INTO</span><span class="p" id="mwAVA">:</span><span class="w" id="mwAVE"> </span><span class="nv" id="mwAVI">LASTNAME</span><span class="p" id="mwAVM">,</span><span class="w" id="mwAVQ"> </span><span class="nv" id="mwAVU">FIRSTNAME</span><span class="p" id="mwAVY">,</span><span class="w" id="mwAVc"> </span><span class="nv" id="mwAVg">CITYNAME</span><span class="p" id="mwAVk">.</span>

Comments

ABAP has 2 ways of defining text as a comment:

An asterisk (*) in the leftmost column of a line makes the entire line a comment
A double quotation mark (") anywhere on a line makes the rest of that line a comment

Example:

<span id="mwAWU"></span><span class="k" id="mwAWY">REPORT</span><span class="w" id="mwAWc"> </span><span class="nv" id="mwAWg">BOOKINGS</span><span class="p" id="mwAWk">.</span> <span class="c1" id="mwAWo">* Read flight bookings from the database</span> <span class="k" id="mwAWs">SELECT</span><span class="w" id="mwAWw"> </span><span class="o" id="mwAW0">*</span><span class="w" id="mwAW4"> </span><span class="k" id="mwAW8">FROM</span><span class="w" id="mwAXA"> </span><span class="nv" id="mwAXE">FLIGHTINFO</span> <span class="w" id="mwAXI"> </span><span class="k" id="mwAXM">WHERE</span><span class="w" id="mwAXQ"> </span><span class="k" id="mwAXU">CLASS</span><span class="w" id="mwAXY"> </span><span class="o" id="mwAXc">=</span><span class="w" id="mwAXg"> </span><span class="s1" id="mwAXk">'Y'</span><span class="w" id="mwAXo"> </span><span class="c1" id="mwAXs">"Y = economy</span> <span class="w" id="mwAXw"> </span><span class="ow" id="mwAX0">OR</span><span class="w" id="mwAX4"> </span><span class="k" id="mwAX8">CLASS</span><span class="w" id="mwAYA"> </span><span class="o" id="mwAYE">=</span><span class="w" id="mwAYI"> </span><span class="s1" id="mwAYM">'C'</span><span class="p" id="mwAYQ">.</span><span class="w" id="mwAYU"> </span><span class="c1" id="mwAYY">"C = business</span> <span class="p" id="mwAYc">(...)</span>

Spaces

Code in ABAP is whitespace-sensitive.

<span id="mwAYw"></span><span class="nv" id="mwAY0">x</span><span class="w" id="mwAY4"> </span><span class="o" id="mwAY8">=</span><span class="w" id="mwAZA"> </span><span class="nv" id="mwAZE">a</span><span class="o" id="mwAZI">+</span><span class="nv" id="mwAZM">b</span><span class="p" id="mwAZQ">(</span><span class="nv" id="mwAZU">c</span><span class="p" id="mwAZY">).</span>

assigns to variable x the substring of the variable a, starting from b with the length defined by the variable c.

<span id="mwAZo"></span><span class="nv" id="mwAZs">x</span><span class="w" id="mwAZw"> </span><span class="o" id="mwAZ0">=</span><span class="w" id="mwAZ4"> </span><span class="nv" id="mwAZ8">a</span><span class="w" id="mwAaA"> </span><span class="o" id="mwAaE">+</span><span class="w" id="mwAaI"> </span><span class="nv" id="mwAaM">b</span><span class="p" id="mwAaQ">(</span><span class="w" id="mwAaU"> </span><span class="nv" id="mwAaY">c</span><span class="w" id="mwAac"> </span><span class="p" id="mwAag">).</span>

assigns to variable x the sum of the variable a and the result of the call to method b with the parameter c.

ABAP statements

In contrast with languages like C/C++ or Java, which define a limited set of language-specific statements and provide most functionality via libraries, ABAP contains an extensive amount of built-in statements. These statements traditionally used sentence-like structures and avoided symbols, making ABAP programs relatively verbose. However, in more recent versions of the ABAP language, a terser style is possible.

An example of statement based syntax (whose syntax originates in COBOL) versus expression-based syntax (as in C/Java):

<span id="mwAbM"></span><span class="k" id="mwAbQ">ADD</span><span class="w" id="mwAbU"> </span><span class="nv" id="mwAbY">TAX</span><span class="w" id="mwAbc"> </span><span class="k" id="mwAbg">TO</span><span class="w" id="mwAbk"> </span><span class="nv" id="mwAbo">PRICE</span><span class="p" id="mwAbs">.</span> <span class="c1" id="mwAbw">* is equivalent to</span> <span class="nv" id="mwAb0">PRICE</span><span class="w" id="mwAb4"> </span><span class="o" id="mwAb8">=</span><span class="w" id="mwAcA"> </span><span class="nv" id="mwAcE">PRICE</span><span class="w" id="mwAcI"> </span><span class="o" id="mwAcM">+</span><span class="w" id="mwAcQ"> </span><span class="nv" id="mwAcU">TAX</span><span class="w" id="mwAcY"> </span><span class="p" id="mwAcc">.</span>

Data types and variables

ABAP provides a set of built-in data types. In addition, every structure, table, view or data element defined in the ABAP Dictionary can be used to type a variable. Also, object classes and interfaces can be used as types.

The built-in data types are:

Date variables or constants (type D) contain the number of days since January 1, 1 AD. Time variables or constants (type T) contain the number of seconds since midnight. A special characteristic of both types is that they can be accessed both as integers and as character strings (with internal format "YYYYMMDD" for dates and "hhmmss" for times), which can be used for date and time handling. For example, the code snippet below calculates the last day of the previous month (note: SY-DATUM is a system-defined variable containing the current date):

<span id="mwAfE"></span><span class="k" id="mwAfI">DATA</span><span class="w" id="mwAfM"> </span><span class="nv" id="mwAfQ">LAST_EOM</span><span class="w" id="mwAfU"> </span><span class="k" id="mwAfY">TYPE </span><span class="nv" id="mwAfc">D</span><span class="p" id="mwAfg">.</span><span class="w" id="mwAfk"> </span><span class="c1" id="mwAfo">"last end-of-month date</span> <span class="c1" id="mwAfs">* Start from today's date</span> <span class="w" id="mwAfw"> </span><span class="nv" id="mwAf0">LAST_EOM</span><span class="w" id="mwAf4"> </span><span class="o" id="mwAf8">=</span><span class="w" id="mwAgA"> </span><span class="nv" id="mwAgE">SY</span><span class="o" id="mwAgI">-</span><span class="nv" id="mwAgM">DATUM</span><span class="p" id="mwAgQ">.</span> <span class="c1" id="mwAgU">* Set characters 6 and 7 (0-relative) of the YYYYMMDD string to "01",</span> <span class="c1" id="mwAgY">* giving the first day of the current month</span> <span class="w" id="mwAgc"> </span><span class="nv" id="mwAgg">LAST_EOM</span><span class="o" id="mwAgk">+</span><span class="mi" id="mwAgo">6</span><span class="p" id="mwAgs">(</span><span class="mi" id="mwAgw">2</span><span class="p" id="mwAg0">)</span><span class="w" id="mwAg4"> </span><span class="o" id="mwAg8">=</span><span class="w" id="mwAhA"> </span><span class="s1" id="mwAhE">'01'</span><span class="p" id="mwAhI">.</span> <span class="c1" id="mwAhM">* Subtract one day</span> <span class="w" id="mwAhQ"> </span><span class="nv" id="mwAhU">LAST_EOM</span><span class="w" id="mwAhY"> </span><span class="o" id="mwAhc">=</span><span class="w" id="mwAhg"> </span><span class="nv" id="mwAhk">LAST_EOM</span><span class="w" id="mwAho"> </span><span class="o" id="mwAhs">-</span><span class="w" id="mwAhw"> </span><span class="mi" id="mwAh0">1</span><span class="p" id="mwAh4">.</span> <span class="w" id="mwAh8"> </span><span class="k" id="mwAiA">WRITE</span><span class="p" id="mwAiE">:</span><span class="w" id="mwAiI"> </span><span class="s1" id="mwAiM">'Last day of previous month was'</span><span class="p" id="mwAiQ">,</span><span class="w" id="mwAiU"> </span><span class="nv" id="mwAiY">LAST_EOM</span><span class="p" id="mwAic">.</span>

All ABAP variables have to be explicitly declared in order to be used. They can be declared either with individual statements and explicit typing or, since ABAP 7.40, inline with inferred typing.

Explicitly typed declaration

Normally all declarations are placed at the top of the code module (program, subroutine, function) before the first executable statement; this placement is a convention and not an enforced syntax rule. The declaration consists of the name, type, length (where applicable), additional modifiers (e.g. the number of implied decimals for a packed decimal field) and optionally an initial value:

<span id="mwAi8"></span><span class="c1" id="mwAjA">* Primitive types:</span> <span class="k" id="mwAjE">DATA</span><span class="p" id="mwAjI">:</span><span class="w" id="mwAjM"> </span><span class="nv" id="mwAjQ">COUNTER</span><span class="w" id="mwAjU"> </span><span class="k" id="mwAjY">TYPE </span><span class="nv" id="mwAjc">I</span><span class="p" id="mwAjg">,</span> <span class="w" id="mwAjk"> </span><span class="nv" id="mwAjo">VALIDITY</span><span class="w" id="mwAjs"> </span><span class="k" id="mwAjw">TYPE </span><span class="nv" id="mwAj0">I</span><span class="w" id="mwAj4"> </span><span class="k" id="mwAj8">VALUE</span><span class="w" id="mwAkA"> </span><span class="mi" id="mwAkE">60</span><span class="p" id="mwAkI">,</span> <span class="w" id="mwAkM"> </span><span class="nv" id="mwAkQ">TAXRATE</span><span class="p" id="mwAkU">(</span><span class="mi" id="mwAkY">3</span><span class="p" id="mwAkc">)</span><span class="w" id="mwAkg"> </span><span class="k" id="mwAkk">TYPE </span><span class="nv" id="mwAko">P</span><span class="w" id="mwAks"> </span><span class="k" id="mwAkw">DECIMALS</span><span class="w" id="mwAk0"> </span><span class="mi" id="mwAk4">1</span><span class="p" id="mwAk8">,</span> <span class="w" id="mwAlA"> </span><span class="nv" id="mwAlE">LASTNAME</span><span class="p" id="mwAlI">(</span><span class="mi" id="mwAlM">20</span><span class="p" id="mwAlQ">)</span><span class="w" id="mwAlU"> </span><span class="k" id="mwAlY">TYPE </span><span class="nv" id="mwAlc">C</span><span class="p" id="mwAlg">,</span> <span class="w" id="mwAlk"> </span><span class="nv" id="mwAlo">DESCRIPTION</span><span class="w" id="mwAls"> </span><span class="k" id="mwAlw">TYPE </span><span class="nv" id="mwAl0">STRING</span><span class="p" id="mwAl4">.</span> <span class="c1" id="mwAl8">* Dictionary types:</span> <span class="k" id="mwAmA">DATA</span><span class="p" id="mwAmE">:</span><span class="w" id="mwAmI"> </span><span class="nv" id="mwAmM">ORIGIN</span><span class="w" id="mwAmQ"> </span><span class="k" id="mwAmU">TYPE COUNTRY</span><span class="p" id="mwAmY">.</span> <span class="c1" id="mwAmc">* Internal table:</span> <span class="k" id="mwAmg">DATA</span><span class="p" id="mwAmk">:</span><span class="w" id="mwAmo"> </span><span class="nv" id="mwAms">T_FLIGHTS</span><span class="w" id="mwAmw"> </span><span class="k" id="mwAm0">TYPE TABLE OF</span><span class="w" id="mwAm4"> </span><span class="nv" id="mwAm8">FLIGHTINFO</span><span class="p" id="mwAnA">,</span> <span class="w" id="mwAnE"> </span><span class="nv" id="mwAnI">T_LOOKUP</span><span class="w" id="mwAnM"> </span><span class="k" id="mwAnQ">TYPE HASHED TABLE OF</span><span class="w" id="mwAnU"> </span><span class="nv" id="mwAnY">FLT_LOOKUP</span><span class="p" id="mwAnc">.</span> <span class="c1" id="mwAng">* Objects:</span> <span class="k" id="mwAnk">DATA</span><span class="p" id="mwAno">:</span><span class="w" id="mwAns"> </span><span class="nv" id="mwAnw">BOOKING</span><span class="w" id="mwAn0"> </span><span class="k" id="mwAn4">TYPE REF TO</span><span class="w" id="mwAn8"> </span><span class="nv" id="mwAoA">CL_FLT_BOOKING</span><span class="p" id="mwAoE">.</span>

Notice the use of the colon to chain together consecutive DATA statements.

Inline declaration

Since ABAP 7.40, variables can be declared inline with the following syntax:

<span id="mwAos"></span><span class="k" id="mwAow">DATA</span><span class="p" id="mwAo0">(</span><span class="nv" id="mwAo4">variable_name</span><span class="p" id="mwAo8">)</span><span class="w" id="mwApA"> </span><span class="o" id="mwApE">=</span><span class="w" id="mwApI"> </span><span class="s1" id="mwApM">'VALUE'</span><span class="p" id="mwApQ">.</span>

For this type of declaration it must be possible to infer the type statically, e.g. by method signature or database table structure.

This syntax is also possible in OpenSQL statements:

<span id="mwApo"></span><span class="k" id="mwAps">SELECT</span><span class="w" id="mwApw"> </span><span class="o" id="mwAp0">*</span><span class="w" id="mwAp4"> </span><span class="k" id="mwAp8">FROM</span><span class="w" id="mwAqA"> </span><span class="nv" id="mwAqE">ekko</span><span class="w" id="mwAqI"> </span><span class="k" id="mwAqM">into</span><span class="w" id="mwAqQ"> </span><span class="err" id="mwAqU">@</span><span class="nv" id="mwAqY">DATA</span><span class="p" id="mwAqc">(</span><span class="nv" id="mwAqg">lt_ekko</span><span class="p" id="mwAqk">)</span><span class="w" id="mwAqo"> </span><span class="k" id="mwAqs">WHERE</span><span class="w" id="mwAqw"> </span><span class="nv" id="mwAq0">ebeln</span><span class="w" id="mwAq4"> </span><span class="ow" id="mwAq8">EQ</span><span class="w" id="mwArA"> </span><span class="err" id="mwArE">@</span><span class="nv" id="mwArI">lv_ebeln</span><span class="p" id="mwArM">.</span>

ABAP Objects

The ABAP language supports object-oriented programming, through a feature known as "ABAP Objects". This helps to simplify applications and make them more controllable.

ABAP Objects is fully compatible with the existing language, so one can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs. Syntax checking is stronger in ABAP Objects programs, and some syntactical forms (usually older ones) of certain statements are not permitted.

Objects form a capsule which combines the character to the respective behavior. Objects should enable programmers to map a real problem and its proposed software solution on a one-to-one basis. Typical objects in a business environment are, for example, ‘Customer’, ‘Order’, or ‘Invoice’. From Release 3.1 onwards, the Business Object Repository (BOR) of SAP Web Application Server ABAP has contained examples of such objects. The BOR object model will be integrated into ABAP Objects in the next Release by migrating the BOR object types to the ABAP class library. A comprehensive introduction to object orientation as a whole would go far beyond the limits of this introduction to ABAP Objects. This documentation introduces a selection of terms that are used universally in object orientation and also occur in ABAP Objects. In subsequent sections, it goes on to discuss in more detail how these terms are used in ABAP Objects. The end of this section contains a list of further reading, with a selection of titles about object orientation.

Objects are instances of classes. They contain data and provide services. The data forms the attributes of the object. The services are known as methods (also known as operations or functions). Typically, methods operate on private data (the attributes, or state of the object), which is only visible to the methods of the object. Thus the attributes of an object cannot be changed directly by the user, but only by the methods of the object. This guarantees the internal consistency of the object.
Classes describe objects. From a technical point of view, objects are runtime instances of a class. In theory, any number of objects based on a single class may be created. Each instance (object) of a class has a unique identity and its own set of values for its attributes.
Object References are unique addresses that may be used to identify and point to objects in a program. Object references allow access to the attributes and methods of an object.

In object-oriented programming, objects usually have the following properties:

Encapsulation – Objects restrict the visibility of their resources (attributes and methods) to other users. Every object has an interface, which determines how other objects can interact with it. The implementation of the object is encapsulated, that is, invisible outside the object itself.
Inheritance – An existing class may be used to derive a new class. Derived classes inherit the data and methods of the superclass. However, they can overwrite existing methods, and also add new ones.
Polymorphism – Identical (identically named) methods behave differently in different classes. In ABAP Objects, polymorphism is implemented by redefining methods during inheritance and by using constructs called interfaces.

CDS Views

The ABAP Core Data Services (ABAP CDS) are the implementation of the general CDS concept for AS ABAP. ABAP CDS makes it possible to define semantic data models on the central database of the application server. On AS ABAP, these models can be defined independently of the database system. The entities of these models provide enhanced access functions when compared with existing database tables and views defined in ABAP Dictionary, making it possible to optimize Open SQL-based applications. This is particularly clear when an AS ABAP uses a SAP HANA database, since its in-memory characteristics can be implemented in an optimum manner.

The data models are defined using the data definition language (DDL) and data control language (DCL) provided in the ABAP CDS in the ABAP CDS syntax. The objects defined using these languages are integrated into ABAP Dictionary and managed here too.

CDS source code can only be programmed in the Eclipse-based ABAP Development Tools (ADT). The Data Definition Language (DDL) and the Data Control Language (DCL) use different editors.

Features

Internal tables in ABAP

Internal tables are an important feature of the ABAP language. An internal table is defined similarly to a vector of structs in C++ or a vector of objects in Java. The main difference with these languages is that ABAP provides a collection of statements to easily access and manipulate the contents of internal tables. Note that ABAP does not support arrays; the only way to define a multi-element data object is to use an internal table.

Internal tables are a way to store variable data sets of a fixed structure in the working memory of ABAP, and provides the functionality of dynamic arrays. The data is stored on a row-by-row basis, where each row has the same structure.

Internal tables are preferably used to store and format the content of database tables from within a program. Furthermore, internal tables in connection with structures are an important means of defining complex data structures in an ABAP program.

The following example defines an internal table with two fields with the format of database table VBRK.

<span id="mwBDQ"></span><span class="c1" id="mwBDU">* First define structured type</span> <span class="k" id="mwBDY">TYPES</span><span class="p" id="mwBDc">:</span><span class="w" id="mwBDg"> </span><span class="k" id="mwBDk">BEGIN OF</span><span class="w" id="mwBDo"> </span><span class="nv" id="mwBDs">t_vbrk</span><span class="p" id="mwBDw">,</span> <span class="w" id="mwBD0"> </span><span class="nv" id="mwBD4">VBELN</span><span class="w" id="mwBD8"> </span><span class="k" id="mwBEA">TYPE </span><span class="nv" id="mwBEE">VBRK</span><span class="o" id="mwBEI">-</span><span class="nv" id="mwBEM">VBELN</span><span class="p" id="mwBEQ">,</span> <span class="w" id="mwBEU"> </span><span class="nv" id="mwBEY">ZUONR</span><span class="w" id="mwBEc"> </span><span class="k" id="mwBEg">TYPE </span><span class="nv" id="mwBEk">VBRK</span><span class="o" id="mwBEo">-</span><span class="nv" id="mwBEs">ZUONR</span><span class="p" id="mwBEw">,</span> <span class="w" id="mwBE0"> </span><span class="k" id="mwBE4">END OF</span><span class="w" id="mwBE8"> </span><span class="nv" id="mwBFA">t_vbrk</span><span class="p" id="mwBFE">.</span> <span class="c1" id="mwBFI">* Now define internal table of our defined type t_vbrk</span> <span class="k" id="mwBFM">DATA</span><span class="w" id="mwBFQ"> </span><span class="p" id="mwBFU">:</span><span class="w" id="mwBFY"> </span><span class="nv" id="mwBFc">gt_vbrk</span><span class="w" id="mwBFg"> </span><span class="k" id="mwBFk">TYPE STANDARD TABLE OF</span><span class="w" id="mwBFo"> </span><span class="nv" id="mwBFs">t_vbrk</span><span class="p" id="mwBFw">,</span> <span class="w" id="mwBF0"> </span><span class="nv" id="mwBF4">gt_vbrk_2</span><span class="w" id="mwBF8"> </span><span class="k" id="mwBGA">TYPE STANDARD TABLE OF</span><span class="w" id="mwBGE"> </span><span class="nv" id="mwBGI">t_vbrk</span><span class="p" id="mwBGM">.</span><span class="w" id="mwBGQ"> </span><span class="c1" id="mwBGU">"easy to define more tables</span> <span class="c1" id="mwBGY">* If needed, define structure (line of internal table)</span> <span class="c1" id="mwBGc">* Definition with type or with reference to internal table:</span> <span class="k" id="mwBGg">DATA</span><span class="w" id="mwBGk"> </span><span class="p" id="mwBGo">:</span><span class="w" id="mwBGs"> </span><span class="nv" id="mwBGw">gs_vbrk</span><span class="w" id="mwBG0"> </span><span class="k" id="mwBG4">TYPE </span><span class="nv" id="mwBG8">t_vbrk</span><span class="p" id="mwBHA">,</span> <span class="w" id="mwBHE"> </span><span class="nv" id="mwBHI">gs_vbrk_2</span><span class="w" id="mwBHM"> </span><span class="k" id="mwBHQ">LIKE LINE OF</span><span class="w" id="mwBHU"> </span><span class="nv" id="mwBHY">gt_vbrk_2</span><span class="p" id="mwBHc">.</span> <span class="c1" id="mwBHg">* You can also define table type if needed</span> <span class="k" id="mwBHk">TYPES</span><span class="w" id="mwBHo"> </span><span class="nv" id="mwBHs">tt_vbrk</span><span class="w" id="mwBHw"> </span><span class="k" id="mwBH0">TYPE STANDARD TABLE OF</span><span class="w" id="mwBH4"> </span><span class="nv" id="mwBH8">t_vbrk</span><span class="p" id="mwBIA">.</span>

Version History

The following list only gives a rough overview about some important milestones in the history of the language ABAP. For more details, see ABAP – Release-Specific Changes.