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
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.
[edit] 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). 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.
[edit] SAP
Basis
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
IBM DB2,
Informix,
MaxDB,
Oracle
and
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 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. An 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.
[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, SE80 is the code for the ABAP workbench). 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.
There exists different kind of transactions:
[edit] Dialog transaction
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 called. The program flow can differ from execution to execution. You can
even assign different dialog transaction codes to one program.
[edit] Parameter transaction
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.
[edit] Report transaction
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.
[edit] Object Oriented transaction
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.
[edit] Types of ABAP programs
In ABAP, there are 7 different types of programs:
Include, executable, function module, module pool, subroutine, class,
interface,
[edit] Report
programs
Report programs 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 output from the report program is interactive
because it is not a passive display; instead it enables the user, through ABAP
language constructs, to obtain a more detailed view on specific data records
via drill-down functions, or to invoke further processing through menu
commands, for instance to sort the data in a different way or to filter the
data according to selection criteria. This method of presenting reports has
great advantages for users who must deal with large quantities of information
and must also have the ability to examine this information in highly flexible
ways, without being constrained by the rigid formatting or unmanageable size of
"listing-like" reports. The ease with which such interactive reports
can be developed is one of the most striking features of the ABAP language.
The term "report" is somewhat misleading in the sense that it is also
possible to create report programs that
modify the data in the
underlying database instead of simply reading it.
A customized screen created using Screen Painter,which
is one of the tools available in ABAP workbench(T-code = SE51).
[edit] Online
programs
Online programs (also called module pools) do not produce lists.
These programs define more complex patterns of user interaction using a
collection of screens. The term “screen” refers to the actual, physical image
that the users sees. Each screen also has a “flow logic”; this refers to the
ABAP code invoked by the screens, i.e. the logic that initializes screens,
responds to a user’s requests and controls the sequence between the screens of
a module pool. Each screen has its own Flow Logic, 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.
Online programs are not invoked directly by their name, but are associated with
a transaction code. Users can then invoke them through customizable,
role-dependent, transaction menus.
Apart from reports and online programs, it is also possible to develop
sharable code units such as class libraries, function libraries and subroutine
pools.
Transaction Code is se51
[edit] Subroutine pools
Subroutine pools, as the same implies, were created to contain collections
of subroutines that can be called externally from other programs. Before
release 6.10, this was the only way subroutine pools could be used. But besides
subroutines, subroutine pools can also contain local classes and interfaces. As
of release 6.10, you can connect transaction codes to methods. Therefore, you
can now also call subroutine pools via transaction codes. This is the closest
to a Java program you can get in ABAP: a subroutine pool with a class
containing a method – say – main connected to a transaction code!
[edit] Function
pools
Function pools, more commonly known as "function groups", are
libraries of functions developed in ABAP. Functions differ from subroutines in
that they are self-contained and do not belong to a specific program. ABAP
functions accept as input any number of input parameters, return as output any
number of output parameters, and raise exceptions if an error condition occurs.
Functions are invoked in ABAP programs by means of the CALL FUNCTION
statement. A very important feature of ABAP is the ability to call function
modules in another SAP system or in an external application using the
RFC (Remote Function Call) mechanism. It is
also possible to call functions asynchronously; the ABAP program then does not
wait for the function to return but instead continues immediately, while the
function executes in a separate context.
[edit] Type
pools
Type pools are the precursors to general type definitions in the ABAP
Dictionary. Before release 4.0, only elementary data types and flat structures
could be defined in the ABAP Dictionary. All other types that should’ve been
generally available had to be defined with TYPES in type pools. As of release
4.0, type pools were only necessary for constants. As of release 6.40,
constants can be declared in the public sections of global classes and type
pools can be replaced by global classes..
[edit] Class
pools
Class pools serve as containers for exactly one global class. Besides the
global class, they can contain global types and local classes/interfaces to be
used in the global class. A class pool is loaded into memory by using one of
its components. For example, a public method can be called from any ABAP
program or via a transaction code connected to the method. You maintain class
pools in the class builder.
[edit] Interface
pools
Interface pools serve as containers for exactly one global interface—nothing
more and nothing less. You use an interface pool by implementing its interface
in classes and by creating reference variables with the type of its interface.
You maintain interface pools in the class builder.
[edit] ABAP
workbench
The ABAP Workbench contains different tools for editing Repository objects.
These tools provide you with a wide range of assistance that covers the entire
software development cycle. The most important tools for creating and editing
Repository objects are:
ABAP Editor for writing and editing program code
(Transaction:SE38
ABAP Editor)
ABAP Dictionary for processing database table definitions and retrieving
global types
(Transaction:SE11)
Menu Painter for designing the user interface (menu bar, standard
toolbar, application toolbar, function key assignment)
Screen Painter for designing screens (dynamic programs) for user dialogs
Function Builder for displaying and processing function modules
(routines with defined interfaces that are available throughout the system)
Class Builder for displaying and processing ABAP Objects classes
[edit] The ABAP dictionary
The ABAP Dictionary is a fully integrated data environment controlling
facility. It contains all definitions for Domains, Data Elements, Structures,
Tables, Views, Search Helps, Lock Objects, Matchcode Objects, The Table
Maintenance Generator, and the Table Description Generator.
With these objects in its repository, the ABAP Dictionary:
- Enforces data integrity
- Manages data definitions
without redundancy
- Is tightly integrated with
the rest of the ABAP/4 Development Workbench.
Enforcing data integrity is the process of ensuring that data entered into
the system is logical, complete, and consistent. When data integrity rules are
defined in the ABAP/4 Dictionary, the system automatically prevents the entry
of invalid data. Defining the data integrity rules at the dictionary level means
they only have to be defined once, rather than in each program that accesses
that data.
The following are examples of data lacking integrity:
- A date field with a month
value of 13
- An order assigned to a
customer number that doesn’t exist
- An order not assigned to a
customer
Managing data definitions without redundancy is the process of linking
similar information to the same data definition. For example, a customer
database is likely to contain a customer’s ID number in several places. The
ABAP Dictionary provides the capability of defining the characteristics of a
customer ID number in only one place. That central definition then can be used
for each instance of a customer ID number.
The ABAP Dictionary’s integration with the rest of the development environment
enables ABAP programs to automatically recognize the names and characteristics
of dictionary objects.
Additionally, the system provides easy navigation between development
objects and dictionary definitions. For example, as a programmer, you can double-click
on the name of a dictionary object in your program code, and the system will
take you directly to the definition of that object in the ABAP/4 Dictionary.
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.
[edit] ABAP
syntax
This brief description of the ABAP syntax begins inevitably with the
ubiquitous "Hello World" program.
[edit] "Helloworld"
PROGRAM TEST.
WRITE 'Hello World'.
This example contains two statements, one on each line. The keywords are
PROGRAM and WRITE. The program displays a list on the screen. In this case, the
list consists of the line "Hello World".
[edit] Formatting rules
[edit] White space significance
ABAP has no format restrictions. You can enter statements in any format, so
a statement can be indented, you can write several statements on one line, or
spread a single statement over several lines. The only requirement is that
every statement ends in a period.
You must separate words within a statement with at least one space. The
system also interprets the end of line marker as a space.
The two-line "Hello World" program from above could also be
written as
PROGRAM TEST. WRITE 'Hello World' .
or even as:
PROGRAM
TEST.
WRITE
'Hello World'.
Free formatting is convenient, but with complex code, such as deeply nested
IF/ELSE blocks, it can get tricky. The ABAP editor therefore offers a
"Pretty Printer" function, which can take care of proper indentation.
One obvious exception to the free-formatting rule are text literals. A text
literal is a sequence of alphanumeric characters in the program code enclosed
in single quotes. If a text literal in an ABAP statement extends across more
than one line, then a ‘&’ character must be used to combine a succession of
text literals into a single one. Example:
USERPROMPT = 'Please double-click on a line in the output list ' &
'to see the complete details of the transaction.'.
[edit] Case sensitivity
ABAP statements are not case-sensitive. The following code is perfectly
permissible:
proGRAm TEsT.
WriTe 'Hello World'.
Users can configure the way source text is presented (all upper case, all
lower case, ABAP keywords in upper case and variable names in lower case, etc.)
according to their own preference. Typically the keywords are in upper case and
everything else (variable, function, method, and class names) in lower case.
[edit] Chained statements
The ABAP programming language allows you to concatenate consecutive
statements with an identical first part into a chain statement.
To concatenate a sequence of separate statements, write the identical part
only once and place a colon (:) after it. After the colon, write the remaining
parts of the individual statements, separating them with commas. Ensure that
you place a period (.) after the last part to inform the system where the chain
ends.
Chaining is very 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:
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 the chain, a colon separates the beginning of the statement from the
variable parts. After the colon or commas, you can insert any number of spaces.
You could, for example, write the same statement like this:
WRITE: FLIGHTINFO-CITYFROM,
FLIGHTINFO-CITYTO,
FLIGHTINFO-AIRPTO.
In a chain statement, the first part (before the colon) is not limited to
the keyword of the statements. For example, the code
SUM = SUM + 1.
SUM = SUM + 2.
SUM = SUM + 3.
SUM = SUM + 4.
could be written in chained form:
SUM = SUM + : 1, 2, 3, 4.
[edit] Comments
ABAP has 2 ways of defining text as a
comment.
An
asterisk
(*) in the leftmost column of a line makes that line a comment. A
double quotation mark («"») anywhere on
a line makes the rest of that line a comment.
[edit] 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] Naming
notation
ABAP has a large number of naming conventions for different language
elements. These are conventions and not rules, so an ABAP programmer is free to
abide by them or not. However ABAP code developed by SAP itself generally
respects these naming rules. Below is a list.
- ALV_* Advance list
viewer
- AS_* Methods that
perform type conversions
- CHECK_* Check Methods
- CH_* Changing
Parameters
- CL_* Class name
- CO_*/C_*
Constants
- DR_* Data reference
- G_* Global
variables/data objects
- GT_* Global table
- GX_* Global boolean
field (X or space)
- IF_* Interface
- INT_*/IT_
Internal Table
- IS_* Methods that
return a Boolean value
- L_* Indicates the data
object is local. Often, before underscore, put a 'type letter' in case of
simple type (LC_,LF etc.)
- LC_* Local Constant
- LR_* Local Range
- LT_* Local Table
- LVC_* List Viewer
Control
- ON_* Event handler
- PA_* Parameters
- PE_*/EX_*
Export parameter
- PI_*/IM_* Input
parameter
- RA_* Ranges/Type Range
Of
- RE_* Result
- RF_* Reference
Variable
- SET_* Accessors
Methods
- SO_* Select-Options
- ST_* Structure
- TA_* Internal Standard
Table
- TC_* Table Control
- TH_* Internal Hashed
Table
- TP_* Other Variables
- TS_* Internal Sorted
Table
- TT_* Table type
- TY_* Types
- T_* Variable is a
table (T_MY_TABLE_VARIABLE)
- X* Source/first data
object (e.g. XVBAK)
- Y* Destination/second
data object (e.g. YVBAK)
- WA_* Work Area
- $* Static Variable
- ** Secondary working
area (e.g. *VBAK in TABLES statement. Obsolete)
[edit] DATA
and TYPES
It is a special strength of ABAP that you can define a great variety of data
types and objects that span the spectrum from very elementary data types to
very complex and dynamic types. Consequently, the subject of ABAP declarations
is quite extensive.
ABAP accepts all data types defined in the SAP dictionary or in Type Pools.
Types can also be defined inside the program itself. Object numeric (I for
integer, F for floating point), packed decimal (P), character (C or N, where
the N type is used for numeric strings that can be used in computation) or
hexadecimal (X). Date fields (type D) and time fields (type T) have a
"dual" nature; in an input/output context they behave like strings,
but in a computational context they are numeric integers. There are no built-in
functions or statements for dealing with dates and times; but, as in
spreadsheets,
arithmetic can be performed on a date-value to break it up. For example:
DATESENT = '20070901'.
VALIDTO = DATESENT + 60.
WRITE: 'Offer is valid until', VALIDTO DD/MM/YYYY.
In this example, a string literal representing September 1, 2007 is assigned
to DATESENT. DATESENT is then used in a numeric calculation to produce another
data field, VALIDTO, which is set to DATESENT plus 60 days. Finally, VALIDTO is
output as a string. The optional "DD/MM/YYYY" modifier displays the
date in a predefined format, here "31/10/2007". Without the modifier
the date would display as "20071031".
Data and Types
All ABAP variables must be explicitly
declared in order to be used. The
convention is for all declarations to be at the top of the program, or
subroutine. 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.
* 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"
[1]. 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.
[edit] ABAP statements – an overview
The first element of an ABAP statement is the ABAP keyword. This determines
the category of the statement. The different statement categories are as
follows:
[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 keywords:
TYPES, DATA, TABLES
[edit] Modularization statements
These statements define the processing blocks in an ABAP program.
The modularization keywords can be further divided into:
· Event Keywords
You use statements containing these keywords to define event blocks. There
are no special statements to conclude processing blocks - they end when the
next processing block is introduced.
Examples of event keywords are:
AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
· Defining keywords
You use statements containing these keywords to define subroutines, function
modules, dialog modules and methods. You conclude these processing blocks using
the END- statements.
Examples of definitive keywords:
FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.
[edit] Control statements
You use these statements to control the flow of an ABAP program within a
processing block according to certain conditions.
Examples of control keywords:
IF, WHILE, CASE
[edit] Call
statements
You use these statements to call processing blocks that you have already
defined using modularization statements. The blocks you call can either be in
the same ABAP program or in a different program.
Examples of call keywords:
CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
[edit] Operational statements
These keywords process the data that you have defined using declarative
statements.
Examples of operational keywords:
MOVE, ADD
[edit] Concept of internal table in ABAP
Internal tables provide a means of taking data from a fixed structure and
storing it in working memory in ABAP. The data is stored line by line in
memory, and each line has the same structure. In ABAP, internal tables fulfill
the function of arrays. Since they are dynamic data objects, the programmer is
saved the task of dynamic memory management in his or her programs. Internal
tables should be used whenever there is a need to process a dataset with a
fixed structure within a program. A particularly important use for internal
tables is for storing and formatting data from a database table within a
program. They are also a good way of including very complicated data structures
in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as
data types and as data objects. A data type is the abstract description of an
internal table, either in a program or centrally in the ABAP Dictionary, that
you use to create a concrete data object. The data type is also an attribute of
an existing data object.
[edit] Internal tables as data types
Internal tables and structures are the two structured data types in ABAP. The
data type of an internal table is fully specified by its line type, key, and
table type.
[edit] Line
type
The line type of an internal table can be any data type. The data type of an
internal table is normally a structure. Each component of the structure is a
column in the internal table. However, the line type may also be elementary or
another internal table.
Line Type can also refer to an ABAP Object's reference pointer value. If two
ABAP Objects are not related, they do not have the same line type. The line
type is stored in the value of the reference pointer and can be viewed in the
debugger. If one object attempts to access another unrelated object's
components, you will receive an error specifying that the line types do not
match.
The key identifies table rows. There are two kinds of key for internal
tables - the standard key and a user-defined key. You can specify whether the
key is UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain
duplicate entries with the same key. The uniqueness depends on the table access
method.
If a table has a structured line type, its default key consists of all of
its non-numerical columns that are not references or themselves internal
tables. If a table has an elementary line type, the default key is the entire
line. An internal table which has a line type that is itself an internal table,
has an empty key.
The user-defined key can contain any columns of the internal table that are
not references or themselves internal tables. Internal tables with a
user-defined key are called key tables. When you define the key, the sequence
of the key fields is significant. You should remember this, for example, if you
intend to sort the table according to the key.
Later versions of ABAP permit the definition of secondary keys. hi
[edit] Table
type
The table type determines how will access individual table entries. Internal
tables can be divided into three types:
Standard tables have an internal linear index. (Think of index as
"record number". It is not to be confused with a database index, for
example). From a particular size upwards, the indexes of internal tables are
administered as trees. In this case, the index administration overhead
increases in logarithmic and not linear relation to the number of lines. The
system can access records either by using the table index or the key. The
response time for key access is proportional to the number of entries in the
table. The key of a standard table is always non-unique. You cannot specify a
unique key. This means that standard tables can always be filled very quickly,
since the system does not have to check whether there are already existing
entries.
Sorted tables are always saved sorted by the key. They also have an internal
index. The system can access records either by using the table index or the
key. The response time for key access is logarithmically proportional to the
number of table entries, since the system uses a binary search. The key of a
sorted table can be either unique or non-unique. When you define the table, you
must specify whether the key is to be unique or not. Standard tables and sorted
tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using
its key. The response time is independent of the number of table entries, and
is constant, since the system access the table entries using a hash algorithm.
The key of a hashed table must be unique. When you define the table, you must
specify the key as UNIQUE.
[edit] Generic internal tables
Unlike other local data types in programs, you do not have to specify the
data type of an internal table fully. Instead, you can specify a generic
construction, that is, the key or key and line type of an internal table data
type may remain unspecified. You can use generic internal tables to specify the
types of field symbols and the interface parameters of procedures. You cannot
use them to declare data objects.
[edit] Internal tables as dynamic data objects
Data objects that are defined either with the data type of an internal
table, or directly as an internal table, are always fully defined in respect of
their line type, key and access method. However, the number of lines is not
fixed. Thus internal tables are dynamic data objects, since they can contain
any number of lines of a particular type. The only restriction on the number of
lines an internal table may contain are the limits of your system installation.
The maximum memory that can be occupied by an internal table (including its
internal administration) is 2 gigabytes. A more realistic figure is up to 500
megabytes. An additional restriction for hashed tables is that they may not
contain more than 2 million entries. The line types of internal tables can be
any ABAP data types - elementary, structured, or internal tables. The
individual lines of an internal table are called table lines or table entries.
Each component of a structured line is called a column in the internal table.
[edit] Choosing a table type
The table type (and particularly the access method) that you will use depends
on how the typical internal table operations will be most frequently executed.
[edit] Standard
tables
This is the most appropriate type if you are going to address the individual
table entries using the index. Index access is the quickest possible access.
You should fill a standard table by appending lines (ABAP APPEND statement),
and read, modify and delete entries by specifying the index (INDEX option with
the relevant ABAP command). The access time for a standard table increases in a
linear relationship with the number of table entries. If you need key access,
standard tables are particularly useful if you can fill and process the table
in separate steps. For example, you could fill the table by appending entries,
and then sort it. If you use the binary search option with key access, the
response time is logarithmically proportional to the number of table entries.
[edit] Sorted
tables
This is the most appropriate type if you need a table which is sorted as you
fill it. You fill sorted tables using the INSERT statement. Entries are
inserted according to the sort sequence defined through the table key. Any
illegal entries are recognized as soon as you try to add them to the table. The
response time for key access is logarithmically proportional to the number of
table entries, since the system always uses a binary search. Sorted tables are
particularly useful for partially sequential processing in a LOOP if you
specify the beginning of the table key in the WHERE condition. Entries are
inserted according to the sort sequence.
[edit] Hashed
tables
This is the most appropriate type for any table where the main operation is
key access. You cannot access a hashed table using its index. The response time
for key access remains constant, regardless of the number of table entries.
Like database tables, hashed tables always have a unique key. Hashed tables are
useful if you want to construct and use an internal table which resembles a
database table or for processing large amounts of data.
[edit] Advanced
topics
[edit] Batch input: concepts
Processing sessions
The above figure shows how a batch input session works.
A batch input session is a set of one or more calls to transactions along
with the data to be processed by the transactions. The system normally executes
the transactions in a session non-interactively, allowing rapid entry of bulk data
into an R/3 System.
A session records transactions and data in a special format that can be
interpreted by the R/3 System. When the System reads a session, it uses the
data in the session to simulate on-line entry of transactions and data. The
System can call transactions and enter data using most of the facilities that
are available to interactive users.
For example, the data that a session enters into transaction screens is
subject to the same consistency checking as in normal interactive operation. Further,
batch input sessions are subject to the user-based authorization checking that
is performed by the system.
There are three batch input methods:
(1) In the
Direct Input Method, the programs are provided by the SAP
system. These programs are available for Standard Applications. Under this
method, the data base is updated using a Function Module, which is responsible
for executing the appropriate consistency checks.
(2) In the
Call Transaction Method, the ABAP Program reads the
external data which is present on the Application or Presentation Server, and
uses the ABAP Statement CALL TRANSACTION USING to run a SAP statement.
(3) In the
Session Method the program reads the data and the SAP
system stores the data in a "Batch Input Session". The session records
the actions that are required to transfer data into the system using normal SAP
transactions.
[edit] Other
Features
ABAP Objects ABAP uses an object-oriented interfaces.
Sharing Data: With ABAP shared objects, you can aggregate data in
memory once at a central location. Different users and programs can then access
this data without the need for copying.
Exception Handling: With the class-based exception concept of ABAP,
you can define a special control flow for a specific error situation and
provide the user with information about the error.
Developing Persistency: For permanent storage of data in ABAP, you
use relational database tables by means of database-independent Open SQL, which
is integrated in ABAP. However, you can also store selected objects
transparently or access the integrated database or other databases using
proprietary SQL.
Connectivity and Interoperability: The Exchange Infrastructure and
Web services are the means by which developers can implement a service-oriented
architecture. With Web services, you can provide and consume services
independently of implementation or protocol. Furthermore, you can do so within
NetWeaver and in the communication with other systems. With the features of the
Exchange Infrastructure, you can enable, manage, and adapt integration
scenarios between systems.
Making Enhancements: With the Enhancement Framework, you can enhance
programs, function modules, and global classes without modification as well as
replace existing code. The Switch Framework enables you activate only specific
development objects or enhancements in a system.
[edit] Example
From SAP NetWeaver:
*-----------------------------------------------------------------------
* set an exclusive lock at level object-type & object-id
*-----------------------------------------------------------------------
IF NOT lf_bapi_error = true.
IF ( NOT istourhd-doc_type IS INITIAL ) AND
( NOT istourhd-doc_id IS INITIAL ).
CALL FUNCTION 'ENQUEUE_/DSD/E_HH_RAREF'
EXPORTING
obj_typ = istourhd-doc_type
obj_id = istourhd-doc_id
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
* terminate processing...
lf_bapi_error = true.
* ...and add message to return table
PERFORM set_msg_to_bapiret2
USING sy-msgid gc_abort sy-msgno
sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
gc_istourhd gc_enqueue_refdoc space
CHANGING lt_return.
ENDIF.
ENDIF.
ENDIF. " bapi error
[edit]
Example report(type - ALV(ABAP list viewer))
REPORT Z_ALV_SIMPLE_EXAMPLE_WITH_ITAB .
************************************************************************
*Simple example to use ALV and to define the ALV data in an internal
*table
************************************************************************
*data definition
tables:
marav. "Table MARA and table MAKT
*---------------------------------------------------------------------*
* Data to be displayed in ALV
* Using the following syntax, REUSE_ALV_FIELDCATALOG_MERGE can auto-
* matically determine the fieldstructure from this source program
Data:
begin of imat occurs 100,
matnr like marav-matnr, "Material number
maktx like marav-maktx, "Material short text
matkl like marav-matkl, "Material group (so you can test to make
" intermediate sums)
ntgew like marav-ntgew, "Net weight, numeric field (so you can test to
"make sums)
gewei like marav-gewei, "weight unit (just to be complete)
end of imat.
*---------------------------------------------------------------------*
* Other data needed
* field to store report name
data i_repid like sy-repid.
* field to check table length
data i_lines like sy-tabix.
*---------------------------------------------------------------------*
* Data for ALV display
TYPE-POOLS: SLIS.
data int_fcat type SLIS_T_FIELDCAT_ALV
*---------------------------------------------------------------------*
select-options:
s_matnr for marav-matnr matchcode object MAT1.
*---------------------------------------------------------------------*
start-of-selection.
* read data into table imat
select * from marav
into corresponding fields of table imat
where
matnr in s_matnr.
* Check if material was found
clear i_lines.
describe table imat lines i_lines.
if i_lines lt 1.
* Using hardcoded write here for easy upload
write: /
'No materials found.'.
exit.
endif.
end-of-selection.
* To use ALV, we need either a reference to a structure defined in
* the SAP Data Dictionary (DDIC) or an in-program structure called
* the Field Catalog.
* The Field Catalog can be declared explicitly or generated by FUNCTION
* 'REUSE_ALV_FIELDCATALOG_MERGE' from an internal table from any
* report source, including this report.
*---------------------------------------------------------------------*
* Store report name
i_repid = sy-repid.
* Create Fieldcatalogue from internal table
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
I_PROGRAM_NAME = i_repid
I_INTERNAL_TABNAME = 'IMAT' "capital letters!
I_INCLNAME = i_repid
CHANGING
CT_FIELDCAT = int_fcat
EXCEPTIONS
INCONSISTENT_INTERFACE = 1
PROGRAM_ERROR = 2
OTHERS = 3.
*explanations:
* I_PROGRAM_NAME is the program which calls this function
*
* I_INTERNAL_TABNAME is the name of the internal table which you want
* to display in ALV
*
* I_INCLNAME is the ABAP-source where the internal table is defined
* (DATA....)
* CT_FIELDCAT contains the Fieldcatalouge that we need later for
* ALV display
IF SY-SUBRC <> 0.
write: /
'Returncode',
sy-subrc,
'from FUNCTION REUSE_ALV_FIELDCATALOG_MERGE'.
ENDIF.
*This was the field catalog
*---------------------------------------------------------------------*
*
* Call for ALV list display
CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
EXPORTING
I_CALLBACK_PROGRAM = i_repid
IT_FIELDCAT = int_fcat
TABLES
T_OUTTAB = imat
EXCEPTIONS
PROGRAM_ERROR = 1
OTHERS = 2.
*explanations:
* I_CALLBACK_PROGRAM is the program which calls this function
*
* IT_FIELDCAT (just made by REUSE_ALV_FIELDCATALOG_MERGE) contains
* now the data definition needed for display
*
* I_SAVE allows the user to save his own layouts
*
* T_OUTTAB contains the data to be displayed in ALV
IF SY-SUBRC <> 0.
write: /
'Returncode',
sy-subrc,
'from FUNCTION REUSE_ALV_LIST_DISPLAY'.
ENDIF.
