Complex Aggregation Level in BI

The following examples show:

· how the system embeds data records from the InfoProviders contained in a MultiProvider in the MultiProvider.

· how the system writes new or changed data records of the MultiProvider to those included in this InfoProvider

Example: Characteristic Product in MultiProvider MP

Assuming there is a MultiProvider MP, that includes the actual-InfoCube IC_A and the plan InfoCube IC_P. The actual InfoCube IC_A includes the characteristics product, product group, version and year, as well as the key figure profit. The plan InfoCube IC_P includes the same objects with the exception of the characteristic, product. An aggregation level ALVL_MP is defined on the MultiProvider MP, which includes all characteristics of the MultiProvider.

The following two data records for the underlying InfoProvider yields the following data records in the MultiProvider:

Data Record in Actual InfoCube IC_A

Product	Product Group	Version	Year	Profit
P1	PG1	V1	2005	10

Data Record in Plan InfoCube IC_P

Product Group	Version	Year	Profit
PG1	V1	2005	30

Data Records in MultiProvider MP (or ALVL_MP)

InfoProviders	Product	Product Group	Version	Year	Profit
IC_A	P1	PG1	V1	2005	10
IC_P	#	PG1	V1	2005	30

The data records in the MultiProvider MP are - from a technical viewpoint - generated using a UNION operation from the records of the underlying InfoProvider. The InfoProvider is always included so that the "origin" of the respective data record is clear on the level of a data record.

If new data records are generated during manual planning or using the planning functions, the system ensure that every record of the MultiProvider can be assigned back to the InfoProviders contained in the MultiProvider uniquely and without loss of information.

The following table shows an example of a data record that could not be assigned.

Example of a Record in the MultiProvider MP that could not be assigned

InfoProviders	Product	Product Group	Version	Year	Profit
IC_P	P1	PG1	V1	2005	43

The data record is part of the InfoProvider IC_P. However, this InfoProvider does not provide a product in the MultiProvider. This means that P1 is not permitted.

In manual planning, data cells that could lead to this type of record are not input ready. In planning functions, the system ensure that these types of data records cannot be saved.

The same situation can occur for key figures in complex aggregation levels. If K is a key figure in MultiProvider MP that is supplied from the actual InfoCube IC_A, but not by the plan InfoCube IC_P, this key figure is always initial in a data record in the MultiProvider MP with the InfoProvider IC_P. This value also cannot be changed.

Simple Aggregation Level in BI

The following example demonstrates how the system works when a key figure value is changed (manually or automatically).

Assuming there is an InfoCube IC with the characteristics product, product group, version and year, along with the key figure revenue. The aggregation level ALVL includes the same objects with the exception of the characteristic, product.

Fact Table of the InfoCube IC

Product	Product Group	Version	Year	Revenue
P1	PG1	V1	2005	10
P2	PG1	V1	2005	20
P3	PG2	V1	2005	42

The key figure revenue includes the database aggregation SUM. Accordingly, we get the following result when the transaction data for the aggregation level ALVL is read from the database without restriction:

Aggregation Level ALVL (Key Figure Aggregated on the Database Level)

Product Group	Version	Year	Revenue
PG1	V1	2005	30
PG2	V1	2005	42

If you have changed the revenue from 30 to 40 and is saved as a new value, the system writes a new record with the difference of the key figure value to the fact table of the InfoCube IC:

Delta Record in the Fact Table of the InfoCube IC

Product	Product Group	Version	Year	Revenue
#	PG1	V1	2005	10

In this type of delta records, all characteristics of the InfoCube that are not included in the aggregation level get the initial value (not assigned: #). (Here we are assuming that no derivations were used. For more information on this concept,

Aggregation Level in BI

Use

Aggregation levels are used as InfoProviders for planning: with an aggregation level, you model levels whose data can be changed manually using input-ready queries or automatically using planning functions.

An aggregation level is set using a set of characteristics and key figures from the underlying InfoProvider. The key figures included in the aggregation level are aggregated using the characteristics that are not included in the aggregation level.

In the simplest case, an aggregation level is located on a real-time enabled InfoCube. For more information on the functioning principle of aggregation and saving the changed data records for an aggregation level by means of a simple example, see Simple Aggregation Level.

Aggregation levels can also be created on MultiProviders.

Integration

You can create multiple aggregation levels for an InfoProvider. Use the Planning Modeler or the Planning Wizard for this.

In the Modeling functional area of the Data Warehousing Workbench, the system also displays the aggregation levels (symbol ) and the underlying InfoProviders in the InfoProvider overview. When you double-click on the aggregation level, you can branch to the Planning Modeler and edit the selected aggregation level.

Prerequisites

In the Planning Modeler or Planning Wizard you have selected (and if necessary edited) an InfoProvider to act as the basis of the aggregation level. This InfoProvider includes at least one real-time-enabled InfoCube. For more information about the corresponding processing step, see InfoProvider.

Features

Simple Aggregation Level

A real-time enabled InfoCube is the basis of a simple aggregation level. You can find a simple example under Simple Aggregation Level.

Complex Aggregation Level

A MultiProvider that includes at least one real-time enabled InfoCube, but no simple aggregation level, is the basis of a complex aggregation level.

You want to copy current data from an actual InfoCube to a plan InfoCube with a planning function of type Copy. To do this, you use an aggregation level based on a MultiProvider that includes the plan and actual InfoCubes.

Aggregation levels, like MultiProviders, cannot be nested.

With a complex aggregation level, note how data records from the InfoProviders included in the MultiProviders are embedded in the MultiProviders (and thus also the aggregation levels) and how the system writes changes to data records of the aggregation level back to the InfoProviders included in the MultiProviders. For more information on these MultiProvider-specific features - with simple examples - see Complex Aggregation Levels.

The following conditions apply to both types of aggregation level:

● At least one key figure and one characteristic have to be included in the aggregation level.

● The key figures used have to have the database aggregations SUM, MIN or MAX. With MIN or MAX, key figure values can only be displayed. They cannot be changed using manual planning or planning functions.

● For key figures of type date or time, only the data type ‘DEC’ is supported.

● Referencing key figures (and thus also non-cumulative key figures or elimination of internal business volume) are not supported in aggregation layers.

● If a characteristic is compounded and used in an aggregation level, the aggregation level must also contain all compounding "parent" characteristics.

● If a key figure is used in an aggregation level and does not have a fixed unit of measure or currency, the aggregation level must contain the associated characteristic for the unit.

● If a key figure with exception aggregation is used in an aggregation level, the aggregation level must also contain the characteristic for exception aggregation if it occurs in the underlying InfoProvider.

● The aggregation level inherits a navigation attribute from the underlying InfoProvider if it includes the basic characteristic of the navigation attribute. Note that the navigation attribute for an aggregation level is not visible in the Planning Modeler. It is only visible in the Query Designer.

● An aggregation level cannot be created on MultiProviders if a characteristic of an InfoProvider contained in the MultiProvider supplies two different characteristics in the MultiProvider.

● If a characteristic on the InfoProvider that serves as the basis for an aggregation level is constant, this characteristic has to be included in the aggregation level.

Activities

You are in the Aggregation Levels tab page of the Planning Modeler. In the Aggregation Level Selection screen area, you can create, copy, delete, change, check, save and activate aggregation levels.

Creating Aggregation Levels

...

1. To create an aggregation level, choose Create. The Create Aggregation Level dialog box appears.

2. Enter a technical name and a description.

3. Choose the appropriate InfoProvider. If you do not enter a search term and choose Start, the system shows all the InfoProviders available in your system.

4. Choose Transfer. In the lower screen area of the Planning Modeler, the system displays an overview of all InfoObjects of the InfoProvider.

5. Choose the InfoObjects that are to be included in the aggregation level. Note the conditions listed above.

6. To save the definition of the aggregation level, choose Save.

7. To check the definition of the aggregation level in view of consistency, choose Check.

When you choose Check, the system tries to complete necessary objects, such as superordinate characteristics from compounded characteristics.

8. If the definition is consistent, choose Activate. Once it has been activated, the aggregation level is ready for use.

Changing Aggregation Levels

...

1. To change an aggregation level, choose Change. In the lower screen area of the Planning Modeler, the system displays an overview of all InfoObjects of the InfoProvider used in the aggregation level. The InfoObjects selection list allows you to display all InfoObjects for the InfoProvider, only those used in the aggregation level, or those not used in the aggregation level.

2. Change the definition as required.

3. Save, check and activate the changed definition.

Actual and Plan Data in One InfoCube in BI

In the simplest case, you have the actual data and the plan data in a real-time InfoCube. You define an aggregation level based on this InfoCube.

The following graphic illustrates this model:

A model of this type allows you to analyze data and enter plan data for one InfoProvider using one query. You also have the option of using planning functions.

You have to use characteristic 0VERSION (or an equivalent characteristic) in the filter to distinguish between the dimensions of the InfoCube that you want to evaluate for reporting and planning, and the dimensions that you want to evaluate using planning functions.

This modeling scenario has the following disadvantages:

● A large amount of data is contained in one InfoCube.

● You cannot load actual and plan data in parallel. In the InfoCube, you can only set the mode for entering plan data or the mode for loading data manually (see Real-Time InfoCubessap).

Due to the manual maintenance effort involved and the corresponding downtime of the InfoCube, we do not recommend this model.

Actual and Plan Data in Different InfoCubes

In most cases it is useful to have the actual data in an InfoCube and the plan data in a separate real-time InfoCube.

● The InfoCubes contain less data.

● If the real-time InfoCube only contains plan data, it is not necessary to switch manually to the data load mode.

However, this model is more complex.

There are various options for filling the plan InfoCube with data.

Use Copy Function to Copy Actual Data to Plan InfoCube

You can use the standard Copy function type to copy data from the actual InfoCube into the plan InfoCube. In this case you require an additional MultiProvider. You define the aggregation levels on the basis of this MultiProvider.

The following graphic illustrates this model:

If you use a planning function to copy the data you can either start this function online from the plan query or include the copy function in a process chain in a planning sequence (see Planning Sequences).

With this type of model the system supports a characteristic relationship check.

Use Data Transfer Process to Load Plan Data

You can use a data transfer process to load data from the actual InfoCube into the plan InfoCube. In this case, you define the aggregation level either on the plan InfoCube or on the basis of a MultiProvider that contains the actual InfoCube and the plan InfoCube.

The following graphic illustrates this model:

Compared with using a planning function to copy data, a data transfer process has the following advantages: It is quicker and it supports delta handling. You can also include a DTP in a process chain. A DTP allows you to use the transformation functions (see Transformation).

With this type of model the system does not support a characteristic relationship check.

Complex Planning Integration

The following example illustrates how you integrate planning-specific InfoProviders for a sales, production, and profit and loss planning into one complex planning application. Changes made manually to the Sales planning should automatically impact on the Production and Profit and Loss planning. You achieve this by using planning functions.

The following graphic illustrates this model:

If manual changes are made to sales planning through the input-ready Sales query, these changes are also visible in the Cross query. The Cross query is defined on aggregation level Cross ALVL which also contains the sales InfoCube.

The customer has implemented planning function Simulate which specifies the relationship between the different key figures in the Sales, Production, and Profit and Loss InfoCubes. This function copies any changes to sales planning to the Production and Profit and Loss planning.

A prerequisite for a complex scenario of this type is that all the InfoCubes contain some common characteristics on which you can define an aggregation level.

Overview of InfoProvider Modeling

InfoProvider	Characteristic	Key Figure
InfoCube 1	CALYEAR, CALMONTH, VERSION, CUSTOMER, PRODUCTGROUP, PRODUCT	SALNET, AMOUNT
InfoCube 2	CALYEAR, CALMONTH, VERSION, PRODUCT	PRODAMOUNT, PRODCOSTS
InfoCube 3	CALYEAR, CALMONTH, VERSION	NETCOSTS, NETREV
Cross ALVL	CALYEAR, CALMONTH, VERSION, 0INFOPROV	SALNET, AMOUNT, PRODAMOUNT, PRODCOSTS, NETCOSTS, NETREV

Planning Automation

You can integrate process chains in planning sequences. This allows you to schedule the execution of planning sequences together with data load processes. You can use BI information broadcasting to automatically send alerts or updated versions of the plan query.

The following graphic illustrates this model:

Modeling Planning Scenarios in BI

Purpose

To model your planning scenarios, BI Integrated Planning provides you with the Planning Modeler and the Planning Wizard.

Both tools are Web dynpro-based applications that have to be installed on the SAP J2EE Server. You can allow access to these applications using links or iViews in the portal. It is not necessary, therefore, to install the SAP front end locally.

Planning Modeler

You use the planning modeler to model, manage, and test all the metadata that belongs to a planning scenario.

Interface

The tab pages InfoProvider, Aggregation Levels, Filters, Planning Functions and Planning Sequences are structured in such a way that in the upper part of the screen you have the option to search using objects that can be selected in the system, and a table which displays the results of the search. If you select or create an entry, in the lower part of the screen the system displays the properties of the respective object and provides the user with options to edit the object.

You can modify the interface as required by hiding or showing the subareas.

To modify the table layout, you can:

● Choose Filter On and enter descriptions in the input-ready rows by which the table columns are filtered.

● Choose Settings and select table columns and define the sequence and the general settings for the table layout. When you upgrade, it cannot be guaranteed that the user-specific settings for the table views in the planning modeler will be retained, or that you will be able to reuse them if you have saved them locally.

Functions

The planning modeler provides the following functions:

...

● InfoProvider selection, characteristic relationship and data slice assignments, selection, modification, and creation of InfoProvider of type aggregation level

You define the corresponding settings on the InfoProvider und Aggregation Levels tab pages in the planning modeler.

Tab Page	Related Information
InfoProvider	The InfoProvider defines the data basis for planning. This involves real-time InfoCubes and MultiProviders. See InfoProviders. For real-time InfoCubes you can define permitted combinations of characteristic values in the form of characteristic relationships and create data slices for data that you want to protect. For more information, see Characteristic Relationships and Data Slices. On the Settings tab page, you can set a Key Date as the default key date for planning. See Standard Key Date in Planning Functions.
Aggregation Levels	An aggregation level is a virtual InfoProvider that has been especially designed to be able to plan data manually or change it using planning functions. An aggregation level represents a selection of characteristics and key figures for the underlying InfoProvider and determines as such the granularity of the planning. You can create several aggregation levels for an InfoProvider and, therefore, model various levels of planning and, for example, hierarchical structures. Note, however, that aggregation levels cannot be nested. You can change an aggregation level by selecting InfoObjects in the lower part of the screen that are to be used or not. For more information, see Aggregation Level.

The following InfoProviders are can be used as the basis for an input-ready query:

● The InfoProvider is an aggregation level that is defined on a real-time-enabled InfoCube (simple aggregation level).

● The InfoProvider is an aggregation level that is defined on a MultiProvider (complex aggregation level). The following prerequisites must be fulfilled: The MultiProvider includes

○ at least one real-time InfoCube, and

○ no simple aggregation level.

● The InfoProvider is a MultiProvider that contains at least one simple aggregation level.

● Creating and changing filters

With regards to the underlying InfoProvider, filter objects are global objects that restrict the dataset that is used in queries and planning functions. You require filters if you want to use a planning function in a planning sequence.

You define the corresponding settings on the Filter tab page.

Tab Page	Related Information
Filter	You can restrict selected characteristics of the InfoProvider to single values, value ranges, hierarchy nodes, history, or favorites and determine whether they can be changed when you execute them. For more information, see Filter.

● Creating and changing planning functions and planning sequences

You define the corresponding settings on the Planning Functions and Planning Sequences tab pages.

Tab Page	Related Information
Planning functions	The system offers you standard planning functions. You can create the following types of planning functions: ● Unit conversion ● Generate combinations ● Formula ● Copy ● Delete ● Delete invalid combinations ● Repost ● Repost by characteristic relationships ● Revaluate ● Distribute by reference data ● Distribute by key ● Currency translation You can use FOX formulas for complex tasks or define customer-specific planning function types in ABAP using an exit. For more information, see Planning Functions.
Planning sequences	You can determine steps for the input templates or planning functions by selecting the required aggregation level, filter, and planning function (if applicable). For more information, see Planning Sequences.

● Creating and changing variables

Variables can be used in queries and different areas of the planning model (see Variables). The system provides a variable wizard wherever you might want to use variables:

○ When defining characteristic relationships and data slices (InfoProvider tab page)

○ When defining filters (Filter tab page)

○ To parameterize planning functions (Planning Functions tab page)

○ To parameterize queries (in the BEx Query Designer)

Planning Wizard

To assist you in modeling planning for the first time, the planning wizard offers support in the form of an assistant that leads you through a simple scenario, starting with one InfoProvider.

You perform the following steps:

Step	Related Information
InfoProvider	You can select an InfoProvider. (You cannot, however, define characteristic relationships, data slices, and settings.)
Aggregation level	You create one or more aggregation levels.
Filter	You create one or more filters.
Planning function	You create one or more planning functions.
Test environment	The system integrates your planning model into a planning sequence. You can then execute this in the test environment.

Prerequisites

You require real-time-enabled InfoCubes as data stores. You have created these InfoCubes in the Data Warehousing Workbench. For more information, see Real-Time InfoCubes.

Process Flow

...

1. You choose the appropriate InfoProvider.

2. You create one or more aggregation levels.

3. You create one or more filters.

4. You create one or more planning functions.

5. You create a planning sequence.

6. You test the planning model.

Result

You have created a planning model on the basis of which you can now run input-ready queries and automatic planning functions.

Authorizations for BI Integrated Planning

Use

The authorizations that users require for BI Integrated Planning are the same as they require to analyze the data in a query. In addition to the authorization for displaying data, the authorization for changing data is also required in the analysis authorizations.

Integration

There are two types of authorization check:

...

1. Check for standard authorizations: The system checks authorization object S_RS_COMP which contains the activity Execute. The user requires this authorization for the InfoProvider on which the query has been defined.

2. Check for analysis authorizations: The user requires authorization for the InfoProvider on which the aggregation level is based.

For a query based on an aggregation level which is in turn defined on a MultiProvider, the aggregation level authorization is contained in field RSINFOCUBE in S_RS_COMP. However, you use the MultiProvider in the analysis authorizations.

In this sense, aggregation levels are transparent as far as analysis authorizations are concerned.

The following figure illustrates the basic modeling options: