MultiProvider

Introduction:

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.

Structure:

A MultiProvider can consist of different combinations of the following
InfoProviders: 

InfoCube, ODS object, InfoObject, and InfoSet.

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.

Characteristics

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 Multi Provider 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.

 Key Figures

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.

Categories

•  Homogenous MultiProviders

•  Heterogeneous MultiProviders

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.

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 subprocesses 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 crossprocess objects (such as customer or order number).

It makes sense here to model each subprocess 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.

 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 subqueries. There is a subquery for each InfoProvider included in the MultiProvider.

These subqueries are usually processed in parallel. A query based on a
MultiProvider is divided internally into sub-queries. A sub-query is generated for each InfoProvider associated with the MultiProvider.

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 and InfoSets

An InfoProvider is a BI Content object for which BI queries can be created or
executed in the BEx.InfoProviders are the objects or views that are relevant for reporting. 

A MultiProvider as well as an InfoSet do not physically store data, but display logical views.

A MultiProvider builds up a data union of basic InfoProviders. The complete data of all basic InfoProviders are available for reporting. A MultiProvider is interpreted at runtime as independent BI queries on each basic InfoProvider where the results are merged into a single result set.

An InfoSet builds up a data join of basic InfoProviders. The valid combination of records from the basic InfoProviders is determined by the join condition of the InfoSet.