Saturday, October 1, 2011

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.

Data and Types

The built-in data types are:

TypeDescription
IInteger (4-bytes)
PPacked decimal
FFloating point
NCharacter numeric
CCharacter
DDate
TTime
XHexadecimal (raw byte)
STRINGVariable-length string
XSTRINGVariable-length raw byte array

ABAP statements – an overview


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 body of built-in statements. These statements often support many options, which explains why ABAP programs look "verbose", especially when compared with programs written in C, C++ or Java.
This section lists some of the most important statements in the language, subdivided by function. Both the statements listed here and the subdivision used are fairly arbitrary and by no means exhaustive.


Declarative statements

These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.
Examples of declarative statements:
TYPES, DATA, CONSTANTS, PARAMETERS, SELECT-OPTIONS, TABLES


Modularization statements

These statements define the processing blocks in an ABAP program.
The modularization statements can be further divided into event statements and defining statements:
Event statements
These are used to define the beginning of event processing blocks. There are no special statements to mark the end of such blocks - they end when the next processing block is introduced.
Examples of event keywords are:
AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND, 
END-OF-SELECTION
Defining statements
These statements delineate callable code units such as subroutines, function modules and methods. The statement marking the end of the unit has the name of the opening statement prefixed with "END".
Examples of defining keywords:
FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION,
MODULE ... ENDMODULE, METHOD ... ENDMETHOD


Control statements

These statements control the flow of the program within a processing block.
Statements controlling conditional execution are:
IF ... ELSEIF ... ELSE ... ENDIF
CASE ... ENDCASE
CHECK
The CHECK statement verifies a condition and exits the current processing block (e.g. loop or subroutine) if the condition is not satisfied.
Several statements exist to define a loop:
DO ... ENDDO
WHILE ... ENDWHILE
LOOP ... ENDLOOP
DO/ENDDO defines an unconditional loop. An exit condition (typically in the form "IF <condition>. EXIT. ENDIF.") must be provided inside the body of the loop. A variant (DO <n> TIMES) sets as exit condition the number of times the loop body is executed. WHILE/ENDWHILE defines a conditional loop. The condition is tested at the beginning of the loop. LOOP/ENDLOOP loops over the lines of an internal table. The loop ends after processing the last line of the internal table.

Call statements

These statements call processing blocks defined using the corresponding modularization statements. The blocks can either be in the same ABAP program or in a different program.
Examples of call keywords:
PERFORM, CALL METHOD, CALL TRANSACTION, CALL SCREEN, SUBMIT, 
LEAVE TO transaction


Operational statements

These statements retrieve or modify the contents of variables.
A first group of operational statements assign or change a variable:
MOVE, ADD, SUBTRACT, DIVIDE
These statements, whose syntax originates in COBOL, can be written in a shorter form that uses operators rather than keywords:
MOVE LASTNAME TO RECIPIENT.
* is equivalent to
RECIPIENT = LASTNAME.
 
ADD TAX TO PRICE.
* is equivalent to
PRICE = PRICE + TAX.
Examples of operational statements on character strings:
SEARCH, REPLACE, CONCATENATE, CONDENSE
Database access statements (Open SQL):
SELECT, INSERT, UPDATE, DELETE, MODIFY
Statements working on internal tables (notice that some "SQL" statements can also be used here):
READ TABLE, INSERT, UPDATE, DELETE, MODIFY, SORT,
DELETE ADJACENT DUPLICATES, APPEND, CLEAR, REFRESH, FREE


Formatting statements

These statements produce or format output. They appear mainly in reports, less so in module pools. Examples are:
WRITE, FORMAT, SKIP, ULINE, MESSAGE, NEW-PAGE


Internal tables in ABAP

Internal tables are an extremely important feature of the ABAP language and merit being explained at some length. An internal table would be defined as 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. It should be noted that ABAP does not support arrays; the only way to define a multi-element data object is to use an internal table.

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 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.