Info Cube
Info Cube
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
2014 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 1 of 9
Table of content
1 InfoProviders
1.1 Characteristic Relationships
1.2 Characteristic Relationships for Time Characteristics
1.3 Data Slices
1.4 Implementing Characteristic Relationships and Data Slices on the SAP HANA Database
1.4.1 SAP HANA-Specific Interfaces for Characteristic Relationships and Data Slices
1.4.2 Parameters for the SQLScript Procedures
1.4.3 Transport and Lifecycle Management of Required Objects
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 2 of 9
1 InfoProviders
Use
InfoProviders contain real-time InfoCubes and DataStore objects for direct updates in planning mode. As such, they provide the data basis for BW Integrated
Planning. Aggregation levels are a type of virtual InfoProvider. They are based on a planning-relevant InfoProvider or a MultiProvider that contains an InfoProvider
of this type. Aggregation levels are specifically designed so that you can plan data manually or change data using planning functions.
For more information about the types of InfoProvider, see:
Real-Time InfoCubes
Creating DataStore Objects for Direct Update
Creating MultiProviders
Characteristic Relationships and Data Slices
When planning, you can define the permitted combinations of characteristic values in the form of characteristic relationships and create data slices for the data
that you want to protect for a real-time InfoCube or a DataStore object for direct updates in planning mode.
Note
More information: Characteristic Relationships and Data Slices.
If the generic types of characteristic relationships (attribute, hierarchy, DataStore) and data slices (selection) do not meet specific customer requirements, you can
implement characteristic relationships and data slices of type Exit.
Note
For more information, see Implementing Characteristic Relationships and Data Slices on the SAP HANA Database
Default Key Date for Planning
You can create a default key date for a real-time InfoCube or a DataStore object for direct updates in planning mode. If time-dependent objects (such as attributes
or hierarchies) are used in objects in the planning model, you can always refer to the default key date for planning. This allows you to ensure that the same key
date is used throughout the planning model. The planning model objects that are relevant for this are characteristic relationships, data slices and parameters of
planning functions.
More information: Standard Key Date in Planning Functions.
Integration
Under Modeling in the Data Warehousing Workbench , you can create InfoProviders as the data basis for BW Integrated Planning. More information: Creating
InfoProviders.
In Planning Modeler , you can select InfoProviders that you want to use as the data basis for BW Integrated Planning. More information: Selecting InfoProviders.
Integration
If you define characteristic relationships for the attributes or hierarchies of characteristics, the system proposes the attributes or hierarchies that you created in the
BW system for a characteristic (see Tab Page: Attributes, Tab Page: Hierarchy and Hierarchy).
Characteristic relationships are created for a real-time InfoCube or a DataStore object for direct updates in planning mode. The system applies the characteristic
relationships to all planning-relevant InfoProviders that reference this InfoProvider.
Each input-ready query and planning function automatically takes the characteristic relationships into account:
In an input-ready query, cells for invalid characteristic combinations are not input ready, and new data records with invalid characteristic combinations
cannot be created.
Planning functions use the characteristic relationships to constantly check whether new characteristic combinations are valid. If it finds invalid combinations,
the system produces an error message.
The system derives the characteristics when it identifies the delta records in the delta buffer (for the InfoCube) or in the after image buffer (for the DataStore object).
Possible source characteristics include characteristics in the planning-relevant InfoProvider that are filled by characteristics from the relevant aggregation levels. If
characteristic relationships are changed, the data records in the planning-relevant InfoProvider might also have to be adapted to the new structure. You use the
Reposting Characteristic Relationships planning function for this purpose.
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 3 of 9
Prerequisites
Before you can define characteristic relationships, the following prerequisites must be met:
The InfoProvider must be a real-time InfoCube or a DataStore object for direct updates in planning mode. The defined characteristic relationships also take
effect in MultiProviders where planning-relevant InfoProviders are used. More information: InfoProviders.
In characteristic relationships of type attribute, the target characteristic must be defined as an attribute of the basic characteristic and it must be contained
in the planning-relevant InfoProvider.
In characteristic relationships of type hierarchy, the target characteristic must be contained in the selected hierarchy and in the planning-relevant
InfoProvider. The hierarchy is mainly intended for modeling a derivation relationship; thus the hierarchy cannot contain a leaf or an inner node more than
once. Link nodes are also not permitted.
With characteristic relationships of type DataStore, only standard DataStore objects are permitted. You can use all the managing and monitoring methods
that are available in the Data Warehousing Workbench.
Features
Definition of a Characteristic Relationship
You can create characteristic relationships for a real-time InfoCube or a DataStore object for direct updates in planning mode. A characteristic relationship is made
up of a set of relations (steps) that link characteristics and are numbered sequentially. Each of these relations links a set of characteristics. These relations
represent the smallest units of a characteristic relationship.
Behavior of Combination Checks With and Without Derivation
You can only use relations to check characteristic combinations or derive characteristics. You specify this behavior when defining a relation. You can link several
relations of type Derivation if the targets of one relation are the sources of another relation. Redundancy should be avoided here so that the relations actually
represent the smallest unit of the characteristic relationships.
At runtime, the system determines the relationships in the planning-relevant InfoProviders that are used.
Combination check: A relation is only used in an aggregation level if every characteristic of the relation occurs in the aggregation level. With derivations,
these are the source and target characteristics. In this case, no characteristics are derived, and the system just performs a combination check.
Characteristic derivation: Derivation is not performed in an aggregation level. Derivation is only performed for records in the planning-relevant
InfoProvider. The system first determines the set (S) of characteristics that are filled by the relevant aggregation level. If all the source characteristics are in
set S, the system applies the derivation relations in the next step. The target characteristics of these derivations can then serve as sources in the steps that
follow. This means that the system performs the maximum possible derivation in the planning-relevant InfoProvider. If previously derived characteristic
values are changed again in subsequent steps, the derivation is incorrect. The system posts an error message.
Types of Characteristic Relationships
The following types of characteristic relationships exist:
Type
More information
Attribute
You can select an attribute of the basic characteristic as the target characteristic
(characteristic currency is an attribute of characteristic controlling area for example).
The existing combinations of characteristics and attribute values are always interpreted
as valid combinations.
Hierarchies
DataStore
The data records located in the DataStore define the valid characteristic combinations and
are used for characteristic derivation.
Only combination check: You can select all InfoObjects from the DataStore object
(except for key figures).
With Derivation: You have to select the keys of the DataStore object as source
characteristics.
Target characteristics can be InfoObjects from the data part of the DataStore object (except
for key figures).
The keys for the DataStore objects can be restricted in any case; the restricted part is then
used for the combination check or derivation. The restrictions can be parameterized with
variables that must be replaceable without the dialog.
We recommend that you use only small DataStore objects (with few characteristics, few
records).
Exit
The valid characteristic combinations and derivable characteristic values are defined by
the customer-specific implementation of the specified exit class.
The exit class must implement interface IF_RSPLS_CR_EXIT. Only these types of
classes can be edited in maintenance. We recommend deriving your class from the
example class CL_RSPLS_CR_EXIT_BASE. You then only have to implement
methods 'CHECK', 'DERIVE' and 'CREATE'. Class 'CL_RSPLS_CR_EXIT_BASE' is
executable, but does not execute any actions.
Note the example source code given in the template class too: An infrastructure for
buffering can be provided here.
Note
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 4 of 9
As well as the characteristic relationships listed above, characteristic relationships for BW time characteristics are also permanently activated in the
system (see Characteristic Relationships for Time Characteristics).
The initial characteristic value # not assigned ) has a special role in a relation. Characteristics that do not occur in an aggregation level (and cannot be derived)
are updated with the initial value.
Example
Combination check without derivation:
There is a relation between the characteristics Product and Assortment ; usually there is no derivation relationship between the two. In aggregation levels
with Product but without Assortment , Assortment is therefore updated with the initial value. These types of combinations are always valid and they cannot
be forbidden. This also applies to combinations with the initial value for Product .
Combination check with derivation:
There is a relation between the characteristics Cost Center and Profit Center ; Profit Center can be derived from Cost Center . In an aggregation level that
contains Profit Center but not Cost Center , Cost Center is also updated with the initial value. Combinations of this sort cannot be forbidden. Since Profit
Center can be derived from Cost Center however, the reverse situation produces an invalid combination.
Activities
For more information on defining characteristic relationships in Planning Modeler, see Defining Characteristic Relationships.
Caution
Note that the system only allows unique relationships. You can derive the calendar year (0CALYEAR) from time characteristic quarter (0CALQUARTER), but
not the calendar week (0CALWEEK).
If you want to model a relationship of this type, you require a customer-defined characteristic relationship of type exit that uses its own characteristics. These
characteristics must reference the appropriate standard time characteristics.
The system uses the derived characteristic relationships for the time characteristics (as with the other relations) for derivation purposes and combinations checks.
Caution
Note that for each time characteristic there is a maximum valid time interval. This can be set in the system. If you are using a time characteristic, the
maximum valid time interval has to cover the entire planning timeframe.
On the General Settings tab page, you specify the value on the F4 Help and Hierarchies for Time Characteristics screen (transaction
RSRHIERARCHYVIRT). Since this setting impacts on performance, you should keep the interval as small as possible.
You cannot create derivations that contain a time derivation that is used automatically in the system.
The following table offers an overview of the derivations that are automatically supported by the system:
Source characteristics
Target characteristics
0CALDAY
0CALWEEK
0CALDAY
0CALMONTH
0CALDAY
0CALQUARTER
0CALDAY
0CALYEAR
0CALDAY, 0FISCVARNT
0FISCPER
0CALDAY, 0FISCVARNT
0FISCYEAR
0CALDAY
0WEEKDAY1
0CALDAY
0CALMONTH2
0CALDAY
0CALQUART1
0CALDAY
0HALFYEAR1
0CALDAY, 0FISCVARNT
0FISCPER3
0CALMONTH
0CALQUARTER
0CALMONTH
0CALYEAR
0CALMONTH
0CALMONTH2
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Comment
Page 5 of 9
0CALMONTH
0CALQUART1
0CALMONTH
0HALFYEAR1
0CALQUARTER
0CALYEAR
0CALQUARTER
0CALQUART1
0CALQUARTER
0HALFYEAR1
0CALMONTH2
0CALQUART1
0CALMONTH2
0HALFYEAR1
0CALQUART1
0HALFYEAR1
0FISCPER, 0FISCVARNT
0FISCYEAR
0FISCPER, 0FISCVARNT
0FISCPER3
0CALWEEK, 0WEEKDAY1
0CALDAY
0CALYEAR, 0CALQUART1
0CALQUARTER
0CALYEAR, 0CALMONTH2
0CALMONTH
0FISCPER
Example
If you want to ensure that certain plan versions cannot be changed after a certain point in time for example, and prevent current data from being overwritten,
you can use a data slice containing these plan versions.
Prerequisites
Data slices are created for a real-time InfoCube or a DataStore object for direct updates in planning mode. They affect all planning InfoProviders that contain this
planning-relevant InfoProvider. More information: InfoProviders.
Features
There are two types of data slice:
Data slices based on a selection. Here, you set the restrictions for the characteristics that you want to protect against changes.
Data slices based on an exit class. In the exit class, you can implement a customer-specific logic to protect data records.
The following basic rules apply for data slices:
If no data slice is defined for a planning-relevant InfoProvider, any valid characteristic combination can be posted to this planning-relevant InfoProvider (see
Characteristic Relationships).
Every data record in the selection in a data slice is protected against changes. The corresponding cells in input-ready queries cannot be changed. You
cannot use planning functions to change or save this kind of record. The data slices cumulate.
If a real-time enabled InfoProvider contains a data slice without any characteristic value restrictions, the data slice acts as a lock for postings of all types in
the entire real-time InfoProvider.
Once you have created a data slice it is activated automatically. The settings in the data slice definition have an immediate effect on the ability to update
data. You can deactivate an existing data slice at any time (status inactive ). This data slice is then ignored.
Activities
For more information on defining data slices in Planning Modeler, see Defining Data Slices.
Regional_Prod_ID
Product_ID
R_01
RP_123
UP_123
R_02
RP_123
UP_321
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 6 of 9
...
...
In the different regional sales organizations, different products can have the same identification number. To ensure that there is a unique designation for a
cross-regional comparison, these RP numbers must be converted into unique UP numbers. In our example, product RP_123 from region R_02 is given
product ID UP_321.
Example 2: Let us assume that a company wants to implement a company-wide planning process for quarterly sales key figures at the product group level.
Note that some regional sales organizations fix their plan data (for certain planning versions at least) on a certain date, while others modify their plan data if
dictated by certain subsequent events.
This could mean for example that the plan data of Region A for the first quarter of the following year is fixed starting on 15th December of the current year,
while Region B is allowed to modify its plan right through to the end of January on the basis of an unforeseen opportunity to increase its sales. To make this
comprehensible, plan version V2 can be introduced, filled with the original plan data from plan version V1 and then opened for modifications from Region B
only.
To implement the requirement in example1, you can define a characteristic relationship of type Exit, containing two relations (steps) with derivation: The first
relation has the unique ID as its source characteristic and the original ID (in connection with the original sales organization) as its target characteristic, while the
second relation is the same but the other way round. The original ID is therefore derived if the unique ID is planned. The unique ID is derived if the fields are
reversed. The consistency of the two IDs is guaranteed if both characteristics are open for planning.
The requirement from example 2 is a typical case for a data slice of type Exit, defined on the characteristics Region, Plan Version and Quarter, with access to
data that is edited outside of the BWsystem in a tool for the planning process, which stores its data in a database. To make this requirement more individual still,
there should a number of administrators who are authorized to modify plan data at any time, in order to correct incorrect entries.
Note
Note the following however: Even if you implement SQLScript procedures for all methods that are used in characteristic relationships and data slices, the
corresponding ABAP implementations must also be present, as the system triggers the ABAP equivalent in certain situations in order to avoid data transfer of
individual records between the BW system in the SAP NetWeaver stack and the SAP HANA database.
Note
If a SQLScript implementation is performed, the names of the implementing SQLScript procedures are determined in the ABAP runtime, and other
parameters that are only available in the SAP NetWeaver stack (such as the user name in the sy-uname system field) are determined for subsequent use in
the SQLScript implementation.
For ABAP processing of the exits, the following interfaces are required:
IF_RSPLS_CR_EXIT : ABAP implementation of the characteristic relationships
IF_RSPLS_DS_EXIT : ABAP implementation of the data slices
In addition to these interfaces, the following interfaces also have to be implemented in order to process the data in the SAP HANA database:
IF_RSPLS_CR_EXIT_HDB : SQLScript implementation of the characteristic relationships
IF_RSPLS_DS_EXIT_HDB : SQLScrip implementation of the data slices
The SAP HANA-specific interfaces have the following tasks:
1. They serve as marking interfaces which show that the data will be processed in the SAP HANA database, regardless of the existence of characteristic
relationships and data slices of type Exit.
2. By providing information about the corresponding SQLScript implementations, these implementation should be called up if the data is processed in the
SAP HANA database, and a data transfer to the ABAP runtime environment can be avoided.
Related Information
SAP HANA-Specific Interfaces for Characteristic Relationships and Data Slices
Parameters for the SQLScript Procedures
Transport and Lifecycle Management of Required Objects
Method GET_SQLSCRIPT_INFO
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 7 of 9
Method GET_SQLSCRIPT_INFO returns the name of the SQLScript procedures that are required for exit processing in the SAP HANA database.
Method GET_SQLSCRIPT_INFO of interface IF_RSPLS_CR_EXIT_HDB has the following export parameters:
Table 1: Export Parameters of Method GET_SQLSCRIPT_INFO of IF_RSPLS_CR_EXIT_HDB
Parameter
Description
E_DB_SCHEMA_NAME
E_PROCEDURE_NAME_CHECK
Name of the SQLScript procedure that contains the implementation of the method to
check characteristic relationships.
E_PROCEDURE_NAME_DERIVE
Name of the SQLScript procedure that contains the implementation of the method to
derive characteristic relationships.
E_PROCEDURE_NAME_CREATE
Name of the SQLScript procedure that contains the implementation of the method to
create characteristic relationships.
E_PARAMETER_NAME
Name of a DDIC structure that describes additional parameters that are passed on to the
SQLScript procedures at runtime.
If the parameter of the method is not set, no additional information is sent by the
application server.
Description
E_DB_SCHEMA_NAME
E_PROCEDURE_NAME_PROTECTED
Name of the SQLScript procedure that contains the implementation of the data protection
check in data slices.
E_PARAMETER_NAME
Name of a DDIC structure that describes additional parameters that are passed on to the
SQLScript procedures at runtime.
If the parameter of the method is not set, no additional information is sent by the
application server.
Note
If method GET_SQLSCRIPT_INFO does not set one of the parameters with procedure names, the corresponding ABAP implementation is called at runtime
as a fallback.
Description
E_S_PARAMETER
Characteristic Relationships
CHECK
IN: All data records that should be processed by the procedure.
OUT: All data records in the IN parameter table, which are considered valid with regard to the characteristic relationship.
DERIVE
IN: All data records that should be processed by the procedure.
OUT: All data records in the IN parameter table, which are considered valid with regard to the characteristic relationshipm with derivation of target
charactersitic values from the source characteristics.
CREATE
OUT: For the CREATE procedure, there is an OUT table parameter with the structure of the modeled characteristic relationship, containing all
characteristic combinations that are valid according to the selection condition passed on to this method.
Data Slices
PROTECTED
IN: All data records that should be processed by the procedure.
OUT: All data records in the IN parameter table, which are protected against changes with regard to the data slice.
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 8 of 9
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 9 of 9