CDS and the Code Pushdown Paradigm
Before SAP HANA, most business applications followed a traditional Data-to-Code architecture.
In this model, the database was primarily responsible for storing and retrieving data, while the majority of business processing happened on the ABAP Application Server.
A typical application would:
- Read large datasets from one or more database tables.
- Transfer data from the database to the application server.
- Store the data in internal tables.
- Execute joins, loops, calculations, filtering, and aggregations in ABAP.
- Return the final result to the user.
This approach worked well when databases were disk-based and data volumes were relatively small.
However, modern enterprise systems process millions of business transactions every day. As data volumes increased, moving large datasets between the database and application server became increasingly expensive.
The result was:
- Higher network traffic
- Increased memory consumption
- Longer response times
- Poor scalability for analytical and reporting scenarios
SAP needed a new approach that would allow calculations to be executed closer to the data rather than transferring massive datasets to the application server.
This led to the introduction of the Code Pushdown paradigm.
From Data-to-Code to Code-to-Data
The core idea behind Code Pushdown is simple:
Move the code to the data instead of moving the data to the code.
Rather than fetching millions of records into ABAP and processing them there, SAP HANA performs the calculations directly inside the database.
Only the final result is sent back to the application server.
This architectural shift is commonly known as moving from Data-to-Code Architecture to Code-to-Data Architecture.
The amount of transferred data is drastically reduced, resulting in better performance and improved scalability.
How CDS Enables Code Pushdown
Core Data Services (CDS) became SAP's strategic technology for implementing Code Pushdown.
CDS allows developers to define:
- Joins
- Associations
- Calculated Fields
- Aggregations
- Filters
- Access Controls
directly at the database layer.
Instead of writing complex ABAP loops and calculations, developers can model the logic once in CDS and let SAP HANA execute it efficiently.
This allows applications to fully leverage the power of the SAP HANA database.
Real Project Example: Purchase Register Application
Consider a Purchase Register application containing several million invoice records.
In a Traditional ABAP Approach
- Purchase documents are read into internal tables.
- Vendor information is joined in ABAP.
- GST calculations are performed inside loops.
- Totals and summaries are calculated on the application server.
- The final report is generated and displayed.
As the volume of data grows, the report becomes slower because a large amount of data must travel between the database and application server.
Using CDS-Based Approach
- Database joins execute directly inside SAP HANA.
- Calculated fields are evaluated at the database layer.
- Aggregations are performed by the HANA engine.
- Only the final summarized result is returned.
The application transfers significantly less data and executes much faster, especially for large datasets.
CDS Is Not the Only Code Pushdown Technology
SAP provides three major technologies that support Code Pushdown:
Core Data Services (CDS)
Used for semantic data modeling, calculations, associations, annotations, and service consumption.
Enhanced Open SQL
Modern ABAP SQL syntax that enables database-intensive operations directly within ABAP programs.
ABAP Managed Database Procedures (AMDP)
Used when advanced SAP HANA-specific logic needs to be implemented using SQLScript.
Together, CDS, Open SQL, and AMDP form the foundation of SAP's Code Pushdown strategy.
Code Pushdown Technologies Comparison
| Technology | Purpose | Typical Usage |
|---|---|---|
| CDS | Semantic Data Modeling | Associations, Annotations, RAP, OData Exposure |
| Open SQL | Database Operations from ABAP | Reads, Joins, Filtering and Aggregations |
| AMDP | Advanced SAP HANA Logic | SQLScript Procedures and Complex Processing |
Architect Perspective
SAP did not introduce CDS merely to replace database views. CDS was introduced as a strategic semantic modeling layer that enables SAP HANA to execute business logic closer to the data.Successful SAP S/4HANA and RAP architectures minimize data movement and maximize database-side processing. Architects should always evaluate whether calculations, joins, aggregations, and filters can be pushed down to CDS before implementing them in ABAP code.
Interview Quenstions
Why did SAP introduce CDS when ABAP Open SQL already existed?
Answer: Open SQL primarily retrieves and manipulates data, whereas CDS provides a semantic modeling layer that supports associations, annotations, access control, calculations, analytics, OData consumption, and code pushdown.
What is the difference between Data-to-Code and Code-to-Data architectures?
Answer: In Data-to-Code architectures, large datasets are transferred to the application server where processing occurs. In Code-to-Data architectures, calculations execute directly inside SAP HANA and only the final result is transferred, significantly improving performance and scalability.
When should CDS, Open SQL, and AMDP be used in a Code Pushdown strategy?
Answer: CDS should be used for semantic data modeling and reusable business views, Open SQL for database-intensive operations within ABAP programs, and AMDP when advanced SAP HANA-specific logic requires SQLScript capabilities that CDS and Open SQL cannot provide.
💡 Key Takeaway
The primary reason CDS was introduced was to leverage the processing power of SAP HANA and reduce unnecessary data movement between the database and application server.
By moving calculations closer to the data, CDS enables faster applications, better scalability, reduced network overhead, and a modern architecture that serves as the foundation of SAP S/4HANA and RAP.