SAP R/3 Architecture
Jessica Blake
⚡ Smart Summary
SAP R/3 Architecture is a three-tier client-server design that separates presentation, application, and database responsibilities. This article explains each layer, the ABAP and Java component stack, the dispatcher-driven logon process, and the reasons SAP chose this layered model.
SAP R/3 Architecture underpins nearly every classic SAP ERP deployment. The sections below explain how the three tiers interact and how the ABAP and Java stacks split work between dispatcher, message server, and database.
What is SAP R/3?
SAP R/3 is a client-server enterprise system built on a three-tier architecture consisting of three independent layers:
- Presentation
- Application
- Database
- R stands for Real-time processing.
- 3 stands for the 3-tier architectural pattern.
User’s PC (front-end): Users access the SAP system through SAP GUI or a web browser. Only the front-end client is installed on the user’s machine; application and database servers run separately on dedicated hardware.
Application servers: Application servers execute business logic. Workload is distributed across multiple application servers so users receive responses faster under heavy load. These servers typically run on remote infrastructure rather than user workstations.
Database server: The database server stores and retrieves data in response to SQL queries generated by ABAP and Java applications. The database and application services may run on the same machine or on separate physical hosts depending on capacity needs.
Why does SAP R/3 use a 3-tier architecture?
Separating presentation, business logic, and storage into three independent tiers gives SAP R/3 four practical advantages over single-tier or two-tier designs:
- Independent scalability: Each layer can be scaled separately. A bottleneck in business logic is solved by adding application servers without touching the database hardware.
- Workload distribution: The message server load-balances incoming sessions across application servers, preventing any single server from becoming a single point of contention.
- Database protection: End-users never connect to the database directly. All read and write operations flow through application server work processes, which standardize authorization checks, locking, and transaction logging.
- Upgrade flexibility: The SAP GUI front-end can evolve (desktop, browser, or mobile clients via SAPUI5) without changing application or database code.
This separation is also what allows SAP to support multiple database back-ends — including SAP HANA, Oracle, IBM Db2, and Microsoft SQL Server — under the same application code base.
SAP R/2 vs SAP R/3: How the Architecture Evolved
SAP R/2 ran on a mainframe and used a two-tier architecture in which the user terminal communicated directly with the database. R/3, launched in 1992, inserted a dedicated application layer between client and database. The two side-by-side:
| Aspect | SAP R/2 | SAP R/3 |
|---|---|---|
| Architecture | 2-tier (mainframe + terminal) | 3-tier (presentation + application + database) |
| Hardware | Centralized mainframe | Distributed Unix / Windows / Linux servers |
| Scalability | Vertical only (bigger mainframe) | Horizontal (add application servers) |
| Database access | Direct from user session | Mediated by application server work processes |
| Programming model | ABAP/4 only | ABAP and Java side by side |
The remaining sections explain each of the three R/3 layers in detail.
Understanding different SAP layers
Figure 1: The three SAP R/3 layers and the traffic that flows between them.
Presentation Layer
The Presentation Layer contains the software components that make up the SAP GUI — the graphical front-end of the R/3 System. It is the interface between the system and its users, providing an intuitive layout for entering and displaying data.
This layer forwards user input to the application server and renders the data it receives in response. While SAP GUI is running, it remains linked to a user’s terminal session in the R/3 System for the duration of that session.
Application Layer
The Application Layer consists of one or more application servers and a message server. Each application server runs a set of services that execute R/3 business logic. In theory a single application server is sufficient; in practice services are distributed across several servers for capacity and redundancy.
The message server coordinates communication between application servers. It forwards requests, tracks application server groups, and assigns an appropriate server when a user logs on based on current load. This is what makes horizontal scaling possible.
Database Layer
The Database Layer houses a central database system that stores all data used by the R/3 System. The database stack has two components — the database management system (DBMS) and the database itself. SAP ships its own DBMS, SAP HANA, and also supports every major commercial database (Oracle, IBM Db2, Microsoft SQL Server).
All R/3 data — customizing settings, application code, screen definitions, menus, function modules, and runtime data — lives in this database. Program code and design objects sit in a special section called the R/3 Repository; these “repository objects” are what the ABAP Workbench reads, writes, and transports between systems.
Understanding the components of SAP R/3 3-tier Architecture
Figure 2: ABAP + Java system architecture showing how the two stacks share infrastructure.
A modern SAP NetWeaver instance can host both ABAP and Java stacks. The components below show how each stack handles its own dispatching while sharing the gateway, ICM, and JCO bridge for cross-stack communication.
| Component | Stack | Role |
|---|---|---|
| Message Server (ABAP) | ABAP | Coordinates communication between distributed dispatchers in the ABAP system and balances load across instances. |
| Dispatcher Queue | ABAP | Buffer that holds incoming requests until a work process becomes free. |
| Dispatcher | ABAP | Pulls requests from the queue and assigns each to the appropriate work-process type. |
| ABAP Work Processes | ABAP | Execute dialog steps in R/3 applications. Types include Dialog, Update, Background, Spool, and Enqueue. |
| Gateway | Shared | Enables communication between SAP systems and between SAP and external systems via RFC. |
| Memory Pipes | Shared | Carry data between the Internet Communication Manager (ICM) and ABAP work processes. |
| Message Server (Java) | Java | Coordinates Java dispatchers and server processes; enables communication inside the Java runtime cluster. |
| Enqueue Server | Java | Manages logical locks set by Java application code running inside a server process. |
| Central Services | Java | A special Java cluster instance that handles locking and inter-process messaging. An “instance” is a group of resources (memory, work processes, etc.). |
| Java Dispatcher | Java | Receives client requests and forwards them to Java server processes. |
| SDM | Java | Software Deployment Manager — installs J2EE components onto the Java stack. |
| Java Server Processes | Java | Process large numbers of requests concurrently using multi-threading. |
| ICM | Shared | Internet Communication Manager — enables HTTP, HTTPS, and SMTP traffic so SAP can be reached from a browser. |
| JCO | Bridge | Java Connector — handles communication between the Java dispatcher and the ABAP dispatcher when both stacks run side by side. |
Figure 3: Categories of ABAP work processes (Dialog, Update, Background, Spool, Enqueue).
How the SAP Logon Process works?
Figure 4: Step-by-step flow of a user logon through the SAP R/3 dispatcher and work-process layers.
Step 1) The user clicks the SAP system from SAP GUI; the request is forwarded to the dispatcher.
Step 2) The request lands in the request queue. The dispatcher follows a first-in, first-out rule and assigns the request to the next available work process.
Step 3) A work process of the appropriate type is assigned. A user logging on receives a Dialog work process; a background report receives a Background work process; an UPDATE statement is handed to an Update work process. The action dictates the type of work process.
Step 4) Once the Dialog work process is assigned, the user’s authorizations and current settings are rolled in to shared memory so the work process can act on the user’s data. When the dialog step finishes, that data is rolled out to free the memory for the next user. A “dialog step” is the movement from one screen to another inside a transaction.
Step 5) The work process first looks for the requested data in the buffer. Finding it there is called a hit and avoids a database round-trip, improving response time. Not finding it triggers a miss and a database read. A high hit-to-miss ratio is the single largest contributor to SAP performance.
Step 6) Any remaining data is queried from the database, and the combined result is sent back to the SAP GUI via the dispatcher.
Step 7) The user’s session data is removed from shared memory in a final roll-out, releasing the memory area for the next request.
The same dispatcher → queue → work process → buffer → roll-out cycle repeats for every user interaction, whether the request originates from SAP GUI, a browser via ICM, or an external system via the gateway.
