CDS Table Functions and AMDP Explained

A CDS table function has a DDL source with a defined signature, parameters, and return structure, so from the outside it looks like any other CDS entity and can be selected from, joined to, and exposed like a view. The structural fact that causes confusion is that no SQL view is generated underneath it. Instead the DDL source is only an interface; execution jumps into an AMDP method, a class implementing the AMDP marker interface, containing SQLScript that runs directly on the HANA database. This makes the table function a black box to the rest of the CDS stack: the ABAP CDS compiler cannot inline it, cannot push filters or aggregations into it, and cannot optimize across the boundary the way it does with nested CDS views. It is declarative on the outside and fully procedural on the inside, and that mismatch is what trips people up when they treat it like an ordinary view for performance planning.

Legitimate use cases are calculations that CDS view syntax genuinely cannot express: recursive hierarchy resolution such as cost center or profit center groups, complex allocation or apportionment logic requiring loops or branching, statistical or forecasting functions available in SQLScript but not exposed as ABAP CDS built-in functions, or algorithms that need intermediate result sets and control flow. It is the wrong tool when a CASE expression, arithmetic operation, standard currency conversion annotation, or an association would produce the same result, because those stay analyzable by the optimizer and by anyone reading the model. It is also the wrong tool for transactional read paths where every millisecond matters, since the SQLScript boundary blocks the kind of push-down that keeps normal CDS views fast, and for any scenario needing write access, since table functions are read-only by construction.

Below the table function sits raw SQLScript reading database tables or other CDS entities directly, with no association navigation available inside the procedure body, only explicit joins written by hand. Above it, the table function is consumed exactly like a CDS view entity: it can be wrapped in a further CDS view to add associations, annotations, or an access control layer, exposed as a RAP read-only entity, or surfaced directly through OData. It sits at the seam between the declarative CDS layer and imperative ABAP/HANA-native code, and it replaces the older pattern of calling an AMDP class or a native SQL function module directly from an ABAP report to fetch precomputed data. Because it is a terminal node for optimization, teams typically wrap it in one thin CDS view immediately on top so the rest of the model can attach annotations without touching the SQLScript.

A profitability report needs margin figures allocated down a cost center hierarchy that changes depth and structure by company code, something no CDS association or CASE expression can walk generically. The DDL source for the table function declares input parameters for company code and period and a return structure with cost center, allocated margin, and hierarchy level. The backing AMDP class implements the marker interface and its method contains SQLScript that uses a HANA hierarchy function to traverse the cost center hierarchy table and join it against actual postings, computing allocated values level by level. A plain CDS view entity is then defined on top of the table function purely to attach annotations such as label and currency conversion metadata, and to expose an association to the cost center master data view, since the table function itself cannot expose associations. That CDS view entity is what gets projected and exposed as a RAP read-only entity for the Fiori reporting app, keeping the SQLScript layer isolated and undocumented logic out of the consuming model.

CDS table functions and AMDP work on S/4HANA on-premise and in embedded steampunk-style extensibility scenarios where a developer has full development access and HANA is guaranteed as the database. In a clean core setup targeting the public cloud ABAP environment, this pattern is out of scope: AMDP and native SQLScript are classic on-stack development, not part of the restricted extensibility language released for cloud development, and are not something an extension project can use. Teams committing to clean core should treat any existing table function as something to re-platform or replace with standard CDS modeling or a side-by-side service where possible, and should avoid writing new ones once that migration path is set as the target architecture.

This is developer territory, specifically a developer comfortable with both ABAP CDS and HANA SQLScript, working with an architect on the decision of whether procedural logic belongs here at all. Handover needs inline comments explaining the business logic in the SQLScript body, since there is no annotation layer to carry that intent, plus test data covering edge cases and a performance test run at realistic production volume, not development sample data.

Read cds view entities versus classic ddic views first to understand what a normal CDS entity looks like when the table function is not needed. Performance of nested cds views explains why push-down matters and why a table function breaks the chain. Cds associations versus joins clarifies why association navigation works differently once SQLScript is involved. Rap-unmanaged-with-legacy-code-reuse and analytical cds views are useful next steps for related patterns that also mix procedural logic or aggregation into the CDS layer.