When good advice is hard to come by

When good advice is hard to come by: navigation attributes from SAP BW and how they are connected to the HANA views generated from them

A look at the current situation and two approaches to make the most of it

Hello everybody:

The combination of SAP BW and HANA has opened up a world of new modeling opportunities. And we have put them to good use in our most recent projects.

One of these modeling opportunities lets you generate HANA views from within the BW system and leverage them for HANA development. This approach is, for example, ideally suited for directly accessing the data in the HANA database without having to take the detour through the Query Designer.

There are, however, some weak spots in this way of directly accessing the data.

One of them being that, unfortunately, navigation attributes are not supported in the way we have come to expect from BW. Here, we are limited by the fact that compound objects (that is, objects with a concatenated key) are not supported. And even though this limitation is well documented, I just have to say: Come on SAP, are you serious?

Especially in large BW landscapes, it is very common to have all your objects compounded – for example with a source system. And now you are telling me that none of these objects are functioning properly anymore? After all, giving us the ability to use navigation attributes was one of the major strengths of BW over these past years.

Simply put, a navigation attribute – just like any other master data object – is what is called a join, for which the master data is read in to the transaction data.

Typically, a Cube or a DSO also holds the characteristics (dimensions, master data, keys of the other tables) along with the fact table (key figures, values). In the past, you could always automatically access the attributes of these characteristics and you practically didn’t have to think twice about how it works. It just did.

Naturally, SAP has issued a recommendation on how to solve the problem. And at Inspiricon, we too have come up with a solution for our project. Both solutions leverage the automatism mentioned earlier. Now let’s have a closer look at what they do.

SAP’s solution

The CompositeProvider as the successor to the MultiProviders should be the object by way of which reporting, or in our case, the data access from within HANA is to be carried out. Underneath of this object, there is one (or several) Cubes, DSOs, and ADSOs. The CompositeProvider has significant advantages over the MultiProvider when it comes to joins. Here, you can create the joins that you need for your master data. Typically, these are left outer joins.

What SAP’s solution now does is to also make the required master data a part of the CompositeProvider. This means they are not used as part of the ADSOs, they are rather once again directly included in the CompositeProvider by join.

The Inspiricon solution

Since we ran into a few problems with the CompositeProviders during this particular project, we built a solution similar to that of SAP, but on a different level.

We didn’t build those joins in BW – and therefore not in the CompositeProvider – but rather in HANA. What we did instead was to use the generated views of the CompositeProviders and of the master data and to then join them.


Summing it all up I can safely say: it works. Both approaches get the job done.

Like for most technical problems there is, indeed, a solution. But it does involve a considerable amount of extra work, regardless of whether you prefer our or SAP’s approach. What bugs me the most is the fact that this extra work isn’t done after they have been created, it has to be put in for every subsequent modification, because these are manual steps that were simply not necessary in the past.

I hope that SAP will step up and solve this problem for good or at least give us an automatism.

But until then, we will weather the headwinds and continue to solve the problem with what we have.

Jörg Waldenmayer Team Lead Technology
Phone: +49 (0) 7031 714 660 0