CDS - Types of Data Definitions

Table of contents

• Introduction
• Types
• VIEW
• VIEW ENTITY
• PROJECTION
• CUSTOM ENTITY
• HIERARCHY
• ABSTRACT ENTITY
• EXTERNAL ENTITY
• TABLE ENTITY
• TABLE FUNCTION
• Overview
• Search
• Complete Example
• Conclusion

In this article, we'll look at different types and how we can use them in ABAP development.

 

Introduction

ABAP now offers numerous data definitions with different keywords that we can use in various scenarios. Objects like the View have even become obsolete, at least if you're working on a modern system. Therefore, it's time to take a look at the multitude of objects in this category.

 

Types

In this chapter, we'll examine the different types in detail and discuss possible use cases. Here you will also find an example of an implementation for each object.

 

VIEW

The View was one of the first Core Data Services developed by SAP to represent the modeling of data models in ABAP. The View always uses an SQL View, which is stored as an additional artifact in the database. This also gives the View some disadvantages, such as dependencies, poor modifiability, and slow activation. The data source is a table or another View for creating View Stacks in the data model.

@AbapCatalog.sqlViewName: 'ZBSIETYCLASSVIEW'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Classic CDS View'
define view ZBS_I_ETypeClassicView
  as select from zbs_dmo_partner
{
  key partner               as Partner,
      name                  as Name,
      street                as Street,
      city                  as City,
      country               as Country,
      payment_currency      as PaymentCurrency
}

 

VIEW ENTITY

The View Entity is the successor to the View and no longer requires any additional artifacts. Activation, extension, and customization are faster, and fields within the View are easier to access. In a current release, you should only use such Views and avoid the classic View. The data source here is a table or other objects containing data (Table Entity, External Entity) from the Core Data Services.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'View Entity'
define view entity ZBS_I_ETypeViewEntity
  as select from zbs_dmo_partner
{
  key partner          as Partner,
      name             as Name,
      street           as Street,
      city             as City,
      country          as Country,
      payment_currency as PaymentCurrency
}

 

PROJECTION

A projection is part of a RAP object and can only be used for views that are used in a business object. They represent the consumption layer in the data model and follow different rules. For example, a provider contract is defined; no new associations can be created in the data model here, and virtual fields are possible at this level.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection'
define root view entity ZBS_C_ETypeProjection
  provider contract transactional_query
  as projection on ZBS_I_ETypeViewEntity
{
  key Partner,
      Name,
      Street,
      City,
      Country,
      PaymentCurrency
}

 

CUSTOM ENTITY

The Custom Entity itself does not have its own data source, but represents a structure externally. An additional annotation can define a query class, which is executed by the SADL framework and provides data for this structure. Within the ABAP class, all possible functions can then be executed, making it a flexible development method. However, this only works with the entity in an OData service.

@EndUserText.label: 'Custom Entity'
@ObjectModel.query.implementedBy: 'ABAP:ZCL_BS_DEMO_ETYPE_QUERY'
define custom entity ZBS_I_ETypeCustomEntity
{
  key uuid        : sysuuid_x16;
      description : abap.sstring( 350 );
      counter     : abap.int4;
}

 

HIERARCHY

If you want to represent a hierarchy, there is a dedicated type for this among the CDS artifacts. This defines the relationships between the information, outputs additional fields, and also determines the order and sorting. The hierarchy can now also be used to create a tree in Fiori Elements.

@AccessControl.authorizationCheck: #NOT_REQUIRED
define hierarchy ZBS_I_ETypeHierarchy
  as parent child hierarchy(
    source ZBS_I_DMOTeamView
    child to parent association _Leader
    start where
      TeamLeader is initial
    siblings order by
      UserIdentification
  )
{
  key UserIdentification,
      TeamLeader,
      TeamName
}

 

ABSTRACT ENTITY

The abstract entity is a kind of structural description and does not necessarily require a key definition or key fields. This allows for the implementation of simple input popups, but also complex and deep structures for advanced actions. UI annotations can also be defined for the popup so that they can be easily applied during later use.

@EndUserText.label: 'Abstract Entity'
define abstract entity ZBS_S_ETypeAbstractEntity
{
  uuid        : sysuuid_x16;
  description : abap.sstring( 350 );
  counter     : abap.int4;
}

 

EXTERNAL ENTITY

External entities are relatively new and represent entities from external systems. For example, if you want to connect a HANA database in the cloud or integrate an SQL service via another system, then the local representation is an external entity. Currently, static and dynamic connections are offered for this. Within the entity, we can map the fields to our target types, for example, if we want to harmonize the data.

@EndUserText.label: 'External Entity'
define external entity ZBS_E_ETypeExternalEntity external name BUT000
{
  key BusinessPartner : abap.char(10) external name PARTNER;
      Type            : abap.char(1)  external name TYPE;
      BPEXT           : abap.char(20);
      BU_SORT1        : abap.char(20);
      BU_SORT2        : abap.char(20);
}
with federated data provided at runtime

 

TABLE ENTITY

The Table Entity is the newest artifact of the CDS family and is intended to eventually replace the classic DDIC table. A corresponding representation of the artifact exists as a database/table, and data can be stored in it. The entity can now also be used for modeling RAP applications.

@ClientHandling.type: #CLIENT_DEPENDENT
@AbapCatalog.deliveryClass: #APPLICATION_DATA
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Table Entity'
define table entity ZBS_T_ETypeTableEntity
{
  key MyUUID          : sysuuid_x16;
      SemanticKey     : abap.char( 15 );
      LongDescription : abap.string null;
      ForeignKey      : abap.char( 10 );

      _KeyAsso        : association of exact one to one ZBS_T_ETypeAssociation on _KeyAsso.ForeignKey = $projection.ForeignKey;
}

 

This allows us to create associations and compositions directly at the table level. We use built-in types or simple types to define the fields. We can also set fields to NULL, and in the case of a string, we even have to, in which case only the native data types will work.

 

TABLE FUNCTION

The table function offloads reusable components and queries to the database. This allows you to read, check, and modify data without doing so in the ABAP stack. This provides good code pushdown to the database. A class must be implemented for the logic, and then SQL scripting must be done within the method.

@EndUserText.label: 'Table Function'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@ClientHandling.type: #CLIENT_DEPENDENT
@ClientHandling.clientSafe: true
@ClientHandling.algorithm: #SESSION_VARIABLE
define table function ZBS_F_ETypeTableFunction
  with parameters
    partner : abap.char( 10 )
returns
{
  Client   : abap.clnt;
  Material : abap.char(5);
  Discount : abap.dec(5,2);
}
implemented by method
  zcl_bs_demo_etpye_tfunc=>get_all_discounts;

 

Overview

Here is once again a brief overview of the different types from above and their use within ABAP development. This gives you a quick overview of the functions and possibilities.

 

The individual categories have the following meaning:

• Data - Provides the artifact with data.
• Scope - Where can the object be used. Everywhere in ABAP, this would be the standard; otherwise, the restrictions are stated.
• Modeling - Can this object be further modeled, and does it serve as a basis for doing so?
• Release - From which on-premises release is the object available?

 

Search

Currently, all objects are stored in the Data Definition area, which makes searching somewhat more difficult, and differentiation currently only works via the different naming conventions. However, you can currently search for the corresponding source types using the search function (CTRL + SHIFT + A). You can restrict the search to other types using the `sourcetype` attribute.

 

This allows you to search for specific views if, for example, the internal naming conventions haven't been followed.

 

Complete Example

All objects from this example can be found in our GitHub repository for CDS examples. We have created a new package, ZBS_DEMO_CDS_TYPES, to delimit the artifacts and examples. In this Commit you will find all changes and new objects.

 

Conclusion

With this article, you should now have an overview of the various artifacts, how and where you can use them, and what they are needed for.