CDS - View structure
In this article, we want to give you an understanding of the structure and functionality of a CDS view. What does a view look like and how does it work.
Table of contents
Article update: Since release 7.57 (S/4 HANA 2022), DEFINE VIEW is marked as obsolete, you should use DEFINE VIEW ENTITY instead. These may differ from the examples in some places. You can find more information about the new views in this article.
We laid the basics in the first three articles of the series, today it's about how to create your first view with Eclipse. Furthermore, we want to show you what works in such a view and how you control and use the corresponding elements.
Data model
We are still working on the current data model for our demos, but we will present it to you in an article soon and how we went about it. For today's examples, however, we'll use the first table from the model. The table looks like this:
It contains data for our business partners with whom we trade. We have already inserted the first data records into the table in order to have master data available:
Eclipse
Core Data Services can only be created with Eclipse and the ABAP Development Tools (ADT). Only a display of the view is possible in SAP, but no creation or change, but this depends on the release of the system.
The easiest way to create a CDS view for a table is to use the table's context menu in the Project Explorer. Based on the context, the tool derives which actions we can carry out with the object or in this area.
After selecting the "New Data Definition" action, you now have the option of filling in further information about the object. The system has already pre-filled the reference object based on the context. You can enter the name of the CDS View in CamelCase. As you have already learned in the virtual data model, we first want to define a classic interface or basic view.
After selecting the transport request, different templates can now be selected, depending on what kind of view you want to define. In this case, a simple view of the table is sufficient.
Interface View
The result of the generation is an almost complete core data service that now has the following format. Although we are not quite finished with the work, but it is a overview of a first template.
@AbapCatalog.sqlViewName: ''
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Interface for Partner'
define view ZBS_I_DmoPartner as select from ZBS_DMO_PARTNER {
key partner,
name,
street,
city,
country,
payment_currency
}
In order to activate the view, we still have to store some information. The "@AbapCatalog.sqlViewName" annotation still has to be filled, here the system requires a name for the DDIC view, which is generated in the system at the end. In contrast to the CDS name, this name only has 16 characters, like all views and database tables. We also create aliases for the fields and remove the underscores from the names. As a result, the view looks like this.
@AbapCatalog.sqlViewName: 'ZBSIDMOPARTNER'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Interface for Partner'
define view ZBS_I_DmoPartner
as select from zbs_dmo_partner
{
key partner as PartnerNumber,
name as PartnerName,
street as Street,
city as City,
country as Country,
payment_currency as PaymentCurrency
}
The first 5 lines are controlling annotations that define the basic settings of the view. With "define view" we define the name of the new CDS view and the SELECT shows the origin of the data. In this case we make a SELECT from the table ZBS_DMO_PARTNER. The field list is defined between the curly brackets. A Core Data Service should also have a key, but it doesn't matter here whether it is the key of the database. With the key we define the unique records that the view returns. In the field list we have the possibility to store corresponding aliases.
Hint: Since it is the interface or basic view, we also have the option of converting the fields into English long names and thus making our data model even more meaningful.
Consumption View
In the second step we can define a consumption view for our interface view. To do this, you can create a new data definition again via the context menu on the view. As a template you can use the same as for the interface view. All partners from Europe are required for the view. The view could now look like this:
@AbapCatalog.sqlViewName: 'ZBSCDMOPAREUROPE'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Partner in Europe'
define view ZBS_C_DmoPartnerEurope
as select from ZBS_I_DmoPartner
{
key PartnerName,
City,
Country
}
where
Country = 'DE'
or Country = 'CH'
In contrast to the interface view, this view has a different core data service as the data source. We only use a limited set of fields and also define a completely different key. After the curly brackets we work with a WHERE condition to restrict the data. However, we can also achieve the same result with a simple SELECT on the interface view:
SELECT FROM zbs_i_dmopartner
FIELDS partnername, city, country
WHERE country = 'DE' OR country = 'CH'
INTO TABLE @DATA(lt_view_data).
The difference, however, is that we can also reuse our consumption view in different places and only have to change this view in the event of an adjustment.
Conclusion
The creation of a first CDS view is not particularly difficult and Eclipse with the ADTs supports you. The views are designed for reusability, so that restrictions on the amount of data can also be transferred to the view and they only have to be maintained in one place.