037: Core Data Service [Basics] - View and View Entity

Introduction

In the last episode, we took a closer look at the Dependency Analyzer. At the end, we noticed that there were entities and somewhat unreadable names in the display. We didn't go into the details then, which we'll now do in this episode. Today, we'll look at the classic views and compare them with the new CDS View Entities.

VIEW

Let's first create a new view on the position table. We'll assign a name and a description, just as we have done before. Finally, we'll see the template selection and can choose between different templates. We have the View Entity, the Root Entity, and the classic Define View at our disposal. Here you can already see the differences between the various entities in detail. So, we create the new entity and, in the first step, have chosen the wrong template. However, since we've chosen the wrong template, we don't necessarily have to delete the new view; we can simply make an adjustment. To do this, we copy the name of the new entity and the source of the selection. In the next step, we delete the entire content of the new view and can then use the Quick Fix to select one of the appropriate templates, which we then want to insert. Here we use the view and have the template inserted into the current editor.

Why can we do this? Because a view is initially a definition, and we can determine its content ourselves before activating it. Accordingly, we can accept the view's name, even if the default formatting sometimes causes problems. The table wasn't automatically included or is missing from the template, so we'll now insert the data source manually. In the next step, we can use Ctrl + Space to automatically insert all the table's fields. The system will also create the appropriate mapping for us. After formatting, however, we notice the first difference, as we still receive an error message: The SQL View Name is still empty in the upper part. This is absolutely necessary for classic views to create the corresponding object in the dictionary. So we assign a name here, but quickly realize that we are limited to 16 characters, in contrast to the up to 32 characters available to us for the actual CDS entity.

As a next step, we add a function and generate a calculated key in the entity. We use the "concat" function and combine the document ID and the product ID. We save the result under a new alias. In the next step, we take this new ID and want to convert it to lowercase so that it can be used as an additional formatted ID in the view. However, we will encounter an error here because the alias field cannot be found. In classic views, it is not possible to directly reuse an alias in the same selection list. Finally, we activate the entire view, which takes a little longer than usual. This is one of the disadvantages of a classic view: activation takes more time because the classic dictionary object (the SQL view) also needs to be generated in the background.

As a next step, we call up the Dependency Analyzer again and display the dependency graph. Here we see the entity and the corresponding table that we defined. Additionally, we can now switch back and forth between the different names. On the one hand, we see the name of the entity, and on the other hand, when we switch, the name of the SQL view we defined earlier. Finally, let's call up the Data Preview again and display the results. The view works perfectly: We see the data and could now perform a detailed analysis.

Migration

With that, we have created and activated the view. During editing, we already noticed some initial differences: We had to assign an SQL view name, which created an additional artifact in the system besides our actual definition. If we search for this SQL view, we will also find it as a classic object in the ABAP Dictionary. Besides the creation, we also noticed that we cannot use certain functions, such as accessing locally defined fields, which are simply not recognized within the same statement. It must be clearly stated here: This is an outdated type of view that should no longer be created in a modern system. An exception exists only if the technical SQL view name is absolutely necessary, for example, for specific customizing or older frameworks. Therefore, in the next step, we will look at how you can migrate from classic views to the modern CDS View Entities.

SAP offers various tools for the migration. In this case, we use the integrated tool in the ABAP Development Tools, which you can find by right-clicking and selecting "Migrate to CDS View Entity". There, we start the corresponding wizard via "Migrate to CDS View Entity" and can begin the check directly in simulation mode. First, it checks whether all prerequisites are met and whether the functions used in the current definition are ready for conversion into a View Entity.

The simulation is then executed, and we receive a corresponding log after the run. Here, we can check which errors are still present in the view. For example, the assignment to the currency and the unit of measure is still missing. In this case, we go to the old Items view and adopt the association as well as the corresponding fields and annotations from the existing view. However, after recording, we'll notice that the association isn't working as intended: We're using a newer statement that isn't yet supported in classic views. Therefore, we need to make an adjustment and use the old association statement. Once that's done, we reactivate the view and restart the migration tool in simulation mode. In this case, we'll again receive a top-level error message, but if we examine the details, we'll see that all the individual checks are fine. In the final preview, you can now see exactly what's being changed in the view: Essentially, various annotations are being removed, and the actual SQL view is being deleted from the system.

Therefore, we can now start the migration in live mode. After the migration is complete, we'll take a look at the log. We'll see an error entry, usually indicating the removed SQL view, but otherwise, the view has been successfully migrated. The new entity is currently inactive, so we need to activate it first. Once that's done, we can make some modern adjustments to the view. For example, we can now use the association in its new, improved form. A real highlight: We can uncomment the previously commented-out code. As you can see, we can now directly access the locally defined field in the statement and process it further. This wasn't technically possible in the old view. Finally, let's take a look at the data preview: All the information is there, and the calculated fields are also generated cleanly and populated correctly.

Summary

Finally, let's take another look at the relevant article on Software-Heroes.com. You can find this in the Core Data Services collection under the entry for the View Entity. Here's a summary of what a classic view actually consists of: It comprises the CDS entity and an additional DDIC artifact, the so-called SQL view. After the migration, we removed this SQL view and now only have access to the pure View Entity. A key advantage of this is that activation times are significantly reduced. Furthermore, functionalities become possible that were simply not supported in this form before.

At the end of the article, you will find an overview of the advantages of using the new artifacts. Firstly, you benefit from faster activation times, as the generation of the SQL view is no longer necessary. Secondly, changes are easier to manage directly via the entity's source code. However, there is also stricter syntax checking, for example, currency and quantity fields must be correctly assigned. Another advantage: We can now easily nest functions, use typed literals, and enjoy fully automated client handling. In summary, the new View Entities offer a significantly larger portfolio of functionalities and more efficient development. Therefore, our advice: Don't wait to migrate, but use the new CDS View Entities today, provided they are available in your system.

In this episode, we've looked at what views and view entities actually are, where exactly the differences lie, how they are used, and what you should consider for the future. That brings us to the end of this episode. Thank you very much for watching and see you next time.

YouTube
Video