By this time most of you would have come across the term composite providers BW systems on HANA. 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.

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. UNION and JOIN operations are executed in HANA and not the application server. BEx Queries can be created on Composite Providers as on any other BW Info Provider. This is done in transaction RSLIMOBW.

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. SAP Still suggests the usage of Multiprovider in case your requirement is just to use Unions. 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.

For information on how to create Composite providers using RSLIMOBW refer to

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:

Most  or almost all of us would have come across this typical scenario of building cubes in our projects. 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:

Modeling Scenario.gif

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.
  • An addition of new characteristic to the cube which requires look-up from one of these DSOs would be a herculean task,  as the new characteristic has to be added to the cube and all the impacted transformations, DTPs would have to be transported again with precision. 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.
  • AlthoughSAP has provided a new rule type in the transformation called the “Read DSO data” in the transformation, this would only help us in avoiding the ABAP part of the look-up but not in reducing the effort taken for changes and the expenses.

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.

In transaction RSLIMOBW, we create a Composite provider that uses the 3 Data store objects, Sales Transaction, Customer Master and Product Master as shown below.

Composite Provider.png

How this works:

  • The Sales transaction DSO is taken in the Composite Provider with Binding Type “Union”. By default there should be at least one Info provider of type Union in the Composite provider.
  • The fields of Sales Transaction DSO are dragged into the Central Composite Provider.
  • The Customer Master and the Product Master DSO are added to the Composite provider with the binding type “Join”.
  • 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).
  • The fields Customer number and Calmonth are used as Join fields and a join condition is drawn between the Sales DSO and the Customer Master.
  • Similarly Product number and Calmonth are joined from the Product DSO with the composite provider.
  • 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. UNION and JOIN operations are executed in HANA DB.
  • Note that SID generation option should be checked in the DSO for it to be available as a data provider for Composite provider.


  • Development time & Cost:
    • Using this approach, a lot of time taken to develop look-ups and maintain complex data models is saved.
    • Addition of a new attribute (changes) to cubes, which required changing a lot of objects in the earlier scenario is very simple now. The only place where the attribute need to be added is in the source DSO (Master DSO) and in the composite provider Maintenance).

  • 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.


With the new Composite provider and SAP BW on HANA there are numerous capabilities that can be explored to save time and cost for your company. In each case it is good to evaluate these possibilities and make a wise decision.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Ashok Babu Kumili

    Hello Srinivasan,

    Perfect document to understand the basic concepts of  “Composite Info provider”. Very nicely written articles. Thanks for the examples used.. I learnt the key views. It has been summarized very nicely

  2. abilash n

    Very nicely presented blog . Thanks for sharing….

    I had bookmarked to refer while thinking about Composite provider πŸ˜‰ ..

  3. Ramakrishnan Azhagappan

    Hello Ram,

    This is an excellent content.

    I Think there is a typo error please correct if am wrong. Instead of “Sales DSO” it should be “Composite Provider”. Also I could see the TCode for creating a Composite Provider RSLIMOBW here, but in it is RSLIMO. Is these transactions depicts the same or what. Thanks for the clarification.


    1. Pradeep R

      RSLIMO is used to create Rapid Prototype models to combine Transient Providers based on Analytic Index or HANA models.

      RSLIMOBW is used to create JOINS between BW Infoproviders to develop new scenarios which otherwise is very expensive with standard methods using Infoset or Multiprovider.

    1. Pradeep R

      Valid question. One that came to my mind whilst reading this document. However I would believe you could use InfoObjects, to replace the master data DSO’s, as a Infoobject is a BW Infoprovider too.

      I am thinking, maybe in this example a DSO is used to include Calendar month (derived from ERDAT) in the Key Fields to maintain history, which otherwise is not posssible with an InfoObject which has an OVERWRITE behaviour.

      Correct me if I am wrong.

  4. Pradeep R

    A very informative article and excellent example to demonstrate this concept.

    I have a question: In the above example – what type of link is City, Customer-Segment, Customer Sub-Segment from the Customer master DSO and Product Sub-Category from the Product master DSO to the Sales data? Is it a Join ?

  5. Antony Jerald J


    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?


    Antony Jerald.

  6. Sandy Assum

    I have created my Local Composite Provider but I do not see it is BEX Query Designer. Is there a setting to make the Composite Provider visible in BEX Query Designer?



  7. Martin Kreitlein

    Hi Ramachandran,

    very helpful document!

    Could you please let me know on which document your Statement is based?

    “SAP Still suggests the usage of Multiprovider in case your requirement is just to use Unions.”

    Can you share a link?

    Thanks, Martin

  8. Daniel Ray

    Hi Ramachandran,

    Thanks for the nice article. However, I have a doubt on the same lookup strategy. For example while loading Material MD to DSO, we have one field called Vendor, where each of the material’s will be looked up on the PO DSO, and it has to take all the material & Vendor & PO in that PO DSO, sort out all the records for that material for the past 1 year and take the latest vendor from the result after arranging the result in the descending order of the PO created date. How can we achieve this requirement while pushing it to a composite infoprovider ? Please advice. Appreciate it.

    Thank You


  9. Daniel Ray


    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. We just need to enable the NAV of the customer MD in the infocube and MP. Is my understanding wrong ? Please advise.



    1. Suresh Vemulapalli

      Hi Daniel,

      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!!!

      thanks, Suresh V


Leave a Reply