RAP CDS View Entity

Published: November 2025

🚀 SAP RAP CDS View Entity – Overview

In SAP’s ABAP RESTful Application Programming Model (RAP), business objects are designed using CDS View Entities rather than classic CDS views. A CDS View Entity is:

• The core modeling artifact for RAP
• Used to define your data model (persistence, interfaces, projections, etc.)
• Lightweight and strict (no DDIC artifacts are generated)

View Entities only generate a runtime object, not an SQL view in the DB (except when using @AbapCatalog.sqlViewName, which is no longer used in RAP View Entities).

🧱 Types of CDS View Entities in RAP

In RAP, CDS View Entities are used in layers:

1. Base (Interface / Data Model) View Entity
2. Projection (Consumption) View Entity

✅ 1. Base View Entity vs. Consumption View (ABAP CDS)

In ABAP CDS, the virtual data model (VDM) is layered. Two major layers you often work with are:

• Base View Entity → Data source representation
• Consumption View → UI/analytics/service representation

A. Base View Entity

Purpose:

Represents the technical data model and provides a reusable, stable foundation. It sits close to the database tables and focuses on correctness and semantic consistency.

Characteristics:

• Foundation layer
  • Often built directly on database tables or other base views.
  • Contains core semantics such as:
  • @ObjectModel.text.element
  • Currency code, unit of measure
  • Associations to master data
• Stable and reusable
  • Other CDS views (cube, consumption views, extension views) reuse it.
  • It should not contain UI-specific annotations.
• Rich semantics
  • Defines field relationships:
  • Quantity fields
  • Unit fields
  • Currency fields
• Focus on correctness, not presentation
  • No UI annotations like Fiori Annotation (UI.*)
  • No analytical annotations like (@AnalyticsDetails etc.)
• Normally not exposed directly to apps or OData services.

Example of Base View:

	
	@AccessControl.authorizationCheck: #NOT_REQUIRED
	@EndUserText.label: 'Student Managed'
	@Metadata.ignorePropagatedAnnotations: true
	define root view entity ZI_STUDENT_M_BD as select from zstudent_m_bd
	{
		key id as Id,
		firstname as Firstname,
		lastname as Lastname,
		age as Age,
		course as Course,
		courseduration as Courseduration,
		status as Status,
		gender as Gender,
		dob as Dob,
		lastchangedat as Lastchangedat,
		locallastchangedat as Locallastchangedat
	}
	

B. Consumption View

Purpose:

Represents the presentation/analytic layer—the final view exposed to UI or external consumption.

Characteristics:

• Top Layer Built on top of cubes, composite views, or base views.
• Contains UI and analytical annotations, e.g.:
  • @UI.*
  • @Analytics.query: true
  • @OData.publish: true
  • @Consumption.filter
• Designed for specific use-cases
  • Fiori analytical apps
  • Smart templates
  • API/OData services
  • Reports
• May hide or rename technical fields
  • User-friendly field labels
  • Selection parameters
  • Custom calculations
• Not meant for reuse
  • Typically, other CDS views do NOT consume a consumption view.

Example of Projection/Consumption View:

	
	@AccessControl.authorizationCheck: #NOT_REQUIRED
	@EndUserText.label: 'Student Managed'
	@Metadata.ignorePropagatedAnnotations: true
	@Metadata.allowExtensions: true
	define root view entity ZC_STUDENT_M_BD
		provider contract transactional_query
		as projection on ZI_STUDENT_M_BD as Student
	{
		@EndUserText.label: 'Student ID'
		key Id,
		@EndUserText.label: 'First Name'
		Firstname,
		@EndUserText.label: 'Last Name'
		Lastname,
		@EndUserText.label: 'Age'
		Age,
		@EndUserText.label: 'Course'
		Course,
		@EndUserText.label: 'Course Duration'
		Courseduration,
		@EndUserText.label: 'Status'
		Status,
		@EndUserText.label: 'Gender'
		Gender,
		@EndUserText.label: 'DoB'
		Dob
	}
	

Supplementary Information

root

	
	...
	define root view entity ZI_STUDENT_M_BD
		...
	{
		...
	}
	

In RAP, a Business Object is modeled using CDS views. Every BO has a root entity, which acts as:

• The top-level node of the BO
• It represents the main business object (e.g., Sales Order, Purchase Request, Travel).
• All other nodes (child / composition entities) derive from the root.
• The main entry point for Create / Read / Update / Delete

Operations like create, update, delete are performed starting from the root.

• Defines the overall identity

The root entity contains the key fields that uniquely identify the instance of the BO.

There is always only one Entity which will represent as ROOT.