Using 0COSTCENTER_0101_HIER and Hierarchy with Directory

 

End-to-end Datasphere modelling flow for the cost center hierarchy scenario.

1. Introduction

This blog explains how the SAP Business Content DataSource 0COSTCENTER_0101_HIER can be replicated into SAP Datasphere and converted from a flat hierarchy extract into a consumable analytical hierarchy. The same pattern can be used when transaction data contains Cost Center as a key dimension and business users need to analyze measures by hierarchy nodes, groups, and leaf-level cost centers.

The purpose of this write-up is to document a practical proof of concept and make the modelling approach easier to repeat. The focus is not only on the individual artifacts, but also on the sequence: source activation, replication, flat-table analysis, hierarchy modelling, dimension modelling, and final analytical consumption.

2. Target Architecture and Modelling Sequence

The complete solution can be organized into six logical layers:

Source layer: Activate the standard hierarchy DataSource 0COSTCENTER_0101_HIER in the SAP source system.Replication layer: Replicate the hierarchy through a Datasphere Replication Flow using the SAPI-based connector.Raw hierarchy layer: Analyze the replicated local table, especially the columns that represent parent-child relationships and node types.Hierarchy layer: Create a hierarchy directory dimension and a Hierarchy with Directory view.Master data layer: Create the Cost Center text and Cost Center dimension views, then associate the hierarchy and text views.Consumption layer: Join the Cost Center dimension to the fact model and consume it in an Analytical Model with hierarchy selection.

3. Prerequisites

SAP source system access to activate and test the Business Content DataSource 0COSTCENTER_0101_HIER, typically using RSA5/RSA6 and ODQMON.SAP Datasphere space with a configured SAPI-based source connection and permission to create Replication Flows, local tables, SQL views, graphical views, dimensions, hierarchies, and analytical models.A Cost Center attribute/text source or equivalent master data extract to build the Cost Center Dimension and Cost Center Text View.A transaction/fact model that contains Cost Center, and where required, Controlling Area, so that the hierarchy can be consumed against measures.

4. Activate and Validate the SAP Source DataSource

Start by installing the Business Content DataSource 0COSTCENTER_0101_HIER from RSA5 and activating it. In the source system, the hierarchy appears in a tree format; this is useful for functional validation because it confirms that the hierarchy exists before it is replicated to Datasphere.

 

Source-system view of the Cost Center hierarchy after Business Content activation.

After activation, use ODQMON to confirm that the ODP queue is available and that extraction requests are technically successful. This check is important before troubleshooting any Datasphere modelling issue, because it separates source-extraction issues from modelling issues.

 

ODQMON confirmation for the hierarchy extraction request.

5. Replicate the Hierarchy into SAP Datasphere

Create a Replication Flow in Datasphere for 0COSTCENTER_0101_HIER. The output of this step is a local table in Datasphere. At this point, the data is intentionally flat. Datasphere will not automatically show the BW-style hierarchy tree until the hierarchy semantics are defined in modelling artifacts.

 

Replication Flow from the SAP source system to the Datasphere local table.

6. Analyze the Flat Hierarchy Table

This is the most important design step. The replicated table contains all hierarchy records in a flat structure. Before creating the hierarchy artifact, identify the fields that represent the hierarchy name, parent node, child node, node type, node text, and leaf cost center.

Topic

Recommendation / Explanation

HIENM

Hierarchy name or hierarchy identifier. This is used to distinguish one hierarchy from another and to associate the hierarchy records with the directory view.

PARENTID

Parent identifier. It defines where each node sits below another node. Root-level records normally have a blank or initial parent reference.

NODEID / CHILDID

Unique internal identifier of the hierarchy node. Use the actual child-node identifier available in your replicated structure; in this POC, NODEID/CHILDID represents the child side of the relationship.

FIELDNM

Node type discriminator. It tells Datasphere whether a row is a hierarchy group node or a cost center leaf node.

NODENAME

Hierarchy group node value. These rows represent structure/group nodes, not transactional cost centers.

TXTLG

Long text for hierarchy group nodes. This becomes the user-facing label for structural nodes.

KOKRS

Controlling Area. This is required when Cost Center is compounded with Controlling Area.

KOSTL

Cost Center. These are the data-bearing leaf nodes used to join the hierarchy to transaction data.

 

Local hierarchy table showing the parent identifier used to reconstruct the tree.

 

Local hierarchy table showing the node identifier / child-side identifier.

 

Node type and text fields used to separate hierarchy nodes from cost center leaf nodes.

How to Interpret the Node Types

In the replicated local table, FIELDNM acts as the node type column. In this scenario, two node types are relevant:

NODENAME: Represents structural hierarchy nodes such as the standard hierarchy, administration, executive, or other grouping nodes. These records usually carry the visible description in TXTLG.KOSTL: Represents actual cost center leaf nodes. These records carry KOKRS and KOSTL and are the records that can be associated with transactional data.

The parent-child relationship is maintained using the parent identifier and the node/child identifier. Datasphere uses these fields to reconstruct the tree in the Hierarchy with Directory artifact.

7. Create the Hierarchy Directory Dimension

Create a SQL view that returns the list of hierarchy root or directory entries. Set the Semantic Usage to Dimension. This view provides the list of available hierarchy roots that users can select from in the analytical experience.

 

Hierarchy directory dimension view with Semantic Usage set to Dimension.

The hierarchy directory view should expose the hierarchy identifier and the descriptive text that users will see when selecting a hierarchy. Keep this artifact simple and stable because the Hierarchy with Directory view depends on it.

8. Create the Cost Center Hierarchy with Directory

Create the hierarchy view and set Semantic Usage to Hierarchy with Directory. Associate this view with the hierarchy directory dimension created in the previous step. This artifact is responsible for converting the flat replicated table into a hierarchy that Datasphere can consume.

 

Hierarchy with Directory view associated with the hierarchy directory dimension.

Attribute Definition and Compounding

If Cost Center is compounded with Controlling Area, define the key columns accordingly and set the representative key to Cost Center. This allows the analytical model to display Cost Center as the primary business value while still preserving the full technical uniqueness required by the source system.

 

Compound key definition with Cost Center as the representative key.

Multiple Hierarchy Settings

In the Multiple Hierarchy Settings dialog, map the flat-table columns into the hierarchy semantics. The exact field names may vary by source, but the design principle remains the same:

Map the parent field to the column that stores the parent node identifier, such as PARENTID.Map the child field to the column that stores the current node identifier, such as NODEID or CHILDID, depending on your local table structure.Select the hierarchy directory association and link it to the directory dimension.Use FIELDNM as the node type column.Define NODENAME as a structural node type and map its display text to TXTLG.Define KOSTL as the data-node type and map its key columns to KOKRS and KOSTL.

 

Multiple Hierarchy Settings for parent, child, hierarchy directory, node type, and NODENAME text.

 

Data-node configuration for KOSTL using KOKRS and KOSTL.

9. Create the Cost Center Text View

Create a text view from the relevant Cost Center text source and set Semantic Usage to Text. This view provides readable descriptions for Cost Center and, when applicable, Controlling Area. Without a text view, the hierarchy may still work technically, but the analytical output will be less user-friendly.

 

Cost Center Text View with Semantic Usage set to Text.

10. Create the Cost Center Dimension

Create the Cost Center Dimension using the relevant Cost Center attribute source. Set Semantic Usage to Dimension. Then associate the Cost Center Dimension with both the Cost Center Hierarchy with Directory and the Cost Center Text View.

 

Cost Center Dimension associated with the hierarchy and text views.

This dimension becomes the reusable semantic object that can be consumed by transaction models. The association to the hierarchy enables hierarchical display, while the association to the text view improves readability for end users.

11. Add the Cost Center Dimension to the Fact / Analytical Model

Add the Cost Center Dimension to the transaction model where Cost Center exists in the fact data. The fact model should expose business measures and include the key fields needed to associate with the Cost Center Dimension. If Cost Center is compounded, make sure the join condition includes the required compounding field, such as Controlling Area.

 

Analytical Model consuming the transaction fact source and the Cost Center Dimension.

 

Final graphical flow showing the hierarchy and transaction modelling chain.

12. Consume the Hierarchy in the Analytical Preview

Run the analytical model and place Cost Center in the row axis. From the Cost Center dimension options, choose the hierarchy presentation and select the required hierarchy root. Datasphere then renders the Cost Center values in hierarchical form.

 

Selecting the hierarchy presentation for Cost Center in the analytical preview.

 

Selecting the required hierarchy root during analytical consumption.

 

Final hierarchical output in the analytical preview.

13. Validation Checklist

Confirm that the hierarchy root list appears from the hierarchy directory dimension.Confirm that structural nodes are displayed with readable descriptions from the NODENAME/TXTLG mapping.Confirm that cost center leaf nodes appear below the correct parent nodes.Confirm that measures roll up correctly from leaf cost centers to parent hierarchy nodes.Confirm that the Cost Center Dimension join to the fact data includes all required key fields, especially Controlling Area if Cost Center is compounded.Compare a small hierarchy branch with the source-system hierarchy to confirm the parent-child reconstruction.

14. Common Issues and Practical Tips

Topic

Recommendation / Explanation

Hierarchy appears flat

Check whether the view is set to Hierarchy with Directory and whether parent, child, hierarchy directory, and node type mappings are correctly assigned.

Root hierarchy is not selectable

Validate the hierarchy directory dimension and its association to the hierarchy view.

Cost centers appear without text

Check the Cost Center Text View and its association to the Cost Center Dimension.

Measures do not roll up correctly

Validate that cost center leaf nodes are defined as data nodes and that the dimension is joined correctly to the fact model.

Duplicate or missing leaf nodes

Review the compounded key definition. For Cost Center, include Controlling Area where required and use Cost Center as the representative key.

Source and Datasphere hierarchy do not match

Compare the parent-child IDs in the local table against the source hierarchy branch and confirm the selected hierarchy root.

15. Conclusion

The key learning from this exercise is that hierarchy replication and hierarchy consumption are two different steps. The 0COSTCENTER_0101_HIER DataSource brings the hierarchy structure into Datasphere as a flat local table. The hierarchy becomes analytically useful only after the parent-child fields, node type column, hierarchy directory, text mapping, and cost center dimension associations are modelled correctly.

Once the semantic layer is in place, the Cost Center hierarchy can be reused across analytical models. This approach helps SAP Datasphere provide a business-friendly hierarchy experience similar to what users expect from BW, while keeping the modelling transparent and extensible for future hierarchy scenarios.

Note: Object names and screenshots are from a proof-of-concept scenario. Adjust field names and associations based on your actual Datasphere local table structure and source-system configuration.

 

​ Using 0COSTCENTER_0101_HIER and Hierarchy with Directory End-to-end Datasphere modelling flow for the cost center hierarchy scenario.1. IntroductionThis blog explains how the SAP Business Content DataSource 0COSTCENTER_0101_HIER can be replicated into SAP Datasphere and converted from a flat hierarchy extract into a consumable analytical hierarchy. The same pattern can be used when transaction data contains Cost Center as a key dimension and business users need to analyze measures by hierarchy nodes, groups, and leaf-level cost centers.The purpose of this write-up is to document a practical proof of concept and make the modelling approach easier to repeat. The focus is not only on the individual artifacts, but also on the sequence: source activation, replication, flat-table analysis, hierarchy modelling, dimension modelling, and final analytical consumption.2. Target Architecture and Modelling SequenceThe complete solution can be organized into six logical layers:Source layer: Activate the standard hierarchy DataSource 0COSTCENTER_0101_HIER in the SAP source system.Replication layer: Replicate the hierarchy through a Datasphere Replication Flow using the SAPI-based connector.Raw hierarchy layer: Analyze the replicated local table, especially the columns that represent parent-child relationships and node types.Hierarchy layer: Create a hierarchy directory dimension and a Hierarchy with Directory view.Master data layer: Create the Cost Center text and Cost Center dimension views, then associate the hierarchy and text views.Consumption layer: Join the Cost Center dimension to the fact model and consume it in an Analytical Model with hierarchy selection.3. PrerequisitesSAP source system access to activate and test the Business Content DataSource 0COSTCENTER_0101_HIER, typically using RSA5/RSA6 and ODQMON.SAP Datasphere space with a configured SAPI-based source connection and permission to create Replication Flows, local tables, SQL views, graphical views, dimensions, hierarchies, and analytical models.A Cost Center attribute/text source or equivalent master data extract to build the Cost Center Dimension and Cost Center Text View.A transaction/fact model that contains Cost Center, and where required, Controlling Area, so that the hierarchy can be consumed against measures.4. Activate and Validate the SAP Source DataSourceStart by installing the Business Content DataSource 0COSTCENTER_0101_HIER from RSA5 and activating it. In the source system, the hierarchy appears in a tree format; this is useful for functional validation because it confirms that the hierarchy exists before it is replicated to Datasphere. Source-system view of the Cost Center hierarchy after Business Content activation.After activation, use ODQMON to confirm that the ODP queue is available and that extraction requests are technically successful. This check is important before troubleshooting any Datasphere modelling issue, because it separates source-extraction issues from modelling issues. ODQMON confirmation for the hierarchy extraction request.5. Replicate the Hierarchy into SAP DatasphereCreate a Replication Flow in Datasphere for 0COSTCENTER_0101_HIER. The output of this step is a local table in Datasphere. At this point, the data is intentionally flat. Datasphere will not automatically show the BW-style hierarchy tree until the hierarchy semantics are defined in modelling artifacts. Replication Flow from the SAP source system to the Datasphere local table.6. Analyze the Flat Hierarchy TableThis is the most important design step. The replicated table contains all hierarchy records in a flat structure. Before creating the hierarchy artifact, identify the fields that represent the hierarchy name, parent node, child node, node type, node text, and leaf cost center.TopicRecommendation / ExplanationHIENMHierarchy name or hierarchy identifier. This is used to distinguish one hierarchy from another and to associate the hierarchy records with the directory view.PARENTIDParent identifier. It defines where each node sits below another node. Root-level records normally have a blank or initial parent reference.NODEID / CHILDIDUnique internal identifier of the hierarchy node. Use the actual child-node identifier available in your replicated structure; in this POC, NODEID/CHILDID represents the child side of the relationship.FIELDNMNode type discriminator. It tells Datasphere whether a row is a hierarchy group node or a cost center leaf node.NODENAMEHierarchy group node value. These rows represent structure/group nodes, not transactional cost centers.TXTLGLong text for hierarchy group nodes. This becomes the user-facing label for structural nodes.KOKRSControlling Area. This is required when Cost Center is compounded with Controlling Area.KOSTLCost Center. These are the data-bearing leaf nodes used to join the hierarchy to transaction data. Local hierarchy table showing the parent identifier used to reconstruct the tree. Local hierarchy table showing the node identifier / child-side identifier. Node type and text fields used to separate hierarchy nodes from cost center leaf nodes.How to Interpret the Node TypesIn the replicated local table, FIELDNM acts as the node type column. In this scenario, two node types are relevant:NODENAME: Represents structural hierarchy nodes such as the standard hierarchy, administration, executive, or other grouping nodes. These records usually carry the visible description in TXTLG.KOSTL: Represents actual cost center leaf nodes. These records carry KOKRS and KOSTL and are the records that can be associated with transactional data.The parent-child relationship is maintained using the parent identifier and the node/child identifier. Datasphere uses these fields to reconstruct the tree in the Hierarchy with Directory artifact.7. Create the Hierarchy Directory DimensionCreate a SQL view that returns the list of hierarchy root or directory entries. Set the Semantic Usage to Dimension. This view provides the list of available hierarchy roots that users can select from in the analytical experience. Hierarchy directory dimension view with Semantic Usage set to Dimension.The hierarchy directory view should expose the hierarchy identifier and the descriptive text that users will see when selecting a hierarchy. Keep this artifact simple and stable because the Hierarchy with Directory view depends on it.8. Create the Cost Center Hierarchy with DirectoryCreate the hierarchy view and set Semantic Usage to Hierarchy with Directory. Associate this view with the hierarchy directory dimension created in the previous step. This artifact is responsible for converting the flat replicated table into a hierarchy that Datasphere can consume. Hierarchy with Directory view associated with the hierarchy directory dimension.Attribute Definition and CompoundingIf Cost Center is compounded with Controlling Area, define the key columns accordingly and set the representative key to Cost Center. This allows the analytical model to display Cost Center as the primary business value while still preserving the full technical uniqueness required by the source system. Compound key definition with Cost Center as the representative key.Multiple Hierarchy SettingsIn the Multiple Hierarchy Settings dialog, map the flat-table columns into the hierarchy semantics. The exact field names may vary by source, but the design principle remains the same:Map the parent field to the column that stores the parent node identifier, such as PARENTID.Map the child field to the column that stores the current node identifier, such as NODEID or CHILDID, depending on your local table structure.Select the hierarchy directory association and link it to the directory dimension.Use FIELDNM as the node type column.Define NODENAME as a structural node type and map its display text to TXTLG.Define KOSTL as the data-node type and map its key columns to KOKRS and KOSTL. Multiple Hierarchy Settings for parent, child, hierarchy directory, node type, and NODENAME text. Data-node configuration for KOSTL using KOKRS and KOSTL.9. Create the Cost Center Text ViewCreate a text view from the relevant Cost Center text source and set Semantic Usage to Text. This view provides readable descriptions for Cost Center and, when applicable, Controlling Area. Without a text view, the hierarchy may still work technically, but the analytical output will be less user-friendly. Cost Center Text View with Semantic Usage set to Text.10. Create the Cost Center DimensionCreate the Cost Center Dimension using the relevant Cost Center attribute source. Set Semantic Usage to Dimension. Then associate the Cost Center Dimension with both the Cost Center Hierarchy with Directory and the Cost Center Text View. Cost Center Dimension associated with the hierarchy and text views.This dimension becomes the reusable semantic object that can be consumed by transaction models. The association to the hierarchy enables hierarchical display, while the association to the text view improves readability for end users.11. Add the Cost Center Dimension to the Fact / Analytical ModelAdd the Cost Center Dimension to the transaction model where Cost Center exists in the fact data. The fact model should expose business measures and include the key fields needed to associate with the Cost Center Dimension. If Cost Center is compounded, make sure the join condition includes the required compounding field, such as Controlling Area. Analytical Model consuming the transaction fact source and the Cost Center Dimension. Final graphical flow showing the hierarchy and transaction modelling chain.12. Consume the Hierarchy in the Analytical PreviewRun the analytical model and place Cost Center in the row axis. From the Cost Center dimension options, choose the hierarchy presentation and select the required hierarchy root. Datasphere then renders the Cost Center values in hierarchical form. Selecting the hierarchy presentation for Cost Center in the analytical preview. Selecting the required hierarchy root during analytical consumption. Final hierarchical output in the analytical preview.13. Validation ChecklistConfirm that the hierarchy root list appears from the hierarchy directory dimension.Confirm that structural nodes are displayed with readable descriptions from the NODENAME/TXTLG mapping.Confirm that cost center leaf nodes appear below the correct parent nodes.Confirm that measures roll up correctly from leaf cost centers to parent hierarchy nodes.Confirm that the Cost Center Dimension join to the fact data includes all required key fields, especially Controlling Area if Cost Center is compounded.Compare a small hierarchy branch with the source-system hierarchy to confirm the parent-child reconstruction.14. Common Issues and Practical TipsTopicRecommendation / ExplanationHierarchy appears flatCheck whether the view is set to Hierarchy with Directory and whether parent, child, hierarchy directory, and node type mappings are correctly assigned.Root hierarchy is not selectableValidate the hierarchy directory dimension and its association to the hierarchy view.Cost centers appear without textCheck the Cost Center Text View and its association to the Cost Center Dimension.Measures do not roll up correctlyValidate that cost center leaf nodes are defined as data nodes and that the dimension is joined correctly to the fact model.Duplicate or missing leaf nodesReview the compounded key definition. For Cost Center, include Controlling Area where required and use Cost Center as the representative key.Source and Datasphere hierarchy do not matchCompare the parent-child IDs in the local table against the source hierarchy branch and confirm the selected hierarchy root.15. ConclusionThe key learning from this exercise is that hierarchy replication and hierarchy consumption are two different steps. The 0COSTCENTER_0101_HIER DataSource brings the hierarchy structure into Datasphere as a flat local table. The hierarchy becomes analytically useful only after the parent-child fields, node type column, hierarchy directory, text mapping, and cost center dimension associations are modelled correctly.Once the semantic layer is in place, the Cost Center hierarchy can be reused across analytical models. This approach helps SAP Datasphere provide a business-friendly hierarchy experience similar to what users expect from BW, while keeping the modelling transparent and extensible for future hierarchy scenarios.Note: Object names and screenshots are from a proof-of-concept scenario. Adjust field names and associations based on your actual Datasphere local table structure and source-system configuration.   Read More Technology Blog Posts by Members articles 

#SAP

#SAPTechnologyblog