Tags: compositeprovider SAP sapbw sapbw73 sapbw74 upgrade. July 6, February 1, February 28, What is the meaning of the square icon next to the image of the local composite provider in RSA1?
|Published (Last):||21 March 2014|
|PDF File Size:||9.16 Mb|
|ePub File Size:||18.22 Mb|
|Price:||Free* [*Free Regsitration Required]|
By this time most of you would have come across the term composite providers w. This paper takes a deeper look at this new type of Info provider and also looks at how modelling scenarios that previously were time consuming could be made easily, in lesser time and also make use of the Calculation engine of HANA to its best.
This paper does not focus on the steps to be followed for creating a composite provider. A Composite Provider is an Info Provider , which combines data from several analytic indexes or from other Info Providers by Join or Union , and makes this data available for reporting and analysis.
The main advantage of Composite providers is that: BW Info Providers can be combined using the JOIN operation allowing us to create new scenarios not possible or very expensive with standard techniques Multiprovider, InfoSet. When we hear the word Union, what strikes our mind immediately is a Multi provider.
This is because the OLAP engine is well suited for this operation. Composite providers however can be used on top of Multiproviders to execute Join operations with Multiprovider as one of the data providers. This gives us additional flexibility and even one additional level of modelling thus allowing us to create new scenarios that were not possible before. Having seen the definition and some of the benefits of Composite providers its time that we jump into some real modelling scenario to see its real benefit.
Modeling Scenario:. A cube is created as a final destination for source data. This cube is loaded from several DSOs containing transaction data and during the loading there are several lookups written inorder to fetch master data attributes from other DSOs and load them in the cube. Regular Modeling Scenario — An example :. Let us take an example of a simple cube. Let us assume that the cube is used for tracking sales information based on customer data and also based on the product sold.
So for the report to have slice and dice capabilities we would need to have all the attributes of Customer as well as Product to be a part of the cube. This is not required in case the attributes are not required historically. Where we can use them as Navigational attributes. For example, to track sales of a city an attribute of customer for a month, and to see its trend in the past, it would make sense to have city as a part of the cube and lookup and populate city every month from customer master, when data is loaded to the cube.
This prevents a customer from being left out if his City was changed historically. Similarly, we also have product attributes like Product Category, Product Group etc. A typical data model for the scenario described above would look like the following:. This scenario depicted above is just an example considering one source DSO, In real-time, the number of DSOs loading to a cube is usually more than one and also the number of look-ups performed can be more than what is depicted here. Modeling Scenario using Composite Provider:.
With the new Composite provider it is possible to realize the dream of storing the same data only once at least for this scenario. The following case shows how we can model the same scenario using a composite provider and thus make use of the calculation capabilities of HANA DB.
How this works:. Addition of a new attribute changes to cubes, which required changing a lot of objects in the earlier scenario is very simple now. Loading time: The time taken for loading huge amounts of data through several layers staging and further in BW is reduced as the Composite providers can be modeled using the DSOs in the EDW layer itself. The time taken for performing look-ups to derive attributes is also saved during loading.
DB Size: A lot of DB — space is saved since we only store information once and use it at different places instead of executing a lookup and storing them every time in the cube. Flexibility: Further to what is shown above and as in the case with most of the real time systems, not just one DSO loads to a cube.
In that case, a Multiprovider is created on top of these DSOs can also be used in the Composite provider to deliver the desired results. In each case it is good to evaluate these possibilities and make a wise decision. I published a document in which the BW 7. Very nicely written articles.
Thanks for the examples used.. I learnt the key views. It has been summarized very nicely. I Think there is a typo error please correct if am wrong. Is these transactions depicts the same or what. Thanks for the clarification. What is your opinion of joining the master data directly in the Composite Provider rather than a master data DSO?
Valid question. One that came to my mind whilst reading this document. Is it a Join? Thanks for sharing. Really useful. Is it possible to write some conditions on Composite Providers? If so, can you please tell me how to write conditions on Composite providers and what all the conditions we can write? Please let me know below scenario possible in BW modelling tools from hana studio.
Thanks for the nice article. However, I have a doubt on the same lookup strategy. How can we achieve this requirement while pushing it to a composite infoprovider? Please advice. Appreciate it. IF city is the attribute of the customer MD, we can enable city as NAV so that the report will have the drill down based on city right.
Is my understanding wrong? Please advise. Based on the above scenario, When Attribute History required, two approaches here, look up during transforming data into the info cube or Maintain Time-dependent attribute in master data tables as we know.
Hope this helps!!! I would like to ask a question In Bw we would see the composite provider. Without going into the hana studio can we find out which operation did composite provider performed Join, union in Bw itself. Is there any Tcode. Former Member. Posted on January 22, 5 minute read.
Follow RSS feed Like. Composite Provider: A Composite Provider is an Info Provider , which combines data from several analytic indexes or from other Info Providers by Join or Union , and makes this data available for reporting and analysis. Regular Modeling Scenario — An example : Let us take an example of a simple cube. A typical data model for the scenario described above would look like the following: This scenario depicted above is just an example considering one source DSO, In real-time, the number of DSOs loading to a cube is usually more than one and also the number of look-ups performed can be more than what is depicted here.
In this typical way, we not only store the same information of the DSOs in an aggregated form in the cube, but also add additional attributes added to the transaction data and stored again in the cubes. The characteristic would then have to be added to the Multiprovider to be made available in the reports.
And on top of this a reload of history is required in case an attribute is required historically. Modeling Scenario using Composite Provider: With the new Composite provider it is possible to realize the dream of storing the same data only once at least for this scenario. By default there should be at least one Info provider of type Union in the Composite provider.
Master data fields required in the composite provider are dragged and dropped into the composite provider. These are the fields for which look-ups were written in the original scenario. In this way, the composite provider will contain all the records present in the Sales transaction DSO with the corresponding attributes filled based on the Calendar Month.
The Joins and Unions are executed at the query execution time. Alert Moderator. Assigned tags. Related Blog Posts. Related Questions. You must be Logged on to comment or reply to a post.
January 22, at pm. Thanks for sharing the views. Like 0. January 23, at pm. Hi Ram, Excellent illustration!! Phani KV. January 24, at am. Very good document about composite provider Thanks, Phani.
Stefan Hoffmann. January 24, at pm. Very good. January 29, at pm. Very usefull and very clear information. February 4, at pm.
Creating a Composite Provider in SAP BW 7.3 on HANA
This combination of data can be done during the staging process by enriching data and by persistence of the result of the enrichment on database level typically a DataStore object or InfoCube or during runtime of the query by performing a union or join operation. Typically you decide to persist the result of the operation in case the data you want to join is not volatile — as otherwise you always would have to realign the data — or if the runtime of the join is to high. In case you want to execute the join during query execution, the metadata objects offered in releases before SAP BW 7. The role of the Composite Provider is to provide a metadata object that forms the data mart layer within BW.
Procedure to create Composite Provider
This includes the popular MultiProvider, used to combine different InfoProviders and to create an abstraction layer for a BW query. It can link InfoProvider objects, even if these are only available as navigation attributes in one of the providers and not directly in the InfoProvider fact table. In this example, the country is allocated once directly and once as a customer navigation attribute. How do you do this with CompositeProviders?
SAP BW on HANA - Composite Providers
Right click on the filed which you need to make joins for the two info providers. In output tab we have the fields which we had selected in the target area, where we assign for each the respective info objects in the association. Now Activate the composite provider. You will find composite provider is available in the info area. What can be the possible reason? I would like to ask a question In Bw we would see the composite provider.