033: Core Data Service [Basics] - Consumption Modeling
In this episode, we look at the modeling of a Consumption View and examine various aspects such as functions, associations, session variables, and virtual fields.
Table of contents
Introduction
In this episode, we'll discuss modeling Core Data Services on the Consumption Layer. We'll use the data model we created last time and generate a new view, which we'll then use to look at some examples.
Consumption View
To do this, we'll create a new view for the positions on the View interface. In this case, we want to create a Consumption View that our application will use later. With Consumption Views, we assume that we create them specifically for use cases and applications. Therefore, they are precisely tailored to a single use case and are usually not intended for reuse or further modeling. At the level of a Consumption View, computationally intensive and performance-intensive operations would also be found.
We should remember that we want to create a View Entity, as this is the standard in current releases. Once we have created the View, we clean up some annotations that we don't currently need, making the View more readable for the next steps. To inform other developers what the View is actually intended for, we add the ViewType of the virtual data model to the header of the CDS Views. Now we can further clean up the view and, in this case, remove the associations and the quantity plus unit, as we won't need them later.
Associations
We received the requirement to also output the partner ID in the data. For this, we no longer need a join, but instead use the association that we have already created in the data model. We can easily identify the connections using the underscore. The partner comes from the "Header", so we can include the field accordingly. If we don't specify an alias, the field receives its original name; the association is not part of the name. Now, if we call up the Data Preview, the PartnerID is now part of the data.
Functions
If you are working with Core Data Services, various functions are available to you, similar to ABAP. Our next requirement is to specify the full name of the partner. Using associations, we can navigate to the partner via the header and find the name there. However, the information is currently split across two fields, which we now want to combine into one. This is where the CONCAT functions come in. The first function joins two fields, but we have no way to cleanly separate the names. With the second function, we can link the fields and insert a certain number of spaces between them. To do this, we first specify the two fields we want to link, then the number of spaces, and finally, we must give the new field an alias. Without the alias, the system throws an error. Looking at the result again, the full name is now also displayed after the partner.
Session
The next requirement is that we should also output the product name along with the product ID. As before, we can navigate through the various modeled associations to include the product text in our view. Once we've done this, we receive a warning message that this relationship could change the cardinality. Let's activate the view and look at the preview. In contrast to previous tests, the result set has increased and no longer fits on one page. Looking at the data in detail, we now have the different languages as product text, and the actual key no longer matches the view. The document number and position are currently no longer unique and are assigned multiple times. The Core Data Service can handle this, but it's no longer entirely correct when accessing the data.
In this case, we actually only want to display the current login language to the user. To do this, we delimit the current text association, similar to a table with square brackets. We want to restrict this to the language. The `$session` variable is available to us for this purpose in the model. In the session, you'll find important user login information, such as the user ID, client, current date, and login language. We'll use this for access. The warning message will still appear, but when we run the view preview, the correct data will load again, and the product text will be in English.
Let's test the view on the same system with a different login language. To do this, we navigate to the system and start the data preview directly using ALT + F8, specifying our Core Data Service. After execution, we receive the data preview in German and the appropriate translations for the product. The data is still correct so far.
Alias
As a further requirement, we are to adjust the names of some fields, as the caller expects different fields. Here too, we have no problem and can simply use a new alias. Since we are not modeling further based on the view, we will not have any problems in the data model later either. You should always be careful when renaming fields within your model, especially if the fields are then also used in authorization checks.
New Fields
As a final adjustment, we are to make new fields available in the model. The fields do not currently exist in the data model or on the database. We need to derive the rank of a position from the quantity. In this case, we use the CASE function and compare the quantity against our KPIs. If the quantity is greater than or equal to 5, then it's a "High" performer. Two indicates a "Medium" performer, and anything below 2 indicates a "Low" performer. We'll assign an alias to the new field to clarify its use.
Finally, the caller wants the current date to also save the snapshot after subtracting the data. For this, we can again access the session and give the field an alias for the execution date. This way, we can provide fields and information that are not directly present in the database but can be derived from the context or other fields.
Summary
Finally, we run the Data Preview and look at the finished data. We have provided our first Consumption View and fulfilled all requirements. In doing so, we accessed the information in the data model, used session information, and created new content - all without writing a single line of ABAP.
That brings us to the end of the episode. Thanks for watching, and see you next time.
YouTube
Video