Hierarchies in Core Data Services for ABAP Part 2: CDS hierarchies
In our last blog post on hierarchies in ABAP CDS views, we covered annotation-based hierarchies.
In this blog we will cover another way on how to implement hierarchies in ABAP CDS views, by using the hierarchy keyword. This feature was introduced with SAP S/4HANA 1809 and it enables third-party apps and ABAP to utilize the hierarchy processor of the SAP Hana Database.
The following picture gives an overview on how CDS hierarchies are defined:
Every rectangle represents a CDS view with special annotations to connect the views to each other and define the hierarchies for analytical purpose.
The most important views here are the hierarchies on the top, that are the views where the actual hierarchy is defined, before that we only have standard CDS views.
Next, we will go through each of these views in detail and highlight the most important keywords to get the hierarchy up and running, using a concrete example.
The Base Entity can be seen as the view that holds the master data. It can include a select on a database table or contain the relevant data in the view itself.
The Base Entity only holds the master data, it does not have any associations to another view.
As the name suggests in here, we only define the relationships between employees. We do not yet tell SAP Hana that it should create a hierarchy, but only state the relationships between the employees.
Please also note that the employee 0012 does not have a manger. By default, this orphan node would be ignored, but there are also ways to display it as root node.
The Hierarchy Node connects the relationship view and the base view via associations. The special part about this view is the self-reference, that indicates the hierarchy.
Compared to the annotation-based hierarchies this view is relatively straightforward. There are just the standard CDS annotations needed. The Relationship is read from the view ZHP_EmployeeRelation.
There are two associations used here, one to do a self-reference on this view and the other one to connect the nodes to the master data via the _Employee association.
This view creates the actual hierarchy in the system. Please note that here we use the keyword hierarchy instead of view. As stated before by using this technique we can only create parent child hierarchies, but no level based hierarchies.
The view itself is basic and it does not have any connections to any other view. The most important keywords need here are the following ones:
-Define hierarchy – Defines the actual hierarchy
-source – Defines the source view
-child to parent association – tells the system the self-reference association
-start where – is a normal where condition to select the root node
-siblings order by – to order the siblings in ascending or descending order
-multiple parents allowed – enables multiple parents for one node
-cycles breakup – when we have loops in the hierarchy we need this option to stop it
Testing a CDS hierarchy
The easiest way to check the results is to create a small ABAP report via SE38.
As you can see here it smoothly integrates into the open SQL syntax. We are also reading the Hierarchy Attributes in line 13 to 18 and the employees name, which is enabled via the association to the base view.
The report generates the following output.
After reading both articles you should now have a basic understanding of the different techniques on how to define hierarchies in CDS Views and how to test them.
Below you can find a table that guides you when you are thinking about integrating hierarchies into your CDS views.
|Annotation Based Hierarchies||CDS – Hierarchies|
|Are not useable in ABAP, because they require an Analytic Processor (=Analytic Engine)||Can be accessed also via ABAP, because they run directly on HANA|
|Are available since the start of CDS Views||Were introduced with S/4Hana 1809|
|Are used in standard SAP Content||Provides Hierarchy Attributes|
|Can be used by external apps|
|Easier to define than annotation based hierarchies|