The Architecture Shift: From R/3 to S/4HANA
For many years, SAP followed a three-tier architecture with presentation, application, and database layers where the choice of database did not matter at all, Oracle, DB2, SQL Server, or MaxDB would suffice under the ABAP application server. In contrast, SAP S/4HANA deliberately breaks such abstraction. Only SAP HANA can be used as a database, and this constraint allows an entirely new rearchitecting of how ABAP programs will be coded, compiled, and executed.
As a result of the old R/3 model, ABAP was constrained to bring entire sets of data from the database into application layer memory (“fat SELECT”), process them using internal ABAP tables, and then store results back in the database. This round trip was the main performance issue. S/4HANA closes that gap by moving processing logic to HANA in-memory column store, the famous code-to-data approach.
The ABAP Application Server & Runtime Stack
The AS ABAP (Application Server ABAP) continues to be the primary runtime environment for S/4HANA. The AS ABAP consists of a multi-process system that runs on the Linux operating system and consists of several major components working together to execute ABAP applications:
Every work process maintains its individual connection with the HANA database through the DBSL (Database Shared Library), which serves as the adapter layer responsible for converting ABAP Open SQL to HANA native SQL. In the case of S/4HANA, the DBSL is compiled especially for HANA, making optimizations such as pushdown feasible.
ABAP and the HANA In-Memory Engine
Columnar storage in HANA is the main factor behind the performance of S/4HANA. Unlike in row storage, where all fields of one record are stored consecutively, in a column store, all columns have their separate data structure — which means maximum compression and fast calculations using SIMD techniques while skipping unnecessary columns.
ABAP code that once had to load 10 million line item records into an internal table to calculate the total amount can now use the query SELECT SUM(amount) FROM bseg, which processes the calculation directly in the HANA engine and returns only a scalar number — literally a microsecond operation.
Code-to-Data Paradigm & Open SQL
S/4HANA came up with a greatly enhanced version of Open SQL, which is the database-independent language used by ABAP, to allow the usage of capabilities provided by HANA using only ABAP statements.
The ABAP SQL engine uses the same optimization techniques as the HANA cost-based optimizer. When a SQL statement is generated by ABAP code, it goes to the DBSL layer and then to HANA, where it is optimized, cached, and then re-used on the next invocation to avoid parsing costs.
Core Data Services (CDS) — The New Data Model Layer
CDS views represent the most important architectural enhancement of ABAP in S/4HANA. They are semantic, reusable components of data models that are described in the ABAP Dictionary and that get compiled into views in HANA. Unlike classical database views (purely technical), CDS views contain annotations used to build user interfaces, make authorization checks, and expose OData services, among other uses.
RESTful ABAP Programming Model (RAP)
RAP is SAP’s strategy for developing Fiori transaction applications within the S/4HANA environment. RAP replaces the outdated BOPF (Business Object Processing Framework) and function module based BAPIs. It provides a comprehensive and managed life cycle approach wherein CDS views serve as data models and behavior definitions define the business logic while the OData V4 services are generated by itself.
In RAP, a Behavior Implementation Class serves to implement all the transaction events. The framework controls the Save Sequence, LUW management, draft management, and OData binding itself, while the developer codes the business logic into the hook methods provided such as validate_, determine_, and action methods.
