CDS - View Entity
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.
Table of contents
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.
