SAP Datasphere has rolled out a much-anticipated feature set with the Hierarchy with Directory. This feature set extends beyond directory capabilities, which we will explore in detail, to a host of other functionalities engineered to integrate smoothly with SAP S/4HANA and SAP BW hierarchies. The outcome is a more efficient experience in modeling these hierarchies within SAP Datasphere, with a richer end-user experience.

This blog post kicks off a series dedicated to unpacking the Hierarchy with Directory bit by bit. We begin with an overview of the new features. Following that, we’ll detail the functionality across two posts, starting with constructing a simple data model to represent a product, and then expanding the hierarchy with additional capabilities. This approach ensures you gain a thorough grasp of the hierarchy features, setting the stage for in-depth guides on integrating specific S/4HANA hierarchies such as GL Account, Cost Center, and Profit Center. A screenshot of the end-result of a GL Account Hierarchy is illustrated in Figure 1.

Here’s what we have lined up for you:

1. An Introduction to Hierarchy with Directory (this blog)
2. Modeling a basic Hierarchy with Directory
3. Modeling an advanced Hierarchy with Directory
4. Create SAP S/4HANA GL Account Hierarchy within SAP Datasphere through Community Content
5. More to be added…

Figure 1: Screenshot of a GL Account Hierarchy, created as Hierarchy with Directory

What’s new?

The Hierarchy with Directory is a new Semantic Usage inside a view, just like a Dimension or a Fact can be set as the Semantic Usage. Part of the feature set is configured inside that view, but the full feature set is leveraged by associating other views, such as Dimension or Text views. The below diagram shows an example of the objects required for a minimal data model that leverages a Hierarchy with Directory. The details of this are all explained in this and subsequent blogs.

Figure 2: The core view types for building a Hierarchy with Directory

In the upcoming sections, we’ll briefly discuss the new features. Our next blog explains how these features can be used, using a comprehensive deep-dive. However, to get the most out of it, we suggest familiarizing yourself with the features first.

Please note that the Hierarchy with Directory is a wholly new suite of functionalities. These exist in parallel with, yet separate from, the pre-existing hierarchy modeling features found within a Dimension, or with Semantic Usage Hierarchy.

Data-driven definition of parent-child hierarchies

A Hierarchy with Directory is designed to be data-driven. Create the view and its associations once—for instance, for a Product Hierarchy—and it’s ready to manage multiple hierarchies. These are all housed within a single dataset, each with a unique identifier allowing for straightforward selection in a front-end tool. Thus, updating hierarchies is as easy as modifying their underlying data. The directory functions as an index, consolidating all hierarchies in the dataset, akin to SAP S/4HANA and SAP BW practices. As illustrated in Figure 2, a Dimension is linked to the Hierarchy with Directory, acting as the directory itself, with Figure 3 showcasing a couple of example entries from a Product Hierarchy Directory.

Figure 3: Minimal form of a Hierarchy Directory with two entries

External hierarchy

The Hierarchy with Directory is an external hierarchy. This means that it is independent and self-contained, holding its own data that outlines the node relationships. After its creation, it can be associated to various dimensions, so that any Fact data with those dimensions can be presented in a hierarchy structure. The relations between a Dimension and the Hierarchy with Directory are illustrated in Figure 2.

Nodes of different dimensions within the same hierarchy

The leaf nodes of a Hierarchy with Directory are always of the type of the dimension that the hierarchy is associated with. For example, in a Product Hierarchy, the leaf nodes are of type product. However, in such a hierarchy, products can be grouped into other dimensions like product category, and these again can be grouped into a responsible department. Defining distinct dimensions for inner nodes is now supported, and Figure 4 provides an example of that.

Figure 4: A product hierarchy with different node types

Language-dependent hierarchy descriptions

Each hierarchy is defined in a Hierarchy Directory with a name and a label. The label is used for example when end-users choose a hierarchy from a list of available hierarchies. The label can be stored in multiple languages, and simply requires a language key field to be added to the Hierarchy Directory. SAP Datasphere allows you to select a Data Access Language, and based on the language selected in your settings, it will fetch the hierarchy label from the Hierarchy Directory.

Figure 5: Choosing the Data Access Language in SAP Datasphere

Language-dependent node texts

Like hierarchy descriptions, node texts now also support multiple languages, for both inner and leaf nodes. This is simply achieved through configuring Dimension views with their corresponding Text views, which is functionality that we already have for some time. What’s new is that once you associate those dimensions to the different node types in your hierarchy, these texts are available in your hierarchy display options as well. Again, if your texts have a language field defined, SAP Datasphere will fetch the language based on your Data Access Language.

Figure 6: Language-dependent node texts

Time-dependent hierarchies

Hierarchies can be configured for time-dependency, by adding a date validity interval to the Hierarchy Directory. This allows you to deactivate obsolete hierarchies or add hierarchies that only become active from a certain date, such as when a new book year starts. When selecting a hierarchy in the end-user tool, or in the data preview of the Analytic Model, only the hierarchies valid at that time show up. It’s also possible to configure a Reference Date Variable in the Analytic Model, so that the end-user can choose for which date the validity of hierarchies should be determined.

Figure 7: Choosing a Reference Date, e.g., to determine validity of hierarchies

Figure 8: An end-user can only choose hierarchies active at that time, or at the set Reference Date

Time-dependent hierarchy nodes

The assignment of a child node to its parent node can also be made time-dependent, which for example is typical for employee structures when reporting lines change. The fields required for this are marked in the Product Hierarchy entity in Figure 9.

Time-dependent attributes of associated dimensions are also considered. For example, dimensions can have time-dependent texts. If such dimension is associated to a node type, such as the Product Category Text which is associated to Product Category in Figure 9, then the node text valid at that time, or determined using the Reference Date Variable, is displayed.

Figure 9: Date validity interval for Child (Node ID) – Parent assignments, and for Hierarchy Node Texts

Feature differences classic SAP hierarchies

The sections above have highlighted the new features. Those with a deep understanding of hierarchies in SAP S/4HANA or SAP BW will find these features familiar. Yet, it’s important to note what isn’t included or how these differ from the classic hierarchies. Here are the key distinctions:

• For texts associated to the hierarchy nodes, you can choose between display of the Child ID or the Text, but you cannot display the technical key of the dimension.
• Dimension values not used as hierarchy nodes won’t appear in the hierarchy; there’s no Unassigned nodes You can manually add these nodes by integrating them from the dimension into a custom unassigned node.
• In SAP Datasphere, each Hierarchy with Directory holds its own data. A Product Hierarchy for example can contain multiple hierarchies, as they are data-driven as discussed before. But there is no central hierarchy table that stores all hierarchies of all different sorts.
• There is no authorization functionality on hierarchy nodes, no sign-reversal functionality, and no support for ordering siblings according to nextid.
• There’s no dedicated hierarchy data preview. Instead, you preview data using the Analytic Model, which necessitates both transaction and dimension data.

Conclusion

In this blog we introduced the Hierarchy with Directory, which provides a rich set of functionalities to model hierarchies, most notably SAP S/4HANA and SAP BW hierarchies. The upcoming blogs are all about how to use this functionality. We start with building a simplified data model around product sales, and then extend it to use all hierarchy features. Then we move to consuming hierarchies from SAP S/4HANA for GL Account, Cost Center and Profit Center. For all these, we also provide you with community content to get you started.

Coming up next: Modeling a basic Hierarchy with Directory.