We’ve all been there. You are building the perfect SAP analytics landscape. S/4HANA, BW, Datasphere and SAP Analytics Cloud are dancing together in perfect harmony. Your master data is clean. Your compound characteristics – like Controlling Area and Cost Center – are mapped beautifully.
And then, you look at the screen. In one report, your compound key looks like 1000/2000. In the next, it’s 10002000.
Welcome to the ultimate separator showdown: The Slash vs. The Backslash. It sounds like a minor detail, but as any data architect knows, this is the kind of formatting chaos that drives business users crazy.
Let’s unpack why SAP Datasphere is currently giving us mixed signals.
The Standard Content Confusion
When you dive into SAP Datasphere standard content, the way compound characteristics are represented depends entirely on how you look at them.
- The Flat Representation: If you look at a flat list or preview, Datasphere defaults to a backslash ( )
- The Hierarchy Representation: The moment you switch to a hierarchy representation in the standard content, it magically changes to a forward slash ( / )
“No problem,” you might think, “I will just change it!”
And you can! If you manually intervene and edit the view settings, you can force the hierarchy representation to use a backslash, too.
In the views behind the Cost Center dimension the behavior for hierarchy representation is customized via calculated columns. (Please note that this example is based on the standard dimension view for Cost Center of the Business Content “Finance Foundation for SAP S/4HANA and SAP S/4HANA Cloud”)
So, should the standard dimension be adjusted? Typically, I would say “No!”. But then, a native Datasphere feature enters the room to mess with your formatting again.
The “Unassigned” Node Trap
Datasphere has a built-in feature to handle unassigned nodes in hierarchies. To use it, you create a view that automatically derives an unassigned node. The catch? This derived node strictly uses the backslash ( ) representation.
If you are using the standard content hierarchy (which defaults to a forward slash) along with this standard unassigned node feature, your hierarchy will now display a wild mix of both slashes. Some nodes will split with ” / “, while the unassigned parts split with ” “.
But that brings us to the ultimate question: What is actually right, and what is wrong?
The Frontend Nightmare: SAC and Excel
If Datasphere lived in a vacuum, we could just enforce the backslash. But it doesn’t.
Classic BW and CDS queries have historically used the forward slash for compound characteristics. SAP Analytics Cloud (SAC), acting as the strategic frontend, connects to all of these.
If you are a “perfect” SAP customer utilizing the full stack – Datasphere, S/4HANA and BW – SAC is going to serve your end-users a chaotic cocktail of slashes.
This raises an even bigger architectural question: What is the right representation for SAC Public Dimensions? Since they don’t support compounding natively, we are forced to actively choose and build a workaround between the slash and backslash.
And let’s not even talk about the power users who export this data to Excel. To a spreadsheet, a backslash can change how formulas react, how text-to-columns works or simply cause visual confusion.
The root of all evil here? The generic use of the backslash in Datasphere.
How Should We Deal With This?
- The “Hope for the Future” Strategy: Keep the forward slash for the hierarchy representation and hope that the Datasphere product team aligns with historical SAP standards in future updates. The downside: Flat representations on a Datasphere Analytic Model will still show a mismatched backslash.
- The “Forced Consistency” Strategy: Manually change the standard hierarchy views to use the backslash everywhere. The downside: You are modifying standard content and fighting against the historical forward-slash standard of BW and S/4HANA.
- The “Anti-Compounding” Strategy: Simply stop using compounding in Datasphere altogether and manually enforce the forward slash across your custom models.
Dear reader, I would like to hear from you:
- Which of these architectural strategies are you using in your live projects?
- Have you found a cleaner workaround?
- Do you have an idea, why Datasphere relies on the backslash for compounding?
Help Fix the Slash Mess!
We shouldn’t have to build custom workarounds for standard features just to keep our slashes straight. I have created an SAP Customer Influence Request to get this fixed.
Let’s convince the Datasphere product team that the forward slash deserves to rule them all (or at least, that consistency should):
#abap