Best Practices for SAP ABAP CDS Views

CDS Views
Close up view on violin's play.

Best practices collection for SAP ABAP CDS views. Please leave a comment if you would like to contribute a best practice or to make any other remark.

See here for the differences between SAP ABAP CDS views and SAP HANA CDS views.

Use the Virtual Data Model

Incorporate your SAP ABAP CDS views into an existing virtual data model or create a virtual data model if no virtual data model exists yet such as in an ECC.

SAP VDM location in an SAP system.
The virtual SAP ABAP CDS views virtual data model resides in the application server in an on-premise SAP system.

The virtual data model is the fundamental data model for applications. For both transactional and analytical applications, plus APIs.

The virtual data model

  • avoids redundant ABAP CDS views,
  • provides a consistent model,
  • helps to maintain an overview,
  • structures the data into logical units from a business perspective, and
  • provides consistent names.

The virtual data model consists of four layers:

  • consumption views,
  • composite interface views,
  • basic interface views, and
  • database tables.
SAP VDM layers.
The SAP virtual data model layers.

The ABAP CDS views in a virtual data model are supposed to be marked with the annotation @VDM.viewType: #<VDM_CDS_VIEW_TYPE>. ‘<VDM_CDS_VIEW_TYPE>‘ is either

  • #BASIC,
  • #COMPOSITE, or
  • #CONSUMPTION.

An ABAP CDS can only be one type of a virtual data model CDS view type.

Database Tables

The transparent tables of the database such as the MARA, VBAK, or USR01.

Basic Interface Views

The annotation for a basic interface view is @VDM.viewType: #BASIC.

Basic interface views are built on top of the database tables. Basic interface views are the bottom of the virtual data model.

Only basic interface views access the database tables. All other CDS views reuse and thus receive their data from the basic interface views.

A basic interface view is supposed to select from a single database table. A basic interface view is not supposed to convert or calculate any database table value.

The purpose of a basic interface view is to

  • mirror the database table in a CDS view shape,
  • transform the technical names of a database table into human-readable names that are used in the business,
  • transform the technical types of a database table via cast operation to make them more precise, and
  • enhance database table fields with additional semantic annotations.

Additional semantic annotations in basic interface views are supposed to document the database table field semantic.

Semantic annotations are, for example:

Field AnnotationSemantic
@Semantics.amount.
currencyCode
Amount that references to a currency (@Semantics.quantity.
unitOfMeasure).
@Semantics.currencyCodeCurrency.
@Semantics.quantity.
unitOfMeasure
Amount that references to a unit (@Semantics.unitOfMeasure).
@Semantics.textText in human-readable form
@Semantics.unitOfMeasureUnit

Composite Interface Views

The annotation for a composite interface view is @VDM.viewType: #COMPOSITE.

Composite interface views are built on top of basic interface views and other composite interface views. Composite interface views are the middle layer in the virtual data model.

Composite interface views project data for specific purposes such as an application and thus a consumption view or combine data from multiple data sources to get reused from other composite views.

Analytical CDS views such as fact sheets, cubes, and dimensions use composite interface views as well.

The purpose of a composite interface view is to

  • be reused,
  • project data for a specific purpose, and
  • combine data from multiple data sources.

Consumption Views

The annotation for a consumption view is @VDM.viewType: #CONSUMPTION.

Consumption views are built on top of composite interface views. Consumption views are the top of the virtual data model.

Consumption views are meant to be consumed as the name says. For example, by

Consumption views are not meant for general reuse. On the contrary, consumption views are made to provide exactly the data for an application or system needs.

Consumption views come in three flavors:

  • consumption views such as a transactional consumption view,
  • analytical consumptions views such as a cube, and
  • remote API consumption views such as to define a web service API.

Consumption views can control through annotations the properties of transactional and analytical applications such as the application’s layout and behavior.

Use Type Annotations for Basic Views, Composite Views, and Consumption Views

Use the respective type annotation for basic, composite, and consumption views in the DDL file:

  • @VDM.viewType: #BASIC
  • @VDM.viewType: #COMPOSITE
  • @VDM.viewType: #CONSUMPTION
@VDM.viewType: #BASIC
define view I_BusinessPartner ... {

	key BusinessPartner, 
	...

}

SAP uses the annotation @VDM.viewType for internal structuring and interpretation of the CDS views. For example, in the Fiori View Browser in S/4 HANA systems.

Use Naming Conventions for CDS views (THE SAP WAY)

The SQL View Name can have maximal 16 characters, and the CDS View name can have maximal 30 characters.

Use Z, Y, or the registered namespace of the company as the first character in every name to signal that it is a custom file and not an SAP file.

And when referring to SAP business entities reuse the field names defined by SAP. When creating own field names or when extending SAP delivered views then use as a prefix a YY or ZZ.

This is the way SAP names its CDS views. You can find an alternative way to name your CDS views below.

SQL View Name

<PREFIX><DESCRIPTION> – for example, ZIBPADDR.

The <PREFIX> consists of

  1. Y, Z or the registered namespace of the company, and
  2. I (interface view – basic & composite views), C (consumption view), A (remote API view), P (private VDM view), E (extension include view), X (VDM view extension)

The <DESCRIPTION> is

  1. all written together,
  2. all in upper case letters,
  3. if the view is a value helper CDS view a VH at the end, for example, ZCBPADDRVH. A value helper CDS view is always a consumption view, and
  4. if the view is a transactional object CDS view or a transactional consumption view a TP at the end, for example, ZCFOOTP.

CDS View Name

<PREFIX><Description> – for example, ZI_BPNameAddress.

The <PREFIX> consists of

  1. Y, Z or the registered namespace of the company,
  2. I (interface view – basic & composite views), C (consumption view), A (remote API view), P (private VDM view), E (extension include view), X (VDM view extension), and
  3. an underscore _.

The <Description> is

  1. all written together,
  2. in CamelCase,
  3. if the view is a value helper CDS view a VH at the end, for example, ZC_BPNameVH. A value helper view is always a consumption view, and
  4. if the view is a transactional object CDS view or a transactional consumption view a TP at the end, for example, ZC_FooTP.

Use Naming Conventions for CDS Views (NOT THE SAP WAY)

The SQL View Name can have maximal 16 characters, and the CDS View name can have maximal 30 characters.

Use Z, Y, or the registered namespace of the company as the first character in every name to signal that it is a custom file and not an SAP file.

And when referring to SAP business entities reuse the field names defined by SAP. When creating own field names or when extending SAP delivered views then use as a prefix a YY or ZZ.

In my opinion, there are better ways to name your CDS views than SAP does:

  • differentiate between basic and composite views,
  • mark a value helper CDS view not with a suffix but with a prefix, and
  • mark transactional CDS view not with a suffix but with a prefix.

At the latest, when you add analytic CDS views, you get the feeling that you need to come up with other naming conventions for your CDS views than how SAP handles it.

SQL View Name

<PREFIX><DESCRIPTION> – for example, ZIBPADDR.

The <PREFIX> consists of

  1. Y, Z or the registered namespace of the company, and
  2. B (basic view), O (composite view), C (consumption view), A (remote API view), P (private VDM view), E (extension include view), X (VDM view extension).

The <DESCRIPTION> is

  1. all written together,
  2. all in upper case letters,
  3. if the view is a value helper CDS view a V right after the C for consumption view, for example, ZCVBPADDR. A value helper CDS view is always a consumption view, and
  4. if the view is a transactional object CDS view or a transactional consumption view a T right after the B for basic, O for composite, or C for consumption view, for example, ZCTFOO.

CDS View Name

<PREFIX><Description> – for example, ZI_BPNameAddress.

The <PREFIX> consists of

  1. Y, Z or the registered namespace of the company,
  2. B (basic view), O (composite view), C (consumption view), A (remote API view), P (private VDM view), E (extension include view), X (VDM view extension), and
  3. an underscore _.

The <Description> is

  1. all written together,
  2. in CamelCase,
  3. if the view is a value helper CDS view a V right after the C for consumption view, for example, ZC_BPNameVH. A value helper CDS view is always a consumption view,
  4. if the view is a transactional object CDS view or a transactional consumption view a T right after the B for basic, O for composite, or C for consumption view, for example, ZCT_Foo.

Use Naming Conventions for Analytical CDS Views (THE SAP WAY)

The SQL View Name can have maximal 16 characters, and the CDS View name can have maximal 30 characters.

Use Z, Y, or the registered namespace of the company as the first character in every name to signal that it is a custom file and not an SAP file.

And when referring to SAP business entities reuse the field names defined by SAP. When creating own field names or when extending SAP delivered views then use as a prefix a YY or ZZ.

SQL View Name

<PREFIX><DESCRIPTION><SUFFIX> – for example, ZBPFACT.

The <PREFIX> consists of Y, Z or the registered namespace of the company.

The <DESCRIPTION> is

  1. all written together, and
  2. all in upper case letters.

The <SUFFIX> is either

Use Naming Conventions for Analytical CDS Views (NOT THE SAP WAY)

The SQL View Name can have maximal 16 characters, and the CDS View name can have maximal 30 characters.

Use Z, Y, or the registered namespace of the company as the first character in every name to signal that it is a custom file and not an SAP file.

And when referring to SAP business entities reuse the field names defined by SAP. When creating own field names or when extending SAP delivered views then use as a prefix a YY or ZZ.

In my opinion, there are better ways to name your analytical CDS views than SAP does. Instead of suffixes such as Cube or Query rather prefixes such as C for a cube or Q for a query.

SQL View Name

<PREFIX><DESCRIPTION> – for example, ZFBMARA.

The <PREFIX> consists of

  1. Y, Z or the registered namespace of the company, and
  2. FB (fact basic view), FO (fact composite view, DB (dimension basic view), DO (dimension composite view), CB (cube basic view), CO (cube composite view), or QC (query consumption view).

The <DESCRIPTION> is

  1. all written together, and
  2. all in upper case letters.

CDS View Name

<PREFIX><Description> – for example, ZFB_Mara.

The <PREFIX> consists of

  1. Y, Z or the registered namespace of the company,
  2. FB (fact basic view), FX (fact composite view, DB (dimension basic view), DO (dimension composite view), CB (cube basic view), CO (cube composite view), or QC (query consumption view), and
  3. an underscore _.

The <Description> is

  1. all written together, and
  2. in CamelCase.
No Comments

Most Recent Articles

Will SAP UI5 replace the SAP Web UI?

SAP Full Forms

More Similar Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu