ABAP CDS Views

An ABAP CDS view is source code that the ABAP system turns into a database view:

1. A developer creates a data definition in ABAP Development Tools and writes a DEFINE VIEW ENTITY statement: data sources, selected fields, calculations, joins and associations to other CDS entities.
2. Annotations add metadata: labels, semantics such as currency or unit fields, analytics roles, UI hints and OData exposure settings.
3. On activation, the system creates the CDS entity and the corresponding view on the database, so the logic runs where the data sits.
4. Consumers read the view: ABAP SQL in programs, OData services built with RAP, analytical queries and released APIs.
5. If a CDS access control exists for the view, its conditions are applied to every read of the view.

Associations are a key difference from classic database views: they declare a relationship once, and the join is only built when a consumer follows the association path. An ABAP CDS view is therefore a reusable semantic data model, not just a stored SELECT.

SAP's documentation lists faster activation, simpler syntax and stricter checks among the reasons for view entities. Existing DDIC-based views keep working, and ABAP Development Tools offers a migration wizard, documented on-premise as of SAP S/4HANA 2023 FPS00. RAP in strict mode also expects view entities as data sources. For any new development, view entities are the variant of ABAP CDS views to use.

SAP S/4HANA ships thousands of CDS views organized as the virtual data model (VDM). Basic interface views expose business entities close to the tables, composite interface views combine them, and consumption views serve a specific app or query. The name prefix signals the layer: I_ for interface views, such as I_SalesOrder, and C_ for consumption views.

What matters for customers is the release status of a view:

• Released for key user extensibility (contract C1): usable in key user tools such as the Custom CDS Views app.
• Released for cloud development (contract C1): usable by developers in ABAP Cloud, including developer extensibility.
• Not released: visible in the system but without a stability contract; SAP may change it in any upgrade.

A key user at Alder Manufacturing who needs open purchase orders by supplier, for example, builds a custom CDS view on released purchasing views instead of reading tables. In the virtual data model, the release status decides whether building on an ABAP CDS view is safe.

A CDS view supplies data and metadata; other objects turn it into an app:

1. Current path (RAP): CDS view entities form a business object, a behavior definition adds operations, projection views tailor it, and a service definition plus a service binding expose it as OData V2 or V4.
2. SAP Fiori elements reads the UI annotations from that service and renders a list report or object page.
3. Analytical apps consume CDS analytical queries, defined as transient view entities in recent releases and with the deprecated @Analytics.query annotation in older ones.

Older systems use earlier paths: the @OData.publish annotation of the ABAP Programming Model for SAP Fiori, or an SAP Gateway project that uses the CDS view as a referenced data source; check which of them your release still supports. In every path, the ABAP CDS view defines what the data is; transactional behavior comes from RAP or, in the predecessor model, from BOPF.

The strengths are substantial. One model serves OData, analytics and ABAP SQL alike; calculations run in the database; annotations carry semantics that every consumer understands; and access control is declared next to the data.

The limits follow from what a view is:

• Read model only. A CDS view does not create, change or validate data. Transactions need a RAP business object on top.
• Declarative SQL, not procedural logic. Complex algorithms move to CDS table functions implemented in AMDP, or to ABAP.
• Performance depends on the stack. Views built on views on views can produce heavy SQL; associations used carelessly multiply joins.
• Release-bound. Syntax features arrive release by release; a view written for the SAP BTP ABAP environment may not activate on an older on-premise release.

ABAP CDS views are the right place for data semantics, not for process or transaction logic.

1. Creating new DDIC-based views. They are obsolete; start with view entities.
2. Building on unreleased SAP views. It works until an upgrade changes the view. Check the release contract first.
3. Forgetting access control. Without a CDS access control, anyone authorized to read the view sees all of its data. Add an access control and keep app start authorizations as well.
4. Writing UI annotations into the data definition. Metadata extensions keep the model readable and let UI metadata change on its own schedule.
5. Confusing ABAP CDS with CAP CDS. Same idea and similar syntax, different runtime: a CAP model does not activate in an ABAP system.

Most problems with ABAP CDS views come from lifecycle decisions, not from SQL.