This is a test message to test the length of the message box.
Login
ABAP CDS View Entity
Created by Software-Heroes

CDS - View Entity

2699

In this article you will learn more about the new Core Data Service entities, what they bring and what makes them different from the old views.

With ABAP 7.55 or S/4 HANA 2020, SAP has implemented new types of CDS views. Above all, the new types bring many advantages, but they are based on a current release. In this article we will explain what the views are all about, how you use them and what the differences between the two current types are.

 

Availability

As described above, view entities have existed since ABAP 7.55 and are mainly introduced in connection with RAP. Now they are feature complete with cloud version 2205 or the 2022 release for S/4. For us as developers, this means that all announced functions and possibilities have now been implemented and can be used in full.

 

Differences

We already used the new views with the first business object in the RAP blog, here only with the addition "root", since every business object has a root. What distinguishes the view from the view entity? Here, SAP had to make a hard cut between the two types so that the older views still worked afterwards and there were no problems in the system.

 

DEFINE VIEW

With the classic CDS view, the view is defined and, via the annotations, a DDIC artifact is created at the same time, which is created as a view in the DDIC. When the Core Data Service is activated, the DDIC View is also updated each time, which led to longer activation times. The typical structure is therefore as follows:

 

If parameters were also contained in such a view, the view was technically saved as a table function in the database. This can be viewed via the "SQL Create Statement" in the view. If you had a view stack that consisted of several views that were based on one another and you now wanted to rename a field, then you had to adapt each individual view, sometimes working with dummy fields, in order to update the entire hierarchy.

 

DEFINE VIEW ENTITY

The new entities no longer require a DDIC artifact and are generated directly as views. This makes activating the view and an entire view stack much faster and easier, since only one object needs to be generated and checked at a time. The architecture of the structure changes accordingly:

 

Advantages

What other advantages does using the new Core Data Services have for you? At this point, just a list of the various advantages:

  • Faster view activation times
  • Field-level changes across entire views stacks
  • Stricter syntax check via the compiler (use of data types, literals, check of existing annotations against DDLA)
  • More nesting of functions and operands in the view
  • Use of typed literals
  • Automatic client handling

 

Furthermore, there are various advantages in the architecture and modeling with CDS Views:

  • Generation of the key now unified, previously partially different in view and DDIC
  • Calculation of quantities and currencies are better checked for meaningfulness, so that meaningful units are created (e.g.: EUR/m²)
  • Creation of own units of measure for calculated fields
  • Better buffer handling of views

 

Comparison

For a small comparison we define two views that are the same but are based on the two variants accordingly. The old view is created accordingly and also contains a parameter to limit the data:

@AbapCatalog.sqlViewName: 'ZBSIDMOOLDVIEW'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Old view type'
define view ZBS_I_DmoOldView
  with parameters
    @Environment.systemField: #SYSTEM_DATE
    P_Date : abap.dats
  as select from zbs_dmo_invoice
  association [0..*] to ZBS_I_DmoPosition as _Position on $projection.DocumentNumber = _Position.DocumentNumber
{
  key document as DocumentNumber,
      doc_date as DocumentDate,
      doc_time as DocumentTime,
      partner  as PartnerNumber,
      _Position
}
where
  doc_date = $parameters.P_Date

 

The SQL create statement now looks like this, it is noticeable that it is not a defined view, but a database function. This is because the functionality on the HANA database was missing at the time, views with parameters had to be displayed differently.

 

Let's now define a corresponding view entity that has the same behavior as the view before it:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'New view type'
define view entity ZBS_I_DmoNewView
  with parameters
    @Environment.systemField: #SYSTEM_DATE
    P_Date : abap.dats
  as select from zbs_dmo_invoice
  association [0..*] to ZBS_I_DmoPosition as _Position on $projection.DocumentNumber = _Position.DocumentNumber
{
  key document as DocumentNumber,
      doc_date as DocumentDate,
      doc_time as DocumentTime,
      partner  as PartnerNumber,
      _Position
}
where
  doc_date = $parameters.P_Date

 

The new view is also generated with parameters as a view on the database and behaves like the defined view. There are no differences here whether the view has parameters or not:

 

The new view contains fewer annotations and also fewer objects since the DDIC view is no longer used. Generating on the database is also always the same and the HANA views are used.

 

Migration

However, the new and old view types are not compatible with each other, since SAP had to make a hard cut here, as already described above. However, SAP continues to provide various reports and tools in the system in order to be able to carry out manual migration and analysis on your own views.

With this you can also migrate existing views and hierarchies to the new world with a little effort. The DDIC views are then deleted from the database in the background. For more information, see the link below under "Migration".

 

Links

Of course, we don't want to withhold from you the additional information that you can find on the various blogs and on the official SAP blog:

 

Conclusion

If your system already has a high release, then you should only use the new view entities for modelling, this is also the statement from SAP. The "old" views should only be used as seldom as necessary and also offer more disadvantages than advantages compared to the new objects.


Included topics:
CDSCore Data ServiceView Entity
Comments (0)



And further ...

Are you satisfied with the content of the article? We post new content in the ABAP area every Friday and irregularly in all other areas. Take a look at our tools and apps, we provide them free of charge.


ABAP Tools - Work with Eclipse (CDS Analysis)

Category - ABAP

In the complex world of CDS views, it is important to have the right tool at hand to ensure an analysis of the structures and data sources.

08/25/2023

CDS - Learnings

Category - ABAP

In this article we summarize the learned content and show you the way for what you will need the CDS Views in the future.

06/10/2022

CDS - Virtual fields

Category - ABAP

This article is about virtual fields in Core Data Services and how you can subsequently deliver such complex data.

06/03/2022

CDS - Authority check

Category - ABAP

How and where are the permissions for a Core Data Service delimited? Check out this article for the details.

05/20/2022

CDS - Extension of Views

Category - ABAP

This article is about the extension of views to include customer-specific fields or to provide missing information.

05/13/2022