MULTIPROVIDERS

A MultiProvider is a special InfoProvider that combines data from several InfoProviders, providing it
for reporting. The MultiProvider itself does not contain any data. Its data comes exclusively from the
InfoProviders on which it is based. This aspect of MultiProviders makes them very similar to InfoSets;
however, the big difference between InfoSets and MultiProviders is in the technical way the tables
are linked. InfoSets link the underlying providers with database joins, and MultiProviders use a
technically different method called unions.
A MultiProvider can be made up of various combinations of the following InfoProviders:

InfoCubes (both Standard and Virtual Provider)

DataStore Objects

InfoObjects

InfoSets

Aggregation levels (slices of a InfoCube to support BI Integrated Planning)

The recommended number of InfoProviders in a MultiProvider is no more than 10.

ADVANTAGES OF THE MULTIPROVIDER

Simplified design: The MultiProvider concept provides you with advanced analysis options,
without you having to fill new and extremely large InfoCubes with data. You can construct
simpler BasicCubes with smaller tables and with less redundancy

No additional storage

Performance gains though parallel execution of sub queries

"Logical Partitioning" is possible: For e.g. according to year, region, plan/actual etc.
("partitioning" can also relate to the concept of splitting cubes and DataStore Objects into smaller
ones, perhaps by limited the number of years in each or physical database partitioning of the fact
table. This is covered in more detail in SAP course BW360)

DISADVANTAGES OF THE MULTIPROVIDER:

More Administrative work required

Aggregates are not possible

PARALLELIZATION OF SUB-QUERIES:
A query on a MultiProvider is internally spit into sub-queries. There is one sub-query for each
InfoProvider included in the MultiProvider. The resulting sub-queries are processed in parallel by
default. This means that the resulting sub-queries (normally one for each sub-InfoProvider) are
deposited in parallel. The results of these sub-queries are collected at one synchronization point and
consolidated to the overall result

SEQUENTIAL PROCESSING:
For sequential processing, the sub-queries are deposited one by one. In this case, an interim result is
forwarded immediately to the BW OLAP engine. This has the advantage of avoiding an overall result
that may be too large in the main memory of the application server. However, there may be a loss
in performance as a result.

IN THE FOLLOWING CASES, THE SYSTEM CHOOSES SEQUENTIAL (NOT PARALLEL) PROCESSING:

The RSADMIN table contains an entry with the value NOPARALLEL (in the VALUE column).

The MultiProvider query runs in a background process.

The MultiProvider query was started from the query monitor (transaction RSRT) using
different debug options (displaying SQL queries, displaying the execution plans among
others).

The query concerns non-cumulative key figures

At the time of execution, there are not sufficient free dialog processes; these are necessary
for parallel processing.

The result of the MultiProvider query should be saved in one file or one table.

IN THE FOLLOWING CASE, THE PARALLEL PROCESSING IS TERMINATED AND IS

AUTOMATICALLY RESTARTED AND PROCESSED SEQUENTIALLY:
If the interim result of a MultiProvider query that was started in parallel is too large (more than
30,000 records), the parallel processing terminated to prevent a memory overflow. Then system
automatically continues to process the query sequentially.

AVOID THE TERMINATION OF PARALLEL PROCESSING:

If the parallel processing terminates, there will be a loss in performance. If you want to improve the
performance of a query on a MultiProvider, you can first check how the sub-queries are processed.
For this purpose, execute the query from the query monitor (transaction RSRT) by choosing the
option "Execute + Debug". Choose the option "MultiProvider Explain". The screen that displays the
query result among other information also displays messages in the upper part of the screen.
Message DBMAN 146 indicates that when this query was executed, the parallel processing was
terminated and was restarted with sequential processing. In such cases, we recommend that you
deactivate the parallel processing for the MultiProvider. This function is available in the Query
monitor by choosing "Query Properties". By selecting the "Not Using Parallel Processing"
indicator, the RSADMIN table for this MultiProvider receives the value NOPARALLEL in the VALUE
column. The sub-queries for this MultiProvider are then processed sequentially from the start so as

to avoid the loss of performance caused by the termination. However, this has the result that all
queries for this MultiProvider are processed sequentially, even those that could be successfully
processed in parallel. You can avoid this disadvantage by using a workaround: Create a copy of the
MultiProvider and run the queries that terminate during parallel processing and deactivate parallel
processing for this MultiProvider copy. The original MultiProvider can keep running the other queries
that can be successfully processed in parallel.

RECOMMENDATIONS FOR MODELLING MULTIPROVIDERS:

Model the MultiProvider in such a way that the characteristics that you want to use in
reporting are available in all the InfoProviders involved.

Use the MultiProvider to keep the size of the InfoProvider small.

Ensure that only relevant data is read when you execute the query by:

Using constants when you model the InfoProviders involved

Modelling the InfoProviders involved with different key figures

Including the 0INFOPROV characteristic when you design the query on the MultiProvider to
enable you to set a filter for one of the InfoProviders.

Use MultiProviders to define a reporting layer. In this way, it is easier to expand reporting
scenarios. If an InfoProvider is subsequently added to a MultiProvider, the technical name of
the previously defined query remains the same.

Do not use more than one InfoCube with non-cumulative key figures in a MultiProvider,
otherwise the numbers in the query may be incorrect.

Do not make any calculations before the aggregation as this may cause incorrect query
results.

Do not combine any InfoProviders that have very heterogeneous data models in one
MultiProvider. Instead, in such a case, use the report-report interface between queries that
are defined on the InfoProviders.

Do not use parts of compound characteristics in InfoProviders. For more information, refer to
SAP Note 702542 on SAP Service Marketplace. Performance of MultiProviders

Use no more than 10 InfoProviders to define a MultiProvider. If more InfoProviders are read
at the same time using a query, the results calculation takes too long.

If a MultiProvider contains an InfoCube with non-cumulative key figures, all sub-queries are
processed sequentially.

The tools of the OLAP for performance optimization (such as caching and aggregation) can
be used for a MultiProvider only if all InfoProviders involved support these tools.

Example: Slow-Moving Item List

1. In the Query Designer, select your InfoProvider (that contains the characteristic 0MATERIAL).
2. Define a query in accordance with your requirements (for example, include the key figure Sales
in the structure).
3. For the characteristic 0MATERIAL, set the Access Type for Result Values property to Master
Data.
4. Save the query and execute it.
The system displays all values, including values for materials that have not been purchased.

If you want to display only the list of slow-moving items without the products that sell well,
proceed as follows:
1. In the Query Designer, define a condition for the Sales key figure in the structure (you can also
assign this to InfoObject 0MATERIAL, but this step is optional) to evaluate sales = 0.
2. Save the query and execute it.
The system displays all materials that have not sold

If you want to display a list of products that do not sell well, proceed as follows:
1. In the Query Designer, define a condition for the Sales key figure in the structure (you can also
assign this to InfoObject 0MATERIAL, but this step is optional). Specify a value that you want to use
as the upper limit for a bad sale.
2. Save the query and execute it.
The system displays all materials that have not sold or have sold badly.