At the end of last month I ask on Twitter why I should create a join between an Advanced DataStoreObject and an InfoObject to read the attributes from this InfoObject when I even can activate the attributes on the output tab of the Composite Provider in SAP BW/4HANA. The answers on Twitter was not satisfactory, and I ask a colleague if he knew a reason. So I build a Composite Provider with a join between an InfoObject and an ADSO in our BW/4HANA system.
Now I have the same picture as in my post on Twitter. The screenshot there is from the book BW4/HANA - An Introduction. So maybe when this book came out in 2017 it was a good idea to build a Composite Provider like this. So let's give it a try. First we need some data for our ADSO, so I used my Sales Data DSO which I already have. Then we have to create for this test an attribute. I decided to add the Business Category to my Country InfoObject.
Now I thought I don't win anything when I join the InfoObject Country with my ADSO Sales Data and add the Business Category from the InfoObject to my Composite Provider. So there must be a way to use this scenario. So I added to my InfoObject Business Category the InfoObject Partner.
Now we are facing some cool idea. Can I report on my Partner and get the Sales Data for it? Even when the Partner is not in the ADSO or has a relationship to an object which is directly in the Advanced DataStoreObject? So we can now activate on the output tab of the Composite Provider the navigation attribute of my Business Category.
So let's look into SAP Analysis for Office and analyze the data with the Partner.
And voilà it works perfectly. Now I can analyze my data with a dimension which has nothing to do with my data model.
Conclusion
So I think this could be a nice way to combine data with InfoObjects which have nothing to do with the data model. So It could be for example to report the sales rep responsible profit center with some financial data which as only the customer in the data model. So you have a link between the customer and as navigation attribute the sales rep. And each sales rep has a profit center. What do you think about this idea?
author.
Hi,
I am Tobias, I write this blog since 2014, you can find me on twitter, facebook and youtube. I work as a Senior Business Warehouse Consultant. In 2016, I wrote the first edition of Analysis Office - The Comprehensive Guide. If you want you can leave me a paypal coffee donation. You can also contact me directly if you want.
Subscribe
- In my newsletter you get informed about new topics
- You learn how to use SAP Analysis for Office
- You get tips and tricks about SAP BI topics
- You get the first 3 chapters of my e-book SAP Analysis for Office - The Comprehensive Guide for free
You want to know SAP Analysis for Office in a perfect detail?
You want to know how to build an Excel Dashboard with your Query in Analysis for Office?
You want to know how functions in SAP Analysis for Office works?
Then you have to take a look into Analysis for Office - The Comprehensive Guide. Either as a video course or as an e-book.
Write a comment
Dietmar (Saturday, 07 November 2020 04:23)
Your conclusion is right: "... which have NOTHING to do with the data model ..."
But, if it has to do with the data-model, you have to activate the "transitive attributes" in the IOBJ,
so you can use the NAV-attribute within a NAV-attribute !
Tobias (Monday, 09 November 2020 08:15)
Yes you are right, but I have to "change" my original object and add a nav attribute which I maybe only need for one report and otherwise it is not neccessary. I know there are always several ways to solve the problem. Thanks for clearing it up.
Aaron (Tuesday, 08 December 2020 02:18)
Either way you have to change the object (transitive) or create a composite provider which joins your original ADSO to an infoobject.
In the second case, you have to copy queries or deal with two objects. I think the transitive option is better.
The one plus about once you create a composite provider, you can easily add other objects to it. Kind of like the old days where best practice was create a multiprovider for every cube, don't write any queries directly on base objects.
Tobias (Wednesday, 16 December 2020 09:04)
You are right Aaron. BW has different ways to do the work. I show different ways and say not my is the best way. I think it depends on the existing data model and what you find in the BW.