Moving ABAP Logic Down to the HANA Database

Code pushdown is the practice of executing data processing inside the HANA database rather than pulling records into the ABAP application server and processing them there in loops. The structural fact that explains most confusion: pushdown is not one technology, it is a spectrum. At the shallow end, writing tighter Open SQL that lets HANA do joins, aggregations and filtering instead of doing them in ABAP after a SELECT is already pushdown. Further down the spectrum sit CDS views, which express reusable data models and calculations as database views with annotations. At the deep end sit AMDP (ABAP Managed Database Procedures), which are ABAP method bodies whose implementation is actual SQLScript, compiled and executed as native HANA procedures. Consultants often use 'pushdown' to mean only AMDP, then argue past each other because someone else means 'stop reading tables into internal tables and looping'.

Reach for pushdown when a program reads a large data set, does aggregation, ranking, currency conversion or complex joins, and then discards most of the rows before doing anything ABAP-specific with the result. Financial consolidation, mass valuation runs, and reporting layers behind Fiori apps are typical candidates. It is the wrong tool when the logic is small in data volume but rich in business rules that change often, where SQLScript's poorer debugging and versioning story costs more than the runtime saved. It is also wrong when the only motivation is 'HANA is fast, so push it down' without having measured where time actually goes; plenty of slow programs are slow because of row-by-row RFC calls or nested loops, not because the database work sits in the wrong layer. Pushing down logic that is not database-shaped, such as complex conditional branching against non-DB data, mainly creates a maintenance burden.

Above pushdown logic sits the ABAP application: the class or program that calls a CDS view via Open SQL, or invokes an AMDP method through its ABAP method signature. Below it sits the HANA calculation and SQL engines that actually execute the joins, aggregations and procedures. Pushdown does not replace Open SQL, it is implemented through it, or through AMDP's SQLScript body, which is itself invoked like any other ABAP method. What it supersedes is the older pattern of SELECT-heavy ABAP with in-memory internal-table processing that was tuned for row-store databases and application-server CPU being the cheaper resource. In an S/4HANA system this pattern also intersects with the virtual data model: many CDS views used for pushdown are the same views exposed for analytics and Fiori, so a change in a pushdown view can ripple into reporting.

A billing report currently selects millions of billing item records into an internal table, then loops to convert currency, apply a discount tier lookup against a customer master table, and sum by sales organization. On production volumes this takes minutes and the application server memory footprint is large. Rework starts by writing a CDS view over the billing item table that joins the customer master, exposes currency conversion via a standard association or built-in currency conversion function, and does the sales-organization aggregation as a GROUP BY. The ABAP program is reduced to one Open SQL statement selecting from this CDS view with a WHERE clause on the selection screen parameters. If the discount tier logic is too irregular for CDS expressions, that one piece moves into an AMDP method that takes the pre-aggregated result as input and returns discount-adjusted totals, keeping SQLScript scope narrow. The ABAP layer keeps the selection screen, authorization check, and output formatting; the heavy lifting happens once, in the database, instead of row by row in application server memory.

In a clean core S/4HANA strategy, deep pushdown via custom AMDP is treated cautiously because SQLScript sits outside the released, upgrade-stable API surface and is not something key-user extensibility tools can touch. CDS view based pushdown is more acceptable because CDS is a first-class, versioned modeling layer with its own extension mechanisms, and much of it is delivered and maintained by SAP already. The general direction is to prefer standard CDS views and released APIs over hand-written SQLScript, and to treat custom AMDP as a targeted exception for genuinely procedural, high-volume logic rather than a default performance lever. Existing ECC custom code with heavy row-by-row processing is one of the classic categories flagged during a conversion for pushdown redesign, not because the old code is wrong, but because it was tuned for an architecture that no longer applies.

This is developer work with architect sign-off. The developer designs and implements the CDS view or AMDP method; the architect decides where on the pushdown spectrum a given piece of logic belongs and whether it conflicts with clean core policy. Handover should include the measured before-and-after runtime, the data volume tested against, and an explicit note of what authorization or currency logic was reimplemented inside the pushed-down layer.

Read the clean core page before deciding on AMDP, since it sets the boundary this page assumes. The ABAP SQL performance rules page covers the shallow end of the pushdown spectrum in detail, including Open SQL patterns that avoid needing AMDP at all. Custom code migration for S/4HANA is the project context in which most existing pushdown decisions get revisited, and ATC checks in an S/4HANA conversion is how those candidates get flagged mechanically.