Skip to Content
Technical Articles

A new generation of CDS views: CDS view entities

With ABAP release 7.55, a new type of CDS view is available: in official terminology, it’s called CDS view entity. And it has come to replace the “classic” CDS DDIC-based views that have been around for years.

This blog post provides the following information:

  1. Motivation: why has SAP developed a new type of CDS view?
  2. Key differences between DDIC-based views and CDS view entities
  3. Outlook: transition from DDIC-based views to CDS view entities

Motivation: why has SAP developed a new type of CDS view?

A CDS DDIC-based view is defined using the statement DEFINE VIEW. This kind of CDS view was first released with release 7.40, SP05 and it was for many years the only available kind of CDS view.

Since release 7.55, CDS view entities are available. They are defined using the statement DEFINE VIEW ENTITY. They have evolved from CDS DDIC-based views, serve the same purpose and have the same structure as their predecessor. But they offer several advantages over the “classic” CDS DDIC-based views, such as the following:

  • No additional ABAP Dictionary view is created on activation.
  • Improved performance during view activation.
  • Optimization and simplification of syntax.
  • Stricter syntax checks indicate problematic situations more explicitly, for example, annotation checks.

Key differences between DDIC-based views and CDS view entities

CDS view entities are a new and improved version of CDS DDIC-based views. Although very similar, CDS view entities are easier to use, and offer many small improvements and enhanced features.

Here are some principal ways in which CDS view entities differ from CDS DDIC-based views:

  • There’s no SQL view. The annotation @AbapCatalog.sqlViewName is not required and each view has only one name.
  • Fewer annotations are required. For example, client handling takes place implicitly and doesn’t require any development effort.
  • Annotations are checked to ensure that only annotations defined as CDS objects in a CDS annotation definition can be used.
  • Expressions can be nested within each other. Situations that previously required a view stack can now be implemented within a single view.
  • Operand positions, such as the WHERE-clause, allow a greater variety of operands.
  • Some features that haven’t been widely used are no longer supported in view entities. Here are some examples (but the list is not exhaustive):
    • In DDIC-based views it is possible to assign alternative element names to elements of a SELECT-list using a name list. CDS view entities don’t support name lists.
    • Domain fixed values in front of literals cannot be defined in CDS view entities.
    • The syntax SELECT * to select all elements from the data source is supported in CDS DDIC-based views, but not in CDS view entities.

Additional features, such as typed literals to enhance type safety, and optimized buffer handling, are planned for future releases.

The following example compares a CDS DDIC-based view with a CDS view entity:

CDS DDIC-based view CDS view entity
@AbapCatalog.sqlViewName: 'DEMO_CDS_JOIN'
@AbapCatalog.compiler.compareFilter: true
@ClientHandling.algorithm: #SESSION_VARIABLE
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_ALLOWED 
define view demo_cds_scarr_spfli
  as select from spfli
    join scarr on scarr.carrid = spfli.carrid
{
  key spfli.carrid     as id,
  key scarr.carrname   as carrier,
  key spfli.connid     as flight,
        spfli.cityfrom as departure,
        spfli.cityto   as destination
}

.
.
.
.
@AccessControl.authorizationCheck: #NOT_ALLOWED
define view entity demo_cds_scarr_spfli_2
as select from spfli
      join scarr on scarr.carrid = spfli.carrid
    {
      key spfli.carrid      as id,
      key scarr.carrname    as carrier,
      key spfli.connid      as flight,
             spfli.cityfrom as departure,
             spfli.cityto   as destination
    }

Differences:

  • The view entity doesn’t require the annotation @AbapCatalog.sqlViewName.
  • The view entity doesn’t require the annotation @AbapCatalog.compiler.compareFilter: true, because the filter is implicitly and automatically compared.
  • The view entity doesn’t require the annotation @ClientHandling.algorithm, since client handling takes place implicitly.
  • The view entity doesn’t require the annotation @AbapCatalog.preserveKey: true, because there’s no ABAP Dictionary view attached to a CDS view entity.
  • The view entity is defined using the statement DEFINE VIEW ENTITY.

For a comprehensive description of CDS view entities, refer to ABAP Keyword Documentation (F1 Help in SAP GUI and ADT).

Outlook: transition from CDS DDIC-based views to CDS view entities

CDS view entities are the future of ABAP CDS. A migration tool that enables the migration from DDIC-based views to CDS view entities is under development. As soon as it is available, it is planned to migrate as many of the existing “classic” views to CDS view entities as possible (due to some incompatible changes, it is unlikely that all of the existing views will be migrated, though).

So, if you work with CDS views, familiarize yourself with CDS view entities. They’ll be around soon.

Further information:

 

12 Comments
You must be Logged on to comment or reply to a post.
    • Hi Tarun, no, subqueries are not supported in view entities and they are currently not planned.

      “Nested expressions” rather refers to, for example:

      • within an arithmetic expression, a cast expression, case expression, aggregate expression or built-in function can be used (DDIC-based views don’t offer the full range).

      Same for aggregate expressions, case, cast, built-in functions, and so on – they all allow other expressions as operands.

      Best,

      Andrea

    • Hi Anup,

      For CDS view entities, the analytical query name is the name of the view entity with the prefix 2C: 2C<name of CDS view entity in UpperCase>.

      As the BW name should not be longer than 30 characters, the CDS view entity name should be less than 28 characters.

      There is also the annotation @Analytics.technicalName (String(16)). If this annotation is used in a CDS view entity, then the analytical query will be „2C<technicalName>“.

      This annotation should be used especially when converting a CDS DDIC-based view to a CDS view entity and when you want the BW name to stay the same and not change during conversion.

       

      Best,

      Andrea

      • Thanks Andrea!

        Does this also imply that (since no SQL view gets generated), CDS view entity cannot be accessed natively in HANA database? There was a note 2511210 in the past mentioning that it “Should Not Be” . But now it appears that it “cannot be”.

        Anup

        • Hi Anup,

          CDS view entities do also generate a HANA view with the name of the CDS view entity. Hence, it is possible to access a view entity natively on HANA database. However, the same restrictions apply as described in note 2511210.

          Best,

          Andrea

  • Hallo andrea,

    due to some incompatible changes, it is unlikely that all of the existing views will be migrated

    In our SAP CPI-DS project, we are using CDSs to create complex logic. In this way, we release CPI-DS system of making complex calculations that could take more than 15 minutes in CPI-DS (vs seconds in CDS).

    However, CPI-DS can only consume the view (database layer).

    Should we get worried about it? I am afraid “Unlikely” could mean a lot of things. Removing these views or making mandatory not using them could ruin other parallel projects that cannot call to a CDS directly .

    Do you have information about it or who could clarify this point?

    Thanks in advance,
    David

    • Hi David,

      how do you consume the CDS views? Do you use ABAP SQL? If yes, then you can use the CDS view entity directly, and not the SQL view.

      Does that help?

      Best,

      Andrea

      • Hi Andrea,

        I am afraid SAP CPI-DS is not the best ETL tool in the market (but it’s SAP recommendation when working with IBP).

        It is only able to “see” tables or views at database level when connecting to a backend system. That means CDSs does not appear as a source object. However, we link the CDS view in CPI-DS and this is how we are working: generating complex SELECTs in CDS and linking them to CPI-DS through its view.

        Our concern is:

        • If these new CDS view entity is going to replace completely classic CDS or they are going to coexist
        • No option to continue creation of classic CDSs once new CDS view entity is available 

        Please, we are not asking for a work around. We need just confirmation of the roadmap to know if we need to change our way of work.

        Thanks in advance,
        David

        • Hi David,

          The classic, DDIC-based CDS views will still be supported. It is not planned to deprecate them. Both types of views will coexist.

          You as owner of the view can decide whether you want to migrate your existing views to view entities or not. There won’t be any automatic conversion.

          You can continue creating classic CDS view, even when CDS view entities are available. SAP only recommends to switch to view entities, because once they are feature complete, they are easier to work with and offer more options.

          Best,

          Andrea