Select language:
Entering content frame!--a11y-->

Object documentation MultiProviders 


A MultiProvider is a type of InfoProvider that combines data from a number of InfoProviders and makes it available for reporting purposes. The MultiProvider does not itself contain any data. Its data comes entirely from the InfoProviders on which it is based. These InfoProviders are connected to one another by a union operation. 

InfoProviders and MultiProviders are the objects or views that are relevant for reporting.


A MultiProvider allows you to run reports using several InfoProviders.


InfoCube and InfoCube: You have an InfoProvider with actual data for a logically closed business area and an equivalent InfoProvider with planned data. You can combine the two InfoProviders into one MultiProvider so that you can compare the actual data with the planned data in a query. In BW releases 2.0B/2.1C, this combination of two InfoCubes is still called a MultiCube.

InfoCube and InfoObject: You have an InfoCube with your products and sales. You combine this InfoCube with the 0MATERIAL InfoObject. This allows you to display any "slow-moving items", since products that do not result in sales are also displayed. For a detailed description of the procedure, refer to the Slow Moving Items Scenario.


A MultiProvider can consist of different combinations of the following InfoProviders: InfoCube, ODS object, InfoObject, and InfoSet.

This graphic is explained in the accompanying text

A union operation is used to combine the data from these objects into a MultiProvider. Here, the system constructs the union set of the data sets involved. In other words, all values of these data sets are combined. As a comparison: InfoSets are created using joins. These joins only combine values that appear in both tables. In contrast to a union, joins form the intersection of the tables

As a comparison, see also InfoSet.

In a MultiProvider, every characteristic in each of the InfoProviders involved must correspond to exactly one characteristic or navigation attribute (wherever these are available). If it is not clear, at the MultiProvider definition stage, you have to specify to which InfoObject you want to assign the characteristic of the MultiProvider.


The MultiProvider contains the characteristic 0COUNTRY and an InfoProvider contains the characteristic 0COUNTRY as well as the navigation attribute 0CUSTOMER__0COUNTRY. In this case, select exactly one of these InfoObjects in the assignment table.

Select a key figure contained in a MultiProvider from at least one of the InfoProviders involved. In general, exactly one of the InfoProviders provides the key figure. However, there are cases where it is better to select from more than one InfoProvider:


If the 0SALES key figure is stored redundantly in more than one InfoProvider (meaning that it is contained completely in all value combinations of the characteristics) you must select from exactly one of the InfoProviders involved (otherwise the duplicated value is added incorrectly in the MultiProvider).

However, if 0SALES is stored as an actual value in one InfoProvider and as a planned value in another InfoProvider so that there is no overlap between the data records (in other words, sales are divided separately between several InfoProviders) then it makes sense to make a selection across several InfoProviders.

You can divide MultiProviders into the following categories:


  1.  Homogenous MultiProviders:

These consist of technically identical InfoProviders, such as InfoCubes with exactly the same characteristics and key figures, where one InfoCube contains the data for 2001, for example, and a second InfoCube contains data for 2002. Homogenous MultiProviders can be used to partition on the modeling level of the InfoProvider.

  2.  Heterogeneous MultiProviders:

These are made up of InfoProviders that only have a certain number of characteristics and key figures in common.  Heterogeneous MultiProviders can be used to simplify the modeling of scenarios by dividing them into sub-scenarios. Each sub-scenario is represented by its own InfoProvider. An example is a sales scenario made up of the sub-processes order, delivery and payment. Each of these sub-processes has its own (private) InfoObjects (delivery location and invoice number, for example) as well as a number of cross-process objects (such as customer or order number). It makes sense here to model each sub-process in its own InfoProvider and then combine these InfoProviders into a MultiProvider. It is possible to:

¡  model all sub-scenarios in an InfoProvider or

¡  create an InfoProvider for each sub-scenario, and then combine these InfoProviders into a single MultiProvider.

The latter option usually simplifies the modeling process and can improve system performance when loading and reading data (see link below: Executing MultiProvider Queries in Parallel).


MultiProviders only exist as a logical definition. The data continues to be stored in the InfoProviders on which the MultiProvider is based.

A query based on a MultiProvider is divided internally into subqueries. There is a subquery for each InfoProvider included in the MultiProvider. These subqueries are usually processed in parallel.

The following sections contain more detailed information:

Dividing a MultiProvider Query into Subqueries

Parallelization of Subqueries Versus Sequential Processing


Technically there are no restrictions with regard to the number of InfoProviders that can be included in a MultiProvider. However, SAP recommends that you include no more than 10 InfoProviders in a single MultiProvider, because any more than this number and splitting the MultiProvider queries and reconstructing the results from the individual InfoProviders takes a substantial amount of time and is generally counterproductive. Modeling these types of MultiProviders is also highly complex.

MultiProviders with Non-Cumulative Key Figures

You should not use more than one non-cumulative InfoCube (InfoCube with at least one non-cumulative key figure) because this could lead to incorrect query results.


Leaving content frame