4Gls Sap R/2: Sap Systems and Landscapes
4Gls Sap R/2: Sap Systems and Landscapes
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 establish integration between independent software.
ABAP used to be an abbreviation of Allgemeiner Berichts-Aufbereitungs-Prozessor, German for
"generic report preparation processor", but was later [when?] renamed to the
English 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(s),which supports every platform, language and units.
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).[4]
Software layers[edit]
ABAP software is deployed in software components. Examples for these are:
SAP_BASIS is the required 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
SAP ABAP is an ERP programming language.
Transactions[edit]
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 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; [citation needed] the short form of
transaction code is T-code.
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 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-contained 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 definitions, for which any class
implementing the interface must provide explicit code.
Type pools 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[edit]
There are two possible ways to develop in ABAP. The availability depends on the release of the
ABAP system.
ABAP Workbench[edit]
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 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 Dictionary[edit]
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.