SAP CDS in ABAP

CDS views are defined in ABAP (as source objects) but run as views on the HANA database, embodying the "code-to-data" principle: instead of pulling rows into ABAP and processing them, you define rich, reusable views (with joins, aggregations, associations and annotations) that the database computes. CDS underpins S/4HANA’s data model, embedded analytics and OData/Fiori.

@AbapCatalog.sqlViewName: 'ZVSALESSUM'
@AccessControl.authorizationCheck: #CHECK
define view Z_Sales_Summary as select from vbak
  association [1..*] to vbap as _Items on vbak.vbeln = _Items.vbeln
{
  key vbak.vbeln,
  vbak.kunnr,
  sum( _Items.netwr ) as TotalValue
} group by vbak.vbeln, vbak.kunnr

CDS annotations add meaning and behaviour, expose a view as an OData service for Fiori (@OData.publish), mark analytics semantics, define UI hints, and enforce authorization. This is how one CDS view can drive a Fiori app, an analytical query and an API.

CDS views are not written one per report. SAP's own model layers them, and following the same pattern is what keeps a landscape maintainable.

Basic interface views sit closest to the tables. One per business object, doing little more than renaming fields to readable names and joining what belongs together. They are stable, and everything else builds on them.

Composite interface views combine basic views into something meaningful: a sales order with its items, its customer and its status.

Consumption views are the ones an application or a report actually uses. They add the annotations for OData exposure, for analytics, and for how fields should be labelled and displayed.

The reason for the discipline is change. When a table changes, the basic view absorbs it and everything above continues to work. When a report needs a different field label, only the consumption view changes. Writing one flat view per requirement produces a landscape where a table change breaks forty objects.

The naming convention in SAP's own model marks which layer a view belongs to, and following a convention of your own matters more than which one you pick.

CDS views are source objects, so they live in Eclipse with the ABAP Development Tools rather than in SAP GUI. SE80 will show you that they exist and is not where they are edited, which catches out people arriving from classic ABAP.

Activation generates a database view underneath, and the view runs on the database rather than in the application server. That is the entire performance argument: the calculation happens where the data is, and only the result travels.

Testing is done in the data preview in Eclipse, and a released view can also be checked from SE16N style tooling. Where a view is exposed as an OData service, the gateway service still has to be activated before an application can reach it.

Forty minutes with Eclipse connected to a development system.

1. Create a basic view over a single table, selecting a handful of fields and giving them readable aliases. Activate it and open the data preview.
2. Create a second view that joins the first to a related object. You are now composing views rather than writing one large query.
3. Add an association rather than a join, and expose it. The consumer can navigate to the related data without paying for it when they do not.
4. Add the annotation that exposes the view as an OData service, activate the service, and call it from a browser.
5. Add an aggregation and compare the runtime against doing the same thing by selecting rows into ABAP and looping. The difference is the point of the whole technology.

CDS is the data-modelling foundation of the modern ABAP RESTful Application Programming model (RAP), the standard for building Fiori apps and services in S/4HANA. Learning CDS is the entry point to modern, cloud-ready ABAP development.

The claim that CDS is faster is true and worth understanding rather than repeating, because it is easy to write a CDS view that is slower than the ABAP it replaced.

Code pushdown means the calculation runs on the database rather than in the application server. Selecting a million rows into an internal table and summing them moves a million rows across the network. A CDS view with an aggregation moves the answer. That is the whole argument.

Where it goes wrong: a view that selects everything and leaves filtering to the consumer pushes nothing down. Filters have to reach the database, which means the consumer's WHERE clause has to be expressible against the view.

Nesting depth is the other trap. The layered model is right for maintainability, and a consumption view built on six layers generates a large statement. Usually the optimiser copes; occasionally it does not, and the fix is a flatter view for that specific case rather than abandoning the layering everywhere.

Measuring is straightforward. Run the data preview, then check the SQL trace to see what actually reached the database. If the trace shows rows being pulled and processed afterwards, the pushdown did not happen and the view needs rewriting. See CDS as an API for exposing the result once it performs.

This is the concept that separates people who write CDS from people who write SQL in CDS syntax.

A join is executed. Every row of the result carries the joined data whether the consumer wanted it or not, and the cost is paid every time.

An association is a declared relationship that is only resolved if somebody navigates it. Define an association from a sales order to its customer, and a consumer selecting only order numbers pays nothing for it. A consumer that asks for the customer name gets the join at that point.

The practical effect is that a view can expose a rich model without forcing every consumer to pay for all of it. That is why SAP's own virtual data model is full of associations rather than joins.

Two rules follow. Prefer associations for related objects a consumer might want. Use a join when the data is genuinely part of the row and every consumer needs it, such as a text description that makes the record meaningful on its own.

• Pulling data into ABAP instead of modelling in CDS.
• Ignoring annotations that unlock OData/analytics.
• Over-complex single views instead of layered, reusable ones.

• One flat view per report. It works until the tables move underneath it.
• Joins where associations belong. An association is only resolved if the consumer asks for it, and a join always costs.
• Forgetting access control. A view without an authorisation object returns everything to everyone. See the CDS reference for the annotation list and how to create one step by step.

• Naming without a convention. A landscape of views nobody can identify by layer becomes unmaintainable faster than one with a mediocre convention consistently applied.

• Exposing a view as OData without thinking about volume. An unfiltered service over a large table will be called by something, and the first time it is called without a filter you will hear about it.

Writing a view is the easy half, and designing a layered model that survives a table change is the part you do in the course.

The rule worth carrying: model in the database, not in ABAP. If you find yourself selecting rows into an internal table and looping to calculate something, there is almost always a CDS view that does it where the data already is.