Virtual Data Model (VDM)

The virtual data model stacks CDS views on top of the database tables, and each layer may only read from the layer below:

1. Basic interface views sit directly on the tables and are the only VDM views that read them. They rename cryptic table fields into business terms and add annotations and associations. Annotation: @VDM.viewType: #BASIC.
2. Composite interface views combine basic views or other composite views into new semantic entities, for example a cube for analytics. Annotation: @VDM.viewType: #COMPOSITE.
3. Consumption views serve one purpose, such as a specific transactional or analytical app. They are the only VDM view type that can act as an analytical query. Annotation: @VDM.viewType: #CONSUMPTION.

Basic and composite views form the reuse layer; a reuse view typically represents one business object node, such as I_SalesOrder. Restricted reuse views look similar but are meant for SAP's own reuse only. The virtual data model is therefore a contract between layers, not just a collection of views.

SAP's naming convention puts the view type in a prefix, followed by a semantic name and optional suffixes:

Suffixes refine the purpose: Query for analytical queries, Cube for cube views, TP for transactional processing views and Text for text views. A version number such as _2 marks a successor view.

One trap: in SAP's naming guide for custom RAP development, R_ marks the base view entity of a business object, while in the SAP S/4HANA virtual data model R_ marks restricted reuse views. The prefix of a VDM view tells you its intended role before you open it.

Visibility is not permission. Only views that SAP has released under the C1 stability contract are safe to reuse, and SAP releases them only for certain view types:

• Can be released for customers: basic and composite interface views, consumption views of type analytical query, and derivation functions.
• Typically SAP-internal: restricted reuse views, remote API views, private views and abstract entities.

Release can be for key user extensibility, used in apps such as Custom CDS Views, or for cloud development in ABAP Cloud. Unreleased views can change in any upgrade. To check a view, open it in the View Browser app or look at its API state in ABAP Development Tools. In the virtual data model, release status, not existence, decides what a custom extension may depend on.

• SAP Fiori apps: transactional processing views form RAP business objects, and consumption views feed SAP Fiori elements apps through OData services.
• Embedded analytics: composite views shaped as cubes and dimensions, topped by analytical query consumption views, drive analytical apps without replicating data.
• APIs: remote API views form the basis for external APIs published on the SAP Business Accelerator Hub.
• Extensions: key users build custom CDS views on released interface views, for example a view of open purchase orders per supplier for Alder Manufacturing, instead of reading tables.
• Data extraction: the Analytics.dataExtraction.enabled annotation marks views as suitable for data replication, for example to SAP BW/4HANA.

The virtual data model gives apps, analytics and integrations one shared business vocabulary instead of separate table readers.

1. Building on an unreleased view. It works until the next upgrade changes it. Check the release status first.
2. Reusing consumption views as building blocks. Consumption views serve one app; build on interface views instead.
3. Reading tables next to the VDM. Custom code that bypasses basic views loses business field names, associations and access controls.
4. Reading R_ the wrong way. Restricted reuse views are not for customer reuse, whatever a custom naming convention says.

Most virtual data model problems come from ignoring the layer and release rules that keep the model stable.