SAP CDS Views

SAP delivers a large virtual data model of CDS views (interface views prefixed I_, consumption views C_, private P_, etc.) that expose S/4HANA data for reuse, analytics and OData. Custom views (Z_/Y_) build on them. Each view has fields, associations and annotations.

The prefix tells you what a view is for and whether you may build on it, which makes the naming convention the fastest filter in the whole virtual data model.

• I_ interface views. The reuse layer, and what you should build on.
• C_ consumption views. Shaped for a specific application or analytical query, not intended as a reuse source.
• P_ private views. Internal to a component. Using one is building on something SAP may change without notice.
• E_ extension include views, where extensibility is anticipated.
• Z_ and Y_ your own.

Alongside the prefix sits the release contract, which matters more than the prefix. A view released for use by SAP carries a stability guarantee; an unreleased view may be changed or removed in a support package and nothing will warn you. Checking the release state before building on a view is the difference between a report that survives an upgrade and one that does not.

• Use ADT (Eclipse) to browse and preview CDS views.
• Check the view’s fields, associations and annotations.
• Prefer released interface views (I_) as reuse sources.
• Use the data preview to see the data a view returns.

Two more routes to the same information. The view browser application lists released views with their fields and lets you preview data without a development environment, which is often enough for a functional consultant. And SE11 still shows the generated database object behind a view, which is occasionally the quickest way to confirm what actually exists.

Opening a CDS view definition, four things carry the information you usually want.

The data source and any joins, which tell you what it is actually reading. A view over a view over a view is common, and following the chain is how you find out whether something is expensive.

The fields, with their names and types. Note that CDS field names are frequently readable rather than the classic short table field names, so the same data has two names depending on which layer you are in.

The associations, which are the reusable joins. An association is defined once and used by anybody consuming the view, which is the mechanism that makes the model composable rather than a pile of views.

The annotations, which carry everything that is not the data itself: whether it is exposed as an OData service, how a field should be labelled and formatted, semantic meaning such as which field is the currency for an amount, and the analytical role of each field.

Annotations are where most of the surprises live, because a view can be functionally correct and behave oddly in an application entirely because of them.

The CDS virtual data model is the backbone of S/4HANA data access, analytics and Fiori. Knowing how to find and reuse released CDS views (rather than querying raw tables) is central to modern development and a growing reference need.

The practical rule that follows from all of this: look for a released view before writing a query. SAP has already modelled most of what a report needs, with the joins, the currency handling and the field labels correct, and reproducing that from raw tables is work that also has to be maintained. See CDS views in ABAP, creating a CDS view, CDS examples and CDS and APIs.

Version note: the virtual data model exists on S/4HANA and not on ECC, so none of this transfers backwards. Within S/4HANA, the set of released views grows with each release and the release contract itself has become stricter over time, which is why material a few years old sometimes recommends building on views that are now marked private.

• Guessing instead of using the reference tools.
• Editing/using without understanding the object.
• Relying on memory for details you can look up.