017: Core Data Service [Basics] - Creation and Structure

Table of contents

• Setup
• Creation
• Structure
• Alias
• Annotation
• Data Preview
• Summary

Setup

Core Data Services are the foundation of modern development and therefore an important skill for every ABAP developer. We are launching a series of short videos to complement current topics. You will find a new folder for Core Data Services in the YouTube directory. Currently, a table has been created there, as well as an executable class that provides data. In the class, you will find a method for each table that generates data. The table is a header table that contains some information about a document, such as the ID, a description, the partner, a creation date, and a clerk. If we look at the contents of the table using F8, we can already see the inserted test data.

 

Creation

There are usually several options for creating Core Data Services; let's look at two options. For example, if we don't yet have a Core Data Service under the package, we can access the context menu and create a new object using the "New" sub-item. Since all objects are now available here, we need to search for "Data Definition".

The second option is to create a new object using a suitable object. For example, if we want to create a Core Data Service for the table, we can also navigate to the table in the repository tree. We'll find the entry directly in the context menu. Working with a reference has an advantage, as the reference object for the new Core Data Service is pre-populated.

Now we can give the service a name. The new feature with CDS Views is that we can use upper and lower case letters. This is also best practice when assigning names. In this case, the B in the name stands for the type of Core Data Service. Here we want to create a Basic View that is located directly above the table. After selecting the transport, we select the template—that is, the type of Core Data Service we want to create. In this case, various templates are available. "VIEW" is still used primarily in older releases but is obsolete in newer versions. Therefore, you should primarily rely on the "VIEW ENTITY" here and forget about the old version as soon as you are on a reasonably up-to-date system.

 

Structure

After creation, we receive an initial suggestion from the system and can use it to look at the structure of a Core Data Service. Here, we can identify three components of the view at first glance:

• Header Annotations - Annotations begin with the @ symbol and are primarily intended to enrich the data model and for description. Since we are above the view definition, this is the header area.
• View Definition - In this area, you will find the view definition. For example, the table selection is displayed here, but relationships within the data model for associations and compositions can also be displayed.
• Field list - Within the curly brackets we are in the field list. Here we can work with the various fields, execute functions, or create new fields. Annotations can also be used in this area, which then apply not only to the view, but to the individual fields within the view.

 

To do this, let's first clean up the view and remove annotations that we don't need for clarity. With Shift + F1, we can run the Pretty Printer and format the fields and annotations to achieve a consistent appearance.

 

Alias

The system already suggests new field names for the Core Data Service. A good recommendation here is to work without underscores in the data model and to use upper and lower case. Here in the base view, we want to provide the table data in the model and assign descriptive long names that are as unique as possible within the model. These names then form the basis for the entire virtual data model.

We can also assign an alias at the table and relationship level. This allows us to access the table fields within the view. At the table level, this is actually only necessary if we have more than one base table available via a join.

 

Annotation

At the header level, we add another annotation for the virtual data model. To do this, we start with the first part of the annotation and can then select the appropriate type from the value help. Using CTRL + SPACE, we call Content Assist and receive all the constants that we can insert at this point. Since we're still at the basic level, we'll use the constant for "BASIC."

Using the forward navigation, we access the annotation definition and can review the available annotations. Here you'll also find additional properties such as release status, scope, data type, default values, and available constants.

If you want to get an overview of all available annotations in the system, you can do so using the general search. To do this, we search for all objects and limit the search to the DDLA type. In this example, we get 49 results and can navigate to, for example, UI. Here we find all annotations related to Fiori Elements.

 

Data Preview

To view the data after modeling, we can start the Data Preview in the Core Data Service using F8. By default, we initially receive all available data. The headings already correspond to the new field names, making the column content easier to identify. If we want to narrow down the set, we can right-click on an element and fill in the Quick Filter. This filters and shows the data for the corresponding partner. We can further adjust the filter afterwards.

 

Summary

This completes our first Core Data Service creation and explains the basic components... Thanks for listening and see you next time.

 

YouTube
Video