Public Dimensions in SAC – manage query volume & master data management with imported data

Hello world,

after a few successful implementations of SAC at customers with imported data in- memory. I thought I would share my experience of working with Public Dimensions.

In SAC different connections are possible, all with specific use cases: in my projects at CTAC, I worked with Public dimensions, with a BW import connections, SQL & ERP infosets, and in each case it showed to be added value!

As there is already a great Blog posted on working with Public Dimensions, I will focus on some other aspects of using Public Dimensions, which have to do more with the back end set up and the advantages for the data load.

Main Advantages of working with Public Dimensions

1. Reduced data load
2. Easy separate modelling of dimensions (hierarchies, attributes) in separate back end queries
3. Master data can be scheduled separately in the back end 
4. A better structure of master data attributes under each dimension 
5. Reusability between different models

Reduced data load

A reduced data load of Columns is a major advantage on optimising queries importing data into SAC. It is only necessary to take the corresponding key of the Public Dimensions, which limits the amount of Lookups of corresponding data entries for the query.

At one of our customers this was crucial, as we quickly went against the limit of data cells allowed to be transferred from BW to SAP AC, and it substantially reduced the running time of a query.

Separate Master Data Modelling 

The advantage of separately modelling Hierarchies and attributes allows users to create a certain logic in the back end and transfer this logic to the front end.

Hierarchies in SAC are parent- child, maintained by having a  unique Child- ID which is unique for each level (best to use a unique compounded key which can be found in the data query as well) and a corresponding parent column.

Note:The parent- ID have also to be mapped as children ID’s. Might be a bit confusing in the beginning, maybe it will even change in future.

Note 2 for the users of BW: you will need to map all your attributes and hierarchies as characteristics of an infoObject.

For the hierarchies, we created a DSO where we mapped the different Hierarchy ID levels with the corresponding +1 parent level, and used this DSO as a characteristic of a new InfoObject.

These can be added to existing Public Dimensions, or new one’s can be created. Here an example

Clear Structure of Master Data Attributes 

For a self- service tool, a clear structure of all Dimensions and attributes is very important, to guide the end user to the right items, and allow them to easily navigate through your data.

Attributes of Master Data items are a great way to provide this structures, where the BW characteristics of Info- Objects easily can be transferred into SAP Analytics Cloud.

Here an example, where we have separated the attributes linked to a Material Group with attributes associated with a Material Sales Group and mapped each one of them in a Public dimension

To mention, there are 2 clear disadvantages of using attributes versus dimensions:

1. Attributes can currently not be used in the explorer, or in Geo Maps as dimensions
2. If you need the ID and the Text of attributes (For sorting purposes), you have to map those as separate attributes, which makes the oversight less good.

Scheduling in the back end

I experience this as a major advantage of using Public Dimensions.

As mentioned above, it reduces the data loads of transactional data, while also allowing you to create dedicated queries for the Master Data items.

In certain cases it might be not necessary to load the master data daily. Keep in mind: if you load transactional data, when the master data has not been loaded yet, all unknown master data ID’s not yet mapped in the Public Dimension will be rejected.

I would suggest to schedule the master data daily before the load of the transactional data

In this example, there were 2 rows rejected because of a “new unknown member” linked to a Public Dimension.

Summary: When best to use Public Dimensions

I would recommend using Public dimensions when

• Having several attributes linked to a Master Data Item
• Creating more complex Hierarchies in the back end
• Having Master Data which needs to be reused
• Having trouble with data loading sizes

Into the future

It is my hope that also SAP will continue to invest in the Public Dimensions, I find it a great way to manage master data, and hope that attributes will soon become available in the explorer and Geo Maps (worth a vote on influence.sap.com).

I also hope that SAP will introduce more specific features which will make working with Public Dimensions easier (empty all fields, Flat Hierarchies, easy to navigate through attributes).

Final Comments 

So, from me: I highly recommend you to start using Public Dimensions for your master data.

Hope this Blog will help to understand some more features.

Any questions, ideas, disagreements…. let’s have a discussion below. Especially if you want to add some more best practice to it!