CDS Annotations in SAP

by

Hello ABAPers, if you are looking for Annotations in CDS Views | CDS Annotations in SAP ABAP | ABAP CDS Annotations | CDS Views Annotations in SAP ABAP | SAP ABAP CDS Annotations With Examples | CDS Annotations in SAP ABAP CDS View Annotations then you will get details in this blog post.

AbapCatalog-Annotations in CDS Views

In order to regulate how the CDS views are processed by the SAP system and integrated with the underlying database, AbapCatalog CDS Annotations offer metadata. The main purposes of these annotations are to specify ABAP layer-related properties, regulate runtime behavior, and affect the creation of database objects.

Here are some of the most commonly used AbapCatalog annotations in CDS views:

@AbapCatalog.sqlViewName

This annotation specifies the name of the SQL view that will be generated when the CDS view is activated. The SQL view is the database representation of the CDS view and is used in SQL queries.

@AbapCatalog.sqlViewName: 'ZDEMO_VW'
define view ZDemo as select from Demo_View {
  key CustomerID,
  CustomerName
}

@AbapCatalog.extensionCategory

Specifies the type of extension for a CDS view (e.g., to indicate whether it’s an “Additive” or “Change” extension). This annotation is relevant for extending existing views in the system.

@AbapCatalog.extensionCategory: #ADD
define view ZDemoExtended as select from ZDemoData {
  key CustomerID,
  CustomerName,
  CustomerEmail
}

@AbapCatalog.preserveSemantics

Used to preserve the semantics of the CDS view, ensuring that the content and meaning of the view remain consistent even when it is transformed (e.g., in various environments or contexts).

@AbapCatalog.preserveSemantics: true
define view ZDemoData as select from ZDemo {
  key CustomerID,
  CustomerName
}

@AbapCatalog.resultType

Specifies the type of result that the CDS view returns. It can be used to define whether the CDS view returns a set of data or a scalar value.

@AbapCatalog.resultType: #TABLE
define view ZDemo as select from ZDemoData {
  key CustomerID,
  CustomerName
}

@AbapCatalog.usage

This annotation specifies the intended use of a CDS view, like whether it should be used as an analytics provider, or for transactional purposes. It helps the system determine how to optimize the execution of the view.

@AbapCatalog.usage: #TRANSACTIONAL
define view ZDemo as select from ZDemoData {
  key CustomerID,
  CustomerName
}

@AbapCatalog.tableCategory

Specifies the category of the table that will be created for the CDS view. It can define if the table is a base table, a transient table, or an analytical table.

@AbapCatalog.tableCategory: #TRANSPARENT
define view ZDemo as select from ZDemoData {
  key CustomerID,
  CustomerName
}

@AbapCatalog.index

This annotation is used to define indexes for the database table that corresponds to the CDS view. It’s useful for performance tuning.

@AbapCatalog.index: { name: 'IX_CUSTOMER_NAME', columns: ['CustomerName'] }
define view ZDemo as select from ZDemoData {
  key CustomerID,
  CustomerName
}

Example of a Full CDS View with AbapCatalog Annotations

Here’s an example that shows how these CDS annotations come together in a CDS view:

@AbapCatalog.sqlViewName: 'ZDEMO_VW'
@AbapCatalog.tableCategory: #TRANSPARENT
@AbapCatalog.index: { name: 'IX_CUSTOMER_NAME', columns: ['CustomerName'] }
define view ZDemo as select from ZDemoData {
  key CustomerID,
  CustomerName,
  CustomerEmail
}

AccessControl-Annotations in CDS Views

The authorization checks for data access in the CDS views are managed and defined using access control annotations. You can define who can access the data in the view, what can be done, and how security is implemented with these annotations.

When the CDS views are used in reporting, applications, or other consumption scenarios, the Access Control Annotations make sure that authorization checks are applied automatically. This reduces the need for distinct authorization logic in applications by enforcing data security and compliance policies directly in the data layer.

Here are the most important AccessControl annotations that can be used in CDS views:

@AccessControl.authorizationCheck

The @AccessControl.authorizationCheck annotation defines the type of authorization check that is applied to the CDS view. It specifies whether the data access should be restricted based on user authorizations. There are two main options for this annotation:

  • #CHECK: The CDS view will enforce authorization checks on the data it represents. If a user does not have the necessary authorization, they will not be able to access the data.
  • #NOT_CHECK: No authorization check will be performed. This is typically used for views that don’t need to enforce any user-specific authorization.

In this example, authorization checks will be enforced when users try to access data in the ZCustomer view.

@AccessControl.authorizationCheck: #CHECK
define view ZCustomer as select from ZCustomerData {
  key CustomerID,
  CustomerName,
  CustomerEmail
}

@AccessControl.authorizationProfile

The @AccessControl.authorizationProfile annotation specifies the name of an authorization profile that should be used for the authorization check. This is useful for more fine-grained control over which roles or permissions are required to access the data.

@AccessControl.authorizationCheck: #CHECK
@AccessControl.authorizationProfile: 'Z_CUST_PROFILE'
define view ZCustomer as select from ZCustomerData {
  key CustomerID,
  CustomerName,
  CustomerEmail
}

Here, the authorization check will be done based on the Z_CUST_PROFILE authorization profile, meaning that only users who have this profile will be allowed to access the ZCustomer view.

@AccessControl.fieldSecurity

The @AccessControl.fieldSecurity annotation is used to define specific field-level security for the CDS view. It allows you to restrict access to specific fields in the view, so that certain users might only be able to see some fields and not others.

  • #READ: The field will be visible for read access.
  • #NONE: The field will be hidden, and users won’t be able to see the data.
@AccessControl.authorizationCheck: #CHECK
@AccessControl.fieldSecurity: { CustomerID: #READ, CustomerEmail: #NONE }
define view ZCustomer as select from ZCustomerData {
  key CustomerID,
  CustomerName,
  CustomerEmail
}

In this example, the CustomerID field will be visible to users (i.e., #READ), but the CustomerEmail field will not be visible (#NONE).

@AccessControl.grantor

The @AccessControl.grantor annotation is used to define who is allowed to grant access to this CDS view. This is helpful for scenarios where access needs to be granted or restricted based on a specific user’s role or authorization.

@AccessControl.grantor: 'Z_ADMIN_ROLE'
define view ZCustomer as select from ZCustomerData {
  key CustomerID,
  CustomerName,
  CustomerEmail
}

This means that only users with the Z_ADMIN_ROLE role would be able to grant access to this CDS view to other users.

@AccessControl.restrictAccess

The @AccessControl.restrictAccess annotation is used to define access restrictions at the data level, typically based on conditions or user attributes. You can use this annotation to apply dynamic authorization checks based on user-specific data.

This annotation is less commonly used but can be important in highly specialized scenarios where access to records is determined based on complex logic.

@AccessControl.masking

Field-level data masking can be implemented using the @AccessControl.masking annotation. This allows you to apply dynamic data masking rules, so users with insufficient authorization can still access the CDS view, but sensitive data is hidden or obfuscated.

This annotation is often used in scenarios where users can access a dataset but should only see a masked version of sensitive fields (e.g., in finance or HR data).

Leave a Comment