Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Sefan_Linders
Product and Topic Expert
Product and Topic Expert
0 Kudos

In our previous blog, we covered the basics of creating a Hierarchy with Directory. Now, we're taking a step further in this blog by enhancing our model with an extra node type, language-dependent texts, and time-dependency, both for the hierarchies and node assignments. These advanced features are often seen in SAP S/4HANA or SAP BW hierarchies but are also applicable to non-SAP hierarchies. We continue to use a simplified data model with local data for clarity, making it easier to grasp these concepts before applying them to more complex, real-world data sources. The additions to the data model are pointed out in Figure 1, with the numbering corresponding to the section numbers in this blog post. The figure shows all views, and each view has a table with data underneath.
This blog is part of a series in which we introduce the Hierarchy with Directory:

  1. An Introduction to Hierarchy with Directory
  2. Modeling a basic Hierarchy with Directory
  3. Modeling an advanced Hierarchy with Directory (this blog)
  4. Create SAP S/4HANA GL Account Hierarchy within SAP Datasphere through Community Content
  5. Walkthrough of different Enterprise Scenarios via Community Content package – GL Account External Hi...
  6. Order siblings in a Hierarchy with Directory

Figure 1: In yellow all extensions to the views of the basic model

1. Adding another node type

Until now, our node types included Product Category (an inner node type) and Product ID (the leaf node type). To demonstrate the use of multiple inner node types within a single hierarchy, we extend the model with a Department node type. The idea is that the company that sells these products, has different departments, each responsible for one or more product categories.
To incorporate this new node type, we'll make the following updates:

  1. Expand the hierarchy table by adding a Department ID
  2. Insert new entries into the hierarchy table to create a new hierarchy that includes department nodes. We highlight this in Figure 2 with an example, where you can traverse the hierarchy from leaf to root node, starting from the leaf node with Product ID OATMILK_1. The other hierarchies we leave untouched.
  3. Add a new entry to the directory table to denote the new Department hierarchy (see Figure 3).
  4. Update the hierarchy view to include the new node type (see Figure 4).
  5. Add a few Product IDs and transactions to the data, to make the data preview richer.

Figure 2: Extending the hierarchy table with a Department ID column and new hierarchy entries

Figure 3: Adding a new record to the Product Hierarchy Directory table

Figure 4: Adding node type definition for Department in the Hierarchy view


A new data preview shows then the new grouping into departments.
 

Figure 5: OATMILK_1 now rolling up into Product Categories, and then into the new node type Department

2. Adding dimensions with language-dependent texts to node types

Previously, our inner nodes Product Category ID and Department ID were only defined as just text-based columns. However, these are perfect candidates to be defined as Dimensions. Once associated to the Hierarchy, you can utilize dimension features like text labels, language-dependent texts, and/or time-dependent texts, which are typical in SAP S/4HANA and SAP BW hierarchies.
To illustrate this, we created a Product Category dimension with language-dependent texts. The screenshot below illustrates the required new objects and their association with the Product Hierarchy.

Figure 6: New objects for Product Category dimension with language-dependent texts

The following steps describe these changes in more detail:

  1. Create a Product Category text table with columns for Language and Text.
  2. Add sample data to the table. We fill the table for language English (EN) and Dutch (NL) (see Figure 7).
  3. Create a Product Category Text view with semantics configured for language and label (see Figure 8).
  4. Create Product Category table with key entries.
  5. Create a Product Category dimension view, consuming the table, with an association to the text view (see Figure 9).
  6. Create an association from the hierarchy view to the new dimension.

Figure 7: Sample data for Product Category text table

Figure 8: Semantics definition for the Product Category text view

Figure 9: The Product Category dimension view

When refreshing the data preview of the Analytic Model, you now have the option to display either the ID, the Descriptions, or both (Figure 10), after which the more readable labels show up for the product Category nodes (Figure 11).

Figure 10: Choosing ID, Description or both as the presentation mode

Figure 11: Product Category texts are now displayed

Because we created a dimension with language-dependent texts, we can now switch the data language in the SAP Datasphere setting menu. In below screenshots, you can see that we change the language to Dutch, after which the Product Category nodes show the Dutch translation.

Figure 12: Changing the Data Access Language

Figure 13: Product Category texts are now displayed in Dutch

We repeated the same exercise for Department by creating a new dimension with language-dependent texts and extended the Product dimension by adding language-dependent texts. The result is shown in below screenshot. Please note that to display the texts for leaf nodes, like our Product node, you don’t need to create an association from the hierarchy to the dimension. The existing association from the product dimension to the hierarchy is adequate. For inner nodes this is different, and you will have to create associations from the hierarchy to the dimension.

Figure 14: All node types are now associated to dimensions with texts

Please note that at time of writing, when texts have been added to a dimension, it is not possible anymore to display the technical name of the dimension. When selecting ID as presentation, the Child ID will show up instead. In our data model the Child ID is represented by the field Node ID. How this looks like is illustrated in the screenshot below.

Figure 15: Presentation mode ID or ID and Description will show the Child field as ID and not the technical name of the dimension

Adding time-dependency to hierarchies, nodes, and texts

Time-dependency is a common requirement in SAP S/4HANA and SAP BW hierarchies, manifesting in several ways:

  1. Time-dependency of a hierarchy itself. Determined within the Hierarchy Directory, this aspect decides if and when a hierarchy is available.
  2. Time-dependency of node assignments. Defined in the Hierarchy with Directory view, this determines which node is assigned to a parent node within specific time intervals.
  3. Time-dependency of dimension texts. Defined in the Text view using date intervals. While this feature was already accessible, it's now also applicable to a Hierarchy with Directory.

We’ll run through setting up time-dependency for the hierarchy and node assignments.

3. Time-dependency of hierarchies

A hierarchy can be considered active or not, based on an optional time-validity interval. This requires an extension to the previously modeled Product Hierarchy Directory, by adding a Valid From and Valid To field to the Hierarchy Directory table and adjusting the semantics in the Hierarchy Directory view to mark those fields as Business Date From and Business Date To. The below screenshots show the changes we made for the Product Hierarchy Directory table and view.

Figure 16: Adding time-interval fields to the Product Hierarchy Directory

Figure 17: Configuring the semantics for the time-intervals in the Hierarchy Directory View

After making these changes, we could simply reopen the Analytic Model to use today’s date as the reference date to select active hierarchies. Instead, we add a Reference Date Variable to the Analytic Model, so that we can choose a reference date ourselves. In the below screenshots you can see how we add this date inside the main design screen of the Analytic Model. Then, we open the data preview again, choose January 1, 2024 as the reference date, and see the two hierarchies active at that date when prompted for a hierarchy selection.

Figure 18: Adding a reference date variable to the Analytic Model

Figure 19: Choosing the reference date when previewing data in the Analytic Model

Figure 20: The hierarchy selection after providing a 2024 reference date, shows only the two active hierarchies at that point in time

4. Time-dependency of node assignments

The validity of node assignments works in a similar fashion as for hierarchies themselves. As depicted in the figure below, we’ve extended the Product Hierarchy table and view with a validity interval and added specific dates to the data in the table. We configured the semantics that define the Valid From and Valid To fields as Business Date From and Business Date To, similarly as we did for the directory in Figure 17.

Figure 21: Time-interval added to the node assignments in the Product Hierarchy Directory view

The data illustrates a notable change: the Sports department, initially aligned with the Non-food department until the end of 2023, shifts its association to the Food department starting in 2024. This transition is visible in the data preview for the year 2024, as shown in Figure 22.

Figure 22: Data preview with selection date January 1, 2024, where the sports departments changed assignment from the Non-food to Food department

5. Time-dependency of dimension texts

As mentioned before, time-dependency of dimension texts is supported as well for hierarchies and is defined in the Text view using date intervals, just like we outlined already for the time-dependency of hierarchies and hierarchy nodes. Applying the semantics works in the same fashion, by choosing a field for Business Date From and Business Date To. From the previous instructions, you should be able to build this yourself. A sample of the data, with both time-dependent as language-dependent texts, is displayed in the figure below.

Figure 23: Data sample of both language- and time-dependent texts

Conclusion

In this blog we extended the basic hierarchy with another inner node type, language-dependent texts, and time-dependency for hierarchies and node assignments. With these features, we presented most of the features of the Hierarchies with Directory. Together, these features are aligned with well-known hierarchies from SAP S/4HANA and SAP BW, which makes it now a lot easier to consume such hierarchies in SAP Datasphere.

Figure 24: Final hierarchy with different node types and texts

Up next: Create an SAP S/4HANA GL Account Hierarchy within SAP Datasphere through Community Content

10 Comments
hasba_younes
Participant
0 Kudos

@Sefan_Linders Thank you for this Blog, i have a question related to the Hierarchy Directorty, here you have a dimension called "Product Hierarchy Directory" which is specific for this dimension.

we wanted to use as BW has already a table for all Hierarchies: RSHIEDIR and respective it's language dependant texts in RSHIEDIRT

but when trying to select the hierarchy the drop down is showing all hierarchies for all Infoobjects, this does not make sense as the association is done with HIEID.

the Advantage using these tables, is that we create the directory once in Datasphere for all InfoObjects and have a generic use instead of making a directory per Dimension.

have you tried or are you going to show same example with BW? i've seen this example and the S/4Hana but none for BW.

for example we're using the:

/BI0/HCOSTCENTER as Hierarchy 

RSHIEDIR as Dimension for Hierachies directory

the table RSTHIERNODE for the Node Dimensions and their Texts

 

thank you & BR

Younes

 

 

Conor_
Explorer
0 Kudos

@Sefan_Linders thanks for the blog. 

Is there best practices involved with your design approach, could we remove the table 'LT_PRODUCT_CATEGORY' & view ' LV_PRODUCT_CATEGORY' and have the association coming directly from the texts view 'LT_PRODUCT_CATEGORY_TEXTS' instead? (Just wondering about scalability, if say you have a large hierarchy to create, if we should/need to create these additional tables/dimensions to follow SAP best practice).

conorclarke_0-1707817984757.png

Thanks,

Conor

Sefan_Linders
Product and Topic Expert
Product and Topic Expert

Hi @Conor_,

Good point. In this example you could do without LV_PRODUCT_CATEGORY and link up the text table directly. After all, the dimension view in this example does not provide anything else than the ID column. However, in real world dimensions, you will likely have more fields and other semantics available. Also, your dimension will probably already have the text association. In those cases, I would prefer linking the dimension first, with the arguments that it provides clarity to work according to the actual data model. Also, you never know what potential future hierarchy functionality might have in store for linked dimensions. On the other hand, if your hierarchy is custom designed and not based on sources that already provide a dimension, and you don't have the need for a separate dimension, I think you don't need to go through the effort of creating a dimension where you only store the key anyway.

Regards,

Sefan

Sefan_Linders
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi @hasba_younes,

Indeed, BW has a single place for storing the hierarchy directories. In SAP Datasphere every dimension has its own directory. In some calls, the directory entity is accessed directly without a join on the dimension values. So you will have to restrict the hierarchies in the directory to the ones that belong to the dimension. That should work with a simple inner join.

For SAP BW/4HANA and SAP BW Bridge, keep an eye out on the public road map for features that deliver a conversion for hierarchies to SAP Datasphere out of the box.

Conor_
Explorer
0 Kudos

Hi @Sefan_Linders,

Thanks for your response above. Just had a follow-up question.

So the other table 'LT_PRODUCT_CATEGORY' is there to provide another avenue to load product category data through your model, possibly this data has some different/more fields available that you don't have in table 'LT_PRODUCT_CATEGORY_TEXTS', am I correct in saying this? 

Thanks

Conor

Sefan_Linders
Product and Topic Expert
Product and Topic Expert

Hi @Conor_,

Correct. In my case it was a self-created table with dummy data with only that column. But a dimension will often have other fields available as well. Even for product category you could think of change date, changed by, category manager, etc.. 

Conor_
Explorer
0 Kudos

Hi @Sefan_Linders 

Last follow-up 😅

In your example we have a table (LT_PRODUCT_CATEGORY_TEXTS) that contains language, to be consistent with this table, should the other table (LT_PRODUCT_CATEGORY) also contain a language column (I have the understanding that both tables can contain different fields as you have mentioned already, but interested in your thoughts regarding Language being missing from one of the tables)? 

Thanks for all the follow-up so far 😄.

Conor

Sefan_Linders
Product and Topic Expert
Product and Topic Expert

Hi @Conor_,

LT_PRODUCT_CATEGORY is the table serving the data for the dimension. Typically, you would not store language specific fields in a dimension. This would make the dimension a mess, e.g., you would get a record for each language you want to store for a dimension member which would violate basic modeling rules. Instead, one or more fields in a dimension can be linked up to a text. Then, each text can be time-dependent and/or language-dependent. It's in line with how S/4 or BW stores texts. More info on texts here in the help

Conor_
Explorer
0 Kudos

Hi @Sefan_Linders 

Just responding to the last comment. So from a BW perspective, we can view the table 'LT_PRODUCT_CATEGORY' as similar to the attributes 'table' for master data that we would see in BW.

Conor__0-1708602042620.png

I come from a BW background, so trying to find comparisons to understand better. 

Conor

Sefan_Linders
Product and Topic Expert
Product and Topic Expert

Hi @Conor_,

You could see LV_PRODUCT_CATEGORY as the infoobject, and LT_PRODUCT_CATEGORY as the table underneath the infoobject (P*, Q*, etc. as they are called in BW).