Multi Provider and Info Sets

Multi Provider and Info Sets in SAP BI

Topic Overview

In this Topic, you will learn about how to work with MultiProviders and get a high-level overview of BI InfoSets.

MultiProviders and InfoSets enable you to combine other InfoProviders into

a logical group. In turn, this group provides a semantic layer on which to base reporting. As both MultiProviders and BI InfoSets do not store the data persistently, the data is only collected when the queries are executed. The difference between MultiProvider and InfoSets

Business Example

InfoProviders exist for plan and actual data of cost center transactions. This separate plan-vs.-actual design supports BI Integrated Planning with one dedicated cube, and to support the loading of actual data from SAP source system. Your users now have requirements for plan and actualcomparison reports. You want to investigate a MultiProvider to solve this need.

MultiProviders

A MultiProvider is a special InfoProvider that combines data from several InfoProviders, providing it for reporting. The MultiProvider itself (like InfoSets and Virtual Providers) does not contain any data. Its data comes exclusively from the InfoProviders on which it is based. A MultiProvider can be made up of various combinations of the following InfoProviders:

• InfoCubes
•  DataStore objects
•  InfoObjects
• InfoSets
• Aggregation levels (slices of a InfoCube to support BI Integrated Planning)

Use

A BEx query can only be written against a single InfoProvider. A MultiProvider is a single InfoProvider to a query but through it, multiple providers can be indirectly accessed. Our example includes two InfoCubes (plan and actual). We have an InfoProvider with actual data for a logically self-contained business area, and a corresponding nfoProvider with plan data. You can combine the two InfoProviders into a MultiProvider to compare actual and plan data in a query. Another example might be an InfoCube and an InfoObject: You have an InfoCube with your products and revenues. Combine it with the InfoObject PROD (product). The result is that you can now display slow-moving items, since products that generate no revenue are also displayed.

MultiProvider Concept

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.
• Individual InfoCubes and DataStore Objects can be partitioned separately*Performance gains though parallel execution of subqueries

Note: *.partitioned separately. can either relate to the concept of splitting cubes and DataStore Objects into smaller ones, perhaps by limited the number of years in each or physical databasepartitioning of the fact table. This is covered in more detail in SAP course BW360.

Integration

MultiProvider only exists as a logical definition. The data is still stored in the InfoProviders on which they are based. This aspect of MultiProvider makes them very similar to InfoSets; however, the big difference between InfoSets and MultipProvider 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. These differences result in different result sets and, therefore different end uses for MultiProvider versus InfoSets.

MultiProviders Are Unions of Providers

Each characteristic of a MultiProvider must match precisely one characteristic or navigation attribute in each InfoProvider involved. As shown above, when this does not happen, a normally unwanted # (unassigned) appears.

MultiProvider: Our Example

A cost center plan and a cost center actual InfoCube, combined into a plan/actual MultiProvider, is a common design to support cost center planning and performance to plan reporting. Our InfoCubes are identical, but one is populated with Value Type = Plan data and the other with Value type = Actual data. The architecture is shown below. You can define a MultiProvider that includes these common characteristics as well as the key figures of the InfoCubes involved. The MultiProvider can then be used in queries.

Note: There are much other BI architecture involving MultiProviders, some performance driven. These are discussed in BW360

Example: Plan And Actual Cost Center Transactions

A query executed using a MultiProvider is divided across the involved InfoProviders with several select statements, which can be processed in parallel. This improves system performance. The OLAP processor presents the combination of the results from all individual select statements as the query result.

MultiProvider Queries

Designing a MultiProvider in BI

In the initial screen in the process of designing a MultiProvider, the individual providers that feed   the MultiProvider are selected. These can include any InfoProvider, as well as a new aggregation-level provider in support of BI Integrated Planning.

Selecting Relevant InfoProviders for a MultiProvider

As of SAP Net Weaver 7.0, the design GUIs for all the providers look and feel very similar.There are, however, a few critical differences in the MultiProvider GUI that you should be aware of. First, the superset of InfoObjects eligible for inclusion into the DIMs of your MultiProvider is limited to those that are in the included underlying InfoProviders. Second, settings must be made for how each InfoObject from the individual InfoProvider reacts with the MultiProvider.

MultiProvider Design GUI

Due to the way unions work, it makes sense to only include characteristics ]in the MultiProvider that appear in the source InfoProviders. In some cases,exact matches do not exist between the characteristics in the dimension tablesor the active table of the DataSource Object. In this case, you might source theunderlying characteristic from a navigational attribute. You must, however, be aware that you may not be merging apples with apples. For example a Country from one InfoCube is not the exact same thing as Sold_To_Country from an other InfoCube. The GUI to identify characteristics in the MultiProvider is accessedwith a special icon, shown below.

Characteristic Identification in a MultiProvider

Note: The system can propose characteristic identification (above) and key figure selection (below) using the buttons at the bottom of the appropriate screens.A key figure contained in a MultiProvider must be selected from at least one of theInfoProviders involved. Generally, the key figure is supplied from precisely oneInfoProvider. If it supplied from more than one source, it is additive, and usually gives inflated and inaccurate results.

Note: There are some situations in which it makes sense to select

from more than one InfoProvider. It is desirable to source the key figure from more than one underlying InfoProvider in cases where a key figure, for example 0Amount (Amount), is stored redundantly in several InfoProviders but the business meaning of the data is different. Technically, this means it comes from disjointed record sets that do notoverlap. For example one InfoCube has US amounts only and the other has DE amounts. In our example, one InfoCube has plan amount and one has actual (nooverlap). In our special case, we also need to make sure the query is designed to never add plan and actual. Nonetheless, we need both to be

fed to the MultiProvider.

Key Figure Selection

InfoSets and Their Business Purpose

BI InfoSets are objects that serve to collect and join any of the targets into a logical view that can be collected and used as the provider to queries. They are, in many ways, analogous to database views, which collect various tables for subsequent access by a programmer.

BI InfoSets: Definition and Features

The GUI (shown below) to build InfoSets is much like Microsoft Access. BI InfoProviders can added to the set by drag and drop, then you would link the objects with a connector at the fields used in the join. You can decide which InfoObjects can be used in subsequent queries on the InfoSet, by using the appropriate checkbox in the GUI. In addition, both inner and outer join types can be configured.

InfoSet Maintenance GUI

Note: The concept of InfoSet joins involving time-dependant objects,know as temporal joins, is discussed in detail in SAP course BW330.However, you should at least know when the use of these objects is appropriate. As such, please refer to the figure below.

Note: The concept of InfoSet joins involving time-dependant objects,know as temporal joins, is discussed in detail in SAP course BW330.However, you should at least know when the use of these objects is appropriate. As such, please refer to the figure below.

Business Scenarios for BI InfoSets

As mentioned in the preceding figure, there are differences between joins and

unions. InfoSets do joins, and MultiProviders do unions. When it comes to joins,

there are two types supported by InfoSets: inner (equal) joins and outer joins.

Both types are similar, as shown below, and both types normally provide the

outcome that your end user expects. On the other hand, misuse of MultiProviders

(unions) can yield very unexpected results.

Defining a MultiProvider

Exercise Objectives

After completing this exercise, you will be able to:

• Combine data from different InfoCubes to compare related information (for example, plan and actual data to support BI Integrated Planning)

Business Example

You have filled your Cost Center InfoCube with actual information. Additionally, there is an InfoProvider for the Cost Center plan data in your enterprise. There are complex reporting demands for which you need to combine data from both of these InfoCubes. Your task is to carry out these complex requests using a MultiProvider.

Note: You will build your MultiProvider with InfoCubes supplied and populated with data by your instructor.

Task 1: Define a MultiProvider

Using MultiProviders accelerates the reporting process in your enterprise and enables you to report using data from combined sources. Create a MultiProvider that combines cost center actual data with plan data.

• In your InfoArea Group ## create a new MultiProvider with technical name T_MULTI##and description GR## MultiProvider Actual/Plan .
• In the next window, you can select the objects involved in the MultiProvider.From the list of InfoCubes, select T_310ACT (Actual Data) and T_310PLAN (Plan Data). Confirm your selection.
• The screen for maintaining the MultiProvider now appears. In the template on the left, you can see all dimensions, characteristics, and key figures of the InfoCubes T_310ACT and T_310PLAN. Use the InfoCube T_310ACT as template for your Multiprovider. Move the dimensions Cost Center, Cost Element, and Val.Type/Version to the MultiProvider structure. You may have to switch to Change mode of MultiProvider maintenance. All the characteristics of the involved dimensions will also be transferred. Additionally delete the Dimension1 dimension from the MultiProvider.
• Transfer the following time characteristics of the InfoCube T_310ACT tothe MultiProvider's Time dimension.