MultiProviders 
Definition
Use
A MultiProvider allows you to run reports based on several InfoProviders.
See the following examples:
Example: List of Slow-Moving Items
Structure
A MultiProvider can consist of different combinations of the following InfoProviders: InfoCube, DataStore object, InfoObject, InfoSet, VirtualProvider, and aggregation level.
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 the 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 InfoSet.
In a MultiProvider, every characteristic in each of the InfoProviders involved must correspond to exactly one characteristic or navigation attribute (where these are available). If it is not clear, you have to specify to which InfoObject you want to assign the characteristic of the MultiProvider at the MultiProvider definition stage.
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 included. In general, one of the InfoProviders provides the key figure. However, there are cases in which it is better to select the key figure 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 it from just 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 and there is no overlap between the data records (in other words, sales are divided separately between several InfoProviders), it is more useful to make a selection across several InfoProviders.
Integration
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 sub-queries. There is a sub-query for each InfoProvider included in the MultiProvider. These sub-queries are usually processed in parallel.
The following sections contain more detailed information:
Dividing a MultiProvider Query into Sub-Queries
Technically there are no restrictions with regard to the number of InfoProviders that can be included in a MultiProvider. However, we recommend that you include no more than 10 InfoProviders in a single MultiProvider, otherwise splitting the MultiProvider queries and reconstructing the results for the individual InfoProviders takes a substantial amount of time and is generally counterproductive. Modeling MultiProviders with more than 10 InfoProviders is also highly complex.
See also:
Recommendations for
Modeling MultiProviders