DDIC of the Future (Tomorrow)

Table of contents

• Introduction
• Overview
• Elements
• Simple Type
• Table Entity
• Abstract Entity
• Usage
• Selection
• Constant
• Full example
• Conclusion

In this article, we take a look at the future and examine artifacts that we will use for modeling data and tables.

 

Introduction

Looking ahead, we will primarily live in a world called "CDS-only." This means that we will only use CDS artifacts and thus gain all the advantages, such as case sensitivity, longer names, and an integrated data model that we can use. The various CDS objects and new artifacts will replace existing artifacts and offer alternatives. The alternative is primarily designed for modernization and the new applications we can use. These applications require different properties than those needed for the SAP GUI.

At the same time, there is now a great opportunity to correct old errors in data modeling and introduce new features. What was not possible in the past and what the objects didn't provide can become possible in the future through new objects.

 

Overview

Let's take a first look at the changed landscape of objects that play a role here. Basically, it can be said that all object types have been replaced by new types. In the area of data elements and domains, there are now Simple Types. Simple Types replace two elements. They can also be stacked, meaning you can inherit properties from individual elements and pass them on. At the same time, the Simple Type represents the lowest and highest levels. Instead of tables, we use so-called Table Entities, which provide the structure while also ensuring data modeling and persistence for the database.

At the highest level, we use Core Data Services to represent views. These are also possible in the traditional world with tables, but for the sake of simplicity, we have incorporated them into this model. Below this is a new object called the Aspect, an object we have already looked at in the past to create reusability and includes. There is currently no element that precisely represents a structure; instead, abstract entities can be used. These are primarily used in the area of pop-ups and structure definitions. Only the table type currently lacks a successor. The question also arises whether one is absolutely necessary, especially considering the use of function modules, which will become increasingly rare in the future and will be replaced by OData services and HTTP interfaces.

 

Elements

Let's take a detailed look at the various objects in the model and how they are structured. We already looked at the Aspect in conjunction with Table Entities in another article.

 

Simple Type

The Simple Type is the actual data type that can be used as an element to represent a column. We can define various texts within it, the object's name, and also the data type. In this case, we are using a built-in data type. However, we can also use various other Simple Types or even data elements that we specify for the definition. This keeps the definition relatively small and concise. An important aspect here is that we can use uppercase and lowercase letters, which will also be used later when modeling the table entity.

 

Do you also want to define values, so-called constant values? Then the enum option is also available to you. Here, after the actual type, we define various values that are available for the object, assign values to the constants, and can also define the text that might be relevant for the UI later. We can then map further properties via annotations.

 

Table Entity

The Table Entity is the new form of the table. As in every CDS artifact, we have a much longer name that we can assign to the table, and we can also use uppercase and lowercase letters. At first glance, you will notice that the client field is missing. This is mapped via an annotation in the upper section, as are the various properties of the table. At the table level, we can define fields that in turn are based on Simple Types, and we can accordingly pre-model the final field names as we will later use them in the model. We can also use annotations for end-user labels or base types when modeling the table. Another advantage is that we can establish direct connections via associations in the table entity. This allows us to map the function directly at the table level and represent the relationships.

 

At the table level, we can also directly create an access control to protect our table and the data within it. This means that, out of the box, an authorization query is performed with every access, which then validates whether the user actually has the authorization to view the data.

 

In addition to associations, we can also map compositions and to-parent relationships. We can also define a root table entity. This means we can directly model a RAP object on top of these artifacts and save ourselves the intermediate layer via Core Data Services, as well as a mapping in the behavior definition.

 

Abstract Entity

Another type is the abstract entity. This behaves similarly to a structure; that is, we have no data stored behind it, and we cannot perform a SELECT statement. With this, we define a type in the system that provides fields. Here, we can use data elements, but we can also use simple types or built-in data types when we create the structure. "Using an annotation, we have the option to add further semantics or texts that we want to make available for the UI later."

 

Usage

For usage, we look at the same two examples as we already do for today's data model and look at the differences.

 

Selection

The SELECT against the Table Entity looks exactly the same as the SELECT against a table. Nothing changes for us here when we want to read data. The advantage of the Table Entity is that an authorization check is performed automatically. This means that all the boilerplate code we needed when accessing a classic table is eliminated. This saves the developer a lot of implementation effort, and security can no longer be overlooked.

SELECT FROM ZBS_CDSTable
  FIELDS *
  INTO TABLE @DATA(found_ddics).

 

Constant

Accessing constants will also become much easier. In an example, we define a local structure over the abstract entity we defined earlier. In the IF statement, we can then directly use the Simple Enum and have the ability to access the individual value of the Simple Enum. This eliminates the need to define a local class structure. We always get the current values defined in the enum and don't have to maintain anything twice or redundantly.

DATA local_structure TYPE ZBS_S_CDSInformation.

IF local_structure-ActionItem = ZBS_SE_CDSActionItem-enhancement.
  " TODO
ENDIF.

 

Full example

You can find all created elements and relationships in a new GitHub repository. In the subpackage ZBS_DEMO_DDIC_NEW you will find all classic DDIC elements. In the top-level package, we have defined overarching elements that we use.

 

Conclusion

The model of tomorrow consists only of "CDS-only" artifacts and brings all the advantages that Core Data Services also have. We finally get longer names for the various objects and can thus natively model data, which we then pass to the frontend. This saves us various layers that we previously had to define, such as the mapping of fields, and thus also streamlines the modeling in our applications.