ABAP - Meaning
ABAP - Meaning
What is ABAP?
ABAP technology is the solid longtime foundation for SAP’s solution portfolio. Its proven robustness,
scalability and extensibility makes it the platform of choice for running mission-critical business processes.
It is the underlying technology of SAP’s traditional Business Suite, SAP’s flagship solution SAP S/4HANA,
and other forthcoming innovative solutions such as next-generation data warehouse SAP BW4/HANA.
ABAP technology is also available as a standalone platform for custom development of modern ABAP-based
business applications. SAP customers and partners also have a long tradition of building custom code and
add-ons that run on the ABAP technology platform.
It is also a complete application development and runtime platform. It combines: the innovation potential
of SAP’s in-memory database SAP HANA on the back end; the proven reliability and robustness of the
ABAP server; and a digital user experience through SAP’s UI technology SAP Fiori. The ABAP technology is
continuously extended to serve new business scenarios and innovative application development in a first
approach.
ABAP runs productively in more than 100,000 SAP customer systems, where it enables enterprise-ready
business applications and processes, and reduces total cost of development due to its integrated, self-
compiling nature.
ABAP Platform
Highlights at a glance
Proven, highly scalable, and robust application server with multi-layer architecture and powerful
transaction management
Central development on the server with integrated source code and version management
Superior development environment and ABAP tools for the whole development lifecycle provided in
Eclipse
Core Concepts
Architecture
The Application Server ABAP (AS ABAP) consists of three layers: presentation, application, and database.
The layer division is purely logical. In fact, all three layers can actually run on a single computer.
The database not only contains the user data, but also the entire program code of the ABAP Application
Server and application programs, all administrative data etc. The programs you develop are stored in the
ABAP schema of the system.
The application layer consists of one or more AS ABAP instances, a single Message Server, which is
responsible for communication and load distribution within this layer, and a single Enqueue Server, which
manages locks. The ABAP programs and all the development tools run in the application layer. ABAP
Dispatcher distributes the requests to the work processes (WP) within an AS ABAP. A WP processes your
program and owns a database connection so that you don’t need to take care of database handling (e.g.
open/close database connections). A WP is assigned to you only for the time of program processing and
afterwards it is free for another user. This architecture is robust and scalable. There is no such thing as
crashing the whole engine in ABAP by a severe syntax error in your program. Beyond this ABAP systems
and external programs can communicate with one another through different protocols like RFC, TCP/IP,
HTTP and OData.
ABAP
The presentation layer represents UI and is responsible for the screen display. This layer receives user
entries – that is, mouse-clicks and keyboard input – and passes them on to the application layer.
Furthermore, it receives data from the application layer and displays it to the user. When writing a business
application you should use SAP Fiori UI as a state-of-the-art user interface. When developing in ABAP you
may also encounter browser-based Web Dynpro ABAP/Floorplan Manager technology or Dynpro
technology. Before SAP Fiori, Web Dynpro for ABAP was the SAP standard UI technology for developing
Web applications in the ABAP environment. Dynpros are the classical user interfaces of most ABAP-based
SAP programs and run in the SAP GUI.
Why and how Application Server ABAP matters for you as developer?
In general, you develop on a central server in ABAP. Thus, you require access and developer authorization
for the AS ABAP. All the tools for the whole development lifecycle are integrated there and are also part of
the server.
You write your programs using the ABAP Development Tools. When you choose Save, the ABAP editor
stores your program in the database. You then retrieve it by name: you don’t have to deal with program files
in ABAP; the server does it all for you. Usually many developers are working on the same server. While you
write your source code in the editor this development object is locked for you. When you choose the Save-
button the inactive version of the development object is created. This is visible for all developers on the
server and they can change it. Once you press Activate button an active version of the development object is
created and other programs can access it.
ABAP
Your advantages:
You don’t need to deal with version management: the server does it for you
The incompatibilities become visible very early: at activation of your source code
No need for a separate system to test the interaction of source code from different developers
Typical experience when working with the AS ABAP: many things that developers or quality
managers usually must care about are already provided and you can concentrate on your daily job:
business programming.
Why and how to connect to integrated software logistics on the ABAP server?
All ABAP development objects are stored in the database of the system. You don’t have to copy a program
file manually if you need it elsewhere. The ABAP server provides the built-in mechanism (change and
transport management system, CTS) to transport development objects through the system landscape.
Besides this, the proper structuring of development objects becomes particularly important if you work in a
team on a development project.
Every development object in ABAP belongs to a package. Packages organize development objects and
handle their connection to the AS ABAP software logistics. That is a package is like a folder in a way. The
transport layer is an important concept in the ABAP software logistics. It refers to the transport path a
package should take in a system landscape. The usual landscape has at least three system layers:
You develop an object in the development system and test it in the consolidation system. When all tests are
successful you transport your tested development objects to the productive system. You define this path
(transport layer) as an attribute of a package and in this way the destinations of your development objects
are clear from the very beginning of your development.
Besides this you need to assign your package and its content (ABAP development objects) to a particular
transport request. As soon as you release the relevant transport request, your object will be transported to
the next system on the transport layer. The only exception to this rule is the package $tmp. You can store
there your local developments, which don’t need to be transported.