022: Core Data Service [Basics] - Semantics and Associations

Table of contents

• Introduction
• Data Model
• Base Layer
• Association
• Interface Layer
• Dependent Views
• Data Preview
• Summary

Introduction

Welcome to the next session on the topic of Core Data Services Basics. Last time, we created the first view and explained the basics around creation. Today, we'll delve deeper into the data model, create additional entities, and link them with associations to define the data model.

 

Data Model

We've already created new tables in advance and filled them with data. In addition to the header, there is now also a partner with their address data. For a document, we now have additional items that are separated by a sequential number. The positions contain specific products, for which we have a separate table where the unit and currency of the product are defined. The product also has a description that should be translatable. For all new tables, you will find the corresponding data in the executable class to populate the tables with content.

 

Base Layer

Last time, we set the ViewType to "BASIC." Since our base view isn't intended for use, we'll add the "Private" annotation. This has no impact on the actual use, but we do indicate to other developers that this view should not be used. In the next step, we create the corresponding base views for the product and product texts; there are no special features here so far. We simply clean up the corresponding annotations in the header and adopt the field suggestions for our data model.

 

Association

We have a small special feature with the position. Normally, we use the base view to normalize the field names for our data model and do not yet establish connections to the various data. However, it can also happen that we do not have all the information for the data model available at this level. In this case, the unit and currency come from the products and are stored in this view. Therefore, we create an association, which is nothing more than an optional join over the data. The association receives an alias with an underscore. The underscore is not required, but it is best practice. We then execute a corresponding JOIN condition. Using the $projection variable, we can access the fields of the current view to establish the connection.

We can then add the fields to the field list. Here, we don't necessarily have to use an alias; the field name remains the same as it comes from the association. Using the "Semantics" annotation, we can then assign the fields to the values, thus eliminating error messages from the view.

Generally, we specify the relationship between the data directly after the ASSOCIATION keyword. In this case, the 1-to-n relationship is incorrect, which we can also see in the compiler warning. However, you should generally no longer use this notation in modern systems. Therefore, we will switch to the descriptive notation.

Finally, we transfer the VDM annotations to the three views and activate them. This completes the CDS foundation and allows us to create our interface for reusability in the next step.

 

Interface Layer

The corresponding views are marked with an "I", for interface. Here, we want to make our data model reusable and make all necessary relationships available in the data model. Within the virtual data model, we no longer have to remember the various tables and dependencies, as they are defined in the model. The standard also provides many basic views that we can reuse in ABAP Cloud. To do this, let's first define the language using an association. We'll use "Exact One" because we expect exactly one entry. We'll also use the association in the field list so that the associations can be optionally accessed when using the view. Without directly using the field, the join isn't established, and thus no performance is lost.

We'll also use three new associations. Using "foreignKey" We specify the foreign key relationship to another entity. With "Semantics.Language" we define the language field, and with "Text" we indicate that this field is a descriptive text.

Now we create the view for the actual product. After we have cleaned up the annotations, we can also establish the various relationships to the data here. In this view, we have assigned the various texts, which this time are in a "one-to-many" relationship, i.e., 1 to n in the classic sense. There are also further associations to the units and currencies from the standard. For all three associations, we again define corresponding foreign key relationships and specify the annotation in the field list.

In the final step, we create the interface for the partner for the master data. Here, there is only a single association to the standard for the countries.

 

Dependent Views

The next step is to define the views for the header and position. Since the two views are dependent on each other, we need to create and activate both. To do this, we first start with the header and define the relationship to the partner. Before we define the association to the position, we create the view for the positions and activate it without defining relationships to other data. This allows us to finalize the association in the header and finally activate the view.

At the position level, we now define the connection to the product and also to the header, the actual document. Once we're done, we can activate all objects in the system. Finally, we create a connection to the user in the header, since we have the corresponding information about the clerk in our views.

 

Data Preview

This completes the data model, and we can view the data in the Data Preview and test the various connections. In the Project Explorer, you'll find an option to directly start the Data Preview under "Open With" in the context menu. By right-clicking on a data record, we can select the "Follow Association" option to navigate via the connection. All defined associations are displayed here, which we can then navigate through. Here we select the positions, and all the positions for the document are now displayed. In the header, you can see the current access path; we started in the header and are now at the positions. From here, we can navigate further and reach our product, which was stored in the selected data record. Using the texts, we can now also view the various translations of the product.

A correspondingly long navigation structure has now been created in the upper part. By clicking on any node, we jump back to the corresponding data. With a clean data model, we can navigate the linked data and no longer have to remember all the tables and relationships.

 

Summary

In this video, we finalized the data and created the reusable interface layer in addition to the base layer. By defining associations, we can connect the data in the data model without encountering performance issues, since the link is only used when we call and use fields from the association. Using additional annotations, we enriched the data model with information about foreign keys, texts, and languages.

Thank you for watching and see you next time.

 

YouTube
Video