Hierarchies in Core Data Services for ABAP Part 1: Annotation-based hierarchies

Introduction

Business data is often hierarchically structured e.g. hierarchies of organizational units, a reporting hierarchy, hierarchies of financial accounts in the balance sheet, product hierarchies, product types and others.

These hierarchical structures make it easier to get an overview, especially when analyzing and processing of larger amounts of data, by aggregating key figures to hierarchy nodes and display selected parts of the hierarchy in more details as needed.

In a SAP BW environment we model hierarchies on the InfoObject, the CDS-infrastructure of an SAP S/4HANA system offers two techniques for modeling and processing hierarchies:

• Annotation-based Hierarchies and
• CDS Hierarchies.

Annotation-based hierarchies are based on CDS and require the analytic engine and is therefore used almost exclusively in analytical applications.

CDS hierarchies are based on a new type of CDS entities used for defining hierarchies only. They are based on native SAP HANA hierarchies and are processed by SAP HANA directly; they are integrated in Open SQL and can therefore be used more flexibly.

In this blog we want to take a closer look at annotation-based hierarchies, in a later follow-up post we will focus on CDS hierarchies. 

Architecture

The following picture gives an overview on how a annotation-based hierarchy is 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 options given here might be overwhelming at first, but to enable a basic hierarchy in reporting you only need the Hierarchy Node view, all other views are optional.

Next, we will go through each of these views in detail and highlight the most important annotations to get the hierarchy up and running, using a concrete example.

Example

Base Entity

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 connects the Master data with the nodes of a hierarchy via an association.

Please note the following 4 important annotations to make the hierarchy work:

• @Analytics: { dataCategory: #DIMENSION} – Set the right data category.
• @ObjectModel.representativeKey: ‚Region‘ – Defines for what field the master data is.
• association [0..*] to ZP_REGION_HIERARCHY_NODE as _region_hier on $projection.Region = _region_hier.HierarchyNode – Makes sure that all the child nodes are available in the master data.
• @ObjectModel.Hierarchy.association: ‚_region_hier‘ – defines on which field the hierarchy is build.

Hierarchy Node

The Hierarchy Node view contains the actual hierarchy by providing a child and parent field. It also connects the Dimension and the Hierarchy directory view via associations.

It is worth to mention that a CDS hierarchy can be time dependent, the fields ValidityStartDate and ValidityEndDate can be used for modeling it.

The following annotations are needed to make this view work:

• @ObjectModel.dataCategory: #HIERARCHY – Defines the dataCategory type.
• @Hierarchy.parentChild.name: ‚REGION_GEO‘ – Defines the technical name of the Hierarchy
• @Hierarchy.parentChild.label: ‚Region Geography‘ – Defines the name of the Hierarchy
• @Hierarchy.parentChild: { recurse: { parent: ‚ParentNode‘, child: ‚HierarchyNode‘ },
•                           directory: ‚_Hierarchy‘ } – Defines the actual fields for Parent and Child and also links the hierarchy directory.
• association [0..1] to ZP_REGION_DIMENSION as _Region    on  $projection.HierarchyNode = _Region.Region – Makes sure that every child node exists in the master data.
• @ObjectModel.foreignKey.association: ‚_Region‘ – defines what values are valid

Additionally, there are the following annotations possible to further define the hierarchy:

• @Hierarchy.perentChild.siblingsOrder.by – to define the field to order siblings.
• @Hierarchy.parentChild.siblingsOrder.direction – to define the sort direction, you can set it to “ASC” or “DESC”.

Because we also linked the hierarchy node to the hierarchy directory via an association, we also need a hierarchy view, which will be described in the next chapter.

Hierarchy Directory

The hierarchy directory is an optional view, that only is needed if you have multiple hierarchies per field. F4-Help

It’s also a good start for anyone who wants to see what hierarchies are available on the system for a specific field.

The view itself is pretty basic and it does not have any connections to any other view. The most important annotations need here are the following ones:

• @Analytics: { dataCategory: #DIMENSION } – Defines the data Category
• @ObjectModel.representativeKey: ‚RegionHierarchy‘ – Defines the key of the view.
• @Semantics.businessDate.from: true – Defines the field of the “from Date”.
• @Semantics.businessDate.to: true – Defines the field of the “to Date”.

Tipps for enabling hierarchies S/4 HANA system

1. To automatically generate the most important hierarchies in an S/4 HANA system, we use transaction: HRRP_REP.
2. To check if hierarchies work, execute Transaction RSRTS_ODP_DIS and execute the Dimension View, then enable hierarchies by right click on the column and pick properties.
3. When using the hierarchies, by default the inner leaves are active. We can disable them by using the annotation @AnalyticsDetails.query.hierarchySettings.hidePostedNodesValues in the CDS Query, or by disabling the values of booked nodes in Analysis for Office. You will notice it when viewing a query in Analysis for office when it’s not set.

Testing an annotation-based hierarchy

The easiest way to test the hierarchy definition is to use the test environment for analytical views, transaction RSRTS_ODP_DIS in the SAP GUI.

1. Enter SAP GUI and transaction RSRTS_ODP_DIS

2. Select the dimension view in the field ODP Name

3. The analytical model of the view is displayed. A tree-like green icon indicates that there is a hierarchy definition for this field

4. Start an analytical test of the view using the function Standard query

5. Group the rows by Node

6. Then open the Properties tab for the Node via the context menu

7. When you switch to the Hierarchy tab,

8. you can select an entry from the hierarchy directory. This tab is only displayed if a hierarchy directory exists at all and entries are present in the hierarchy directory.

9. If you accept the selected entry…

10. …the region nodes are displayed hierarchically.

Conclusion

You should now have a basic understanding of how annotation-based hierarchies can be defined and used in analytical applications in a S/4 HANA scenario. In a follow-up post, we will take a closer look at CDS hierarchies, highlight the advantages and disadvantages of each type of implementation as well as when to use which type of hierarchies.