ABAP (Advanced Business Application Programming, originally ...

clutteredreverandData Management

Oct 31, 2013 (3 years and 7 months ago)

178 views

ABAP

(Advanced Business Application Programming, originally

Allgemeiner Berichts
-
Aufbereitungs
-
Prozessor
, German for
"general report creation processor"
[1]
) 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 lan
guage for programming the

SAP Application Server
,
part of its

NetWeaver

platform f
or building business applications. The syntax of ABAP is somewhat similar to

COBOL
.
[
opinio
n
][
citation
needed
]

Contents



[
hide
]




1

Introducti on

o

1.1

ABAP runti me envi ronment

o

1
.2

SAP Basi s

o

1.3

SAP systems and l andscapes



2

Transacti ons



3

Types of ABAP programs



4

ABAP Workbench



5

ABAP Di cti onary



6

ABAP syntax

o

6.1

"Hel l o Worl d"

o

6.2

Chai ned statements

o

6.3

Comments



7

Data types and vari abl es



8

ABAP Obj ects



9

ABAP statements


an overvi ew

o

9.1

Decl arati ve statements

o

9.2

Modul arizati on statements

o

9.3

Control stat
ements

o

9.4

Cal l statements

o

9.5

Operati onal statements

o

9.6

Formatti ng statements



10

Internal tables i n ABAP



11

See al so



12

References



13

External l i nks

[
edit
]
Introduction

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

A
llgemeiner

B
erichts
A
ufbereitungs
P
rozessor
,
German for "generic report preparation
processor", but was later renamed to the English

A
dvanced

B
usiness
A
pplication

P
rogramming
. ABAP was one of the first
languages to include the concept of

Logical Databases

(LDBs), which provides a high level of abstrac
tion from the basic database
level(s).

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
[
opinion
]

for
programmers but it is not a tool for direct use by non
-
programmers.
Knowledge of relational database design and preferably also of object
-
oriented concepts is necessary to create ABAP programs.

ABAP remains as the language for creating programs for the cli
ent
-
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 bu
t 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
.


[
edit
]
ABAP runtime environment

All ABAP programs reside inside the SAP database. They are not stored in separate external files li
ke 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, contro
lling
the flow logic of screens and r
esponding 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.

[
edit
]
SAP Basis

The ABAP language environment, including the syntax checking, code generation, and runtime system, is part of the SAP Basis
component/layer. 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

virtual machine

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

SAP Basis also provides

a layer of 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 platfo
rm 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

IBM DB2
,

Informix
,

MaxDB
,

Oracle
,
an
d

Microsoft SQL Server

(support for Informix was discontinued in SAP Basis release 7.00).

[
edit
]
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, l
oad
balancing mechanisms ensure that the l
oad 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 an
d
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 unde
r 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 th
e 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 tra
nsactions 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.

[
edit
]
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"). Transactions can be called

via
system
-
defined or user
-
specific, role
-
based menus. They can also be started by entering the trans
action 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 term "transaction" must not be misunderstood h
ere; 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) a
s a whole. This concept exists in SAP and is called a LUW (Logical Unit of
Work). In the course of one transaction (program execution), there can be different LUWs. Transaction for ABAP Workbench coul
d
be invoked using transaction code SE80 to work on all
ABAP development related activities.
[
citation needed
]

[
edit
]
Types of ABAP programs

As in other programming languages, an ABAP program is either an executable unit or a library, which pro
vides 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 te
rm
"report" can be somewhat misleading in that reports can also be designed to

modify

data; the reason wh
y 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. Each screen has its own flow logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After I
nput)
section. In SAP documentat
ion the term “dynpro” (dynamic program) refers to the combination of the screen and its flow logic.

The non
-
executable program types are:



INCLUDE modules



Subroutine pools



Function groups



Object classes



Interfaces



Type pools

An INCLUDE module gets included
at generation time into the calling unit; it is often used to subdivide very large programs.
Subroutine pools contain ABAP subroutines (blocks of code enclosed by FORM/ENDFORM statements and invoked with
PERFORM). Function groups are libraries of self
-
cont
ained function modules (enclosed by FUNCTION/ENDFUNCTION and
invoked with CALL FUNCTION). Object classes and interfaces are similar to Java classes and interfaces; the first define a set

of
methods and attributes, the second contain "empty" method definiti
ons, for which any class implementing the interface must provide
explicit code. Type pools define collections of data types and constants.

[
edit
]
ABAP Workbench

The ABAP Workbench contains different tools for editing programs. The most important of these are (transaction codes are show
n
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

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.

[
edit
]
ABAP Dictionary

The ABAP Dictionary contains all metadata about the data in the SAP system. It is closely linked with the ABAP Workbench in t
hat

any reference to data (e.g., a table, a view, or a data type) will be obtained from the dictionary. Developers use the ABAP D
ictionary
transactions (directly or through the SE80 Object Navigator inside the ABAP Workbench) to display and maintain this meta
data.

When a dictionary object is changed, a program that references the changed object will automatically reference the new versio
n the
next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference chang
ed
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 definitio
n 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 th
e 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 pr
imary 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 "clu
ster 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 select
ion 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

hav
e 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. View is actually a virtual table which does not contain data physically. Views take very short
memory spac
e in database because the views contain only the definition of data.



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, do
zens 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 d
ata
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 li
st
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 pos
sible 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
geograp
hical location, credit rating, etc.



Lock objects

implement application
-
level locking when changing data.

[
edit
]
ABAP syntax

This brief descri
ption of the ABAP syntax begins inevitably with the ubiquitous "Hello World" program.

[
edit
]
"Hello World"

REPORT

TEST
.

WRITE

'Hello
World'
.

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. An alternative
statement,
PROGRAM, would be used for a module pool.

[
edit
]
Chained statements

Consecutive statements with an identical first (leftmo
st) part can be combined into a "chained" statement using the chain operator ":"
(colon). 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 op
erator 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 very often used in WRITE statements. WRITE accepts just one argument, so if for ins
tance you wanted to display three
fields from a structure called FLIGHTINFO, you would have to code:

WRITE

FLIGHTINFO
-
CITYFROM
.

WRITE

FLIGHTINFO
-
CITYTO
.

WRITE

FLIGHTINFO
-
AIRPTO
.

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

WRITE
:

FLIGHTINFO
-
CITYFROM
,

FLIGHTINFO
-
CITYTO
,

FLIGHTINFO
-
AIRPTO
.

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. Examp
le:

REPLACE

'A'

WITH

'B'

INTO

LASTNAME
.

REPLACE

'A'

WITH

'B'

INTO

FIRSTNAME
.

REPLACE

'A'

WITH

'B'

INTO

CITYNAME
.

could be rewritten in chained form as:

REPLACE

'A'

WITH

'B'

INTO
:

LASTNAME
,

FIRSTNAME
,

CITYNAME
.

[
edit
]
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:

***************************************

** Program: BOOKINGS

**

** Author: Joe Byte, 07
-
Jul
-
2007 **

***************************************



REPORT

BOOKINGS
.



* Read flight bookings from the database

SELECT

*

FROM

FLIGHTINFO


WHERE

CLASS

=

'Y'

"Y = economy


OR

CLASS

=

'C'
.

"C = business

(...)

[
edit
]
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:

Type

Description

I

Integer (4
-
bytes)

P

Packed decimal

F

Floating point

N

Character
numeric

C

Character

D

Date

T

Time

X

Hexadecimal (raw byte)

STRING

Variable
-
length string

XSTRING

Variable
-
length raw byte array

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 an
d as
character strings (with internal format "YYYYMMDD" for dates and "hhmmss" for times), which makes date/time handlin
g very easy.
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):

DATA

LAST_EOM
TYPE

D
.

"last end
-
of
-
month date



* Start from today's date


LAST_EOM
=

SY
-
DATUM
.

* Set characters 6 and 7 (0
-
relative) of the YYYYMMDD string to "01",

* giving the first day of the current month


LAST_EOM
+
6
(
2
)

=

'01'
.

* Subtract one day


LAST_EOM
=

LAST_EOM
-

1
.




WRITE
:

'Last day of previous month was'
,

LAST_EOM
.

All ABAP variables must be explicitly

declared

in order to be used. Normally all declarations are placed at the top of the code
modul
e (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:

* Primitive types:

DATA
:

COUNTER
TYPE

I
,


VALIDITY
TYPE

I
VALUE

60
,


TAXRATE
(
3
)

TYPE

P
DECIMALS

1
,


LASTNAME
(
20
)

TYPE

C
,


DESCRIPTION
TYPE

STRING
.



*
Dictionary types:

DATA
:

ORIGIN
TYPE

COUNTRY
.



* Internal table:

DATA
:

T_FLIGHTS
TYPE

TABLE OF

FLIGHTINFO
,


T_LOOKUP
TYPE

HASHED TABLE OF

FLT_LOOKUP
.



* Objects:

DATA
:

BOOKING
TYPE

REF TO

CL_FLT_BOOKING
.

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

[
edit
]
ABAP Objects

The ABAP language supports

object
-
oriented programming
, through a feature known as "ABAP Objects".
[2]

This helps to simplify
applications and make them mor
e 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.

[
edit
]
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 statem
ents listed here
and the subdivision used are fairly arbitrary and by no means exhaustive.

[
edit
]
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

[
edit
]
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:

LOAD OF PAGE,INITIALIZATION,AT SELECTION SCREEN OUTPUT,AT SELECTION SCREEN ON FIELD, AT SELECTION
SCREEN ON BLOCK,


AT SELECTION SCREEN, START
-
OF
-
SELECTION
,END
-
OF
-
SELECTION, AT USER
-
COMMAND, AT LINE
-
SELECTION,GET,GET LATE,AT USER COMMAND,

AT LINE SELECTION

Defining statements

These statements delineate callable code units such as subroutines, function modules and methods. The statement marking the
end of th
e unit has the name of the opening statement prefixed with "END".

Examples of defining keywords:

FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION,

MODULE ... ENDMODULE, METHOD ... ENDMETHOD

[
edit
]
Control statements

These statements control the flow of the program within a processing block.

Statements controlling conditional

execution are:

IF ... ELSEIF ... ELSE ... ENDIF

CASE ... WHEN ... 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 prov
ided
inside the body of the loop. A variant (DO <n> TIMES) sets as exit c
ondition 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.

[
edit
]
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, CALL FUNCTION

[
edit
]
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, LOOP AT, INSERT, DELETE, MODIFY, SORT, DELETE ADJACENT DUPLICATES, APPEND, CLEAR,
REFRESH, FREE

[
edit
]
Formatting statements

[
edit
]
Internal tables in ABAP

Internal tables are an extremely important feature of the ABAP language. An internal table is define
d as a vector of

struct
s in C++ or
a vector of objects in Java. The main difference with these languages is that ABAP provides a collection of statements to eas
ily
access and manipulate the contents of internal tables. Note that ABAP does not support array
s; the only way to define a multi
-
element data object is to use an internal table.
[
citation needed
]

Internal tables are a way to store variable datasets
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 da
tabase tables from within a program. Furthermore, internal
tables in connection with structures are the most important means of defining very complex data structures in an ABAP program
.

Following example define an internal table with two fields with the fo
rmat of database table VBRK:

DATA

:

BEGIN OF

I_VBRK
OCCURS

0
,


VBELN
LIKE

VBRK
-
VBELN
,


ZUONR
LIKE

VBRK
-
ZUONR
,


END OF

I_VBRK
.

[
edit
]
See also



ERP software



Secure Network Communications



SAP Logon Ticket



Single Sign
-
On

[
edit
]
References

1.

^

"ABAP Hi story".

SAP
-
technical.com

2.

^

"Cl asses".

SAP NetWeaver 7.0
.

[1]

accessed 10 August 2009.

[
edit
]
External links



SAP Help Portal



ABAP Development

discussions, blogs, documents and videos on the

SAP Community Network (SC
N)



ABAP Objects



ABAP

at the

Open Directory Project