BI Platform

BI Platform
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw70/helpdata/en/f7/8e93e8850b244085f2c4a39a7d73d5/content.htm
Created on November 15, 2016
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.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing
subtopics.
2016 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 Page 1 of 139

2014 SAP SE or an SAP affiliate company. All rights reserved.
Table of content
1 BI Platform
1.1 Metadata Repository
1.1.1 BI Metadata Search
1.1.2 Displaying Graphics
1.1.3 HTML Export
1.1.4 Exchanging Metadata in XMI Format
1.1.5 Calling the Metadata Repository as an HTTP Service
1.2 Documents
1.2.1 Document Classes
1.2.2 BAdIs for Use in Documents
1.2.3 Hyperlinks to Documents
1.2.4 BI Security Manager for Documents
1.2.5 Repository Manager for BI
1.2.5.1 BI Document Repository Manager
1.2.5.2 BI Metadata Repository Manager
1.3 OLAP
1.3.1 Special OLAP Functions and Services
1.3.1.1 Aggregation
1.3.1.1.1 Examples in the Data Warehousing Workbench
1.3.1.1.1.1 Examples of Exception Aggregation: Last Value and Average
1.3.1.1.1.2 Examples of Exception Aggregation: Average (AV1)
1.3.1.1.2 Examples in the BEx Query Designer
1.3.1.1.2.1 Example of Exception Aggregation: Counting
1.3.1.1.2.2 Example of Exception Aggregation: Enhanced Counting
1.3.1.2 Hierarchies
1.3.1.2.1 Options for Hierarchical Modeling
1.3.1.2.2 Hierarchy Nodes
1.3.1.2.2.1 Link Nodes
1.3.1.2.3 Loading Hierarchies
1.3.1.2.3.1 Loading Hierarchies Using a Process Chain
1.3.1.2.3.2 Special Features when Loading using the PSA
1.3.1.2.3.3 Loading Data as Subtrees
1.3.1.2.4 Creating Hierarchies
1.3.1.2.4.1 Modeling Nodes and Leaves
1.3.1.2.5 Editing Hierarchies
1.3.1.2.5.1 Functions of Hierarchy Processing
1.3.1.2.5.2 Level Maintenance
1.3.1.2.5.3 Hierarchy Attributes
1.3.1.2.6 Activating Virtual Time Hierarchies
1.3.1.2.7 Hierarchy Properties
1.3.1.2.7.1 Hierarchy Version
1.3.1.2.7.1.1 Maintaining Hierarchy Versions
1.3.1.2.7.2 Time-Dependent Hierarchies
1.3.1.2.7.2.1 Time-Dependent Hierarchy Structures in the Query
1.3.1.2.7.2.2 Loading Time-Dependent Hierarchies
1.3.1.2.7.3 Intervals
1.3.1.2.7.4 Sign Reversal
1.3.1.2.7.4.1 Using Sign Reversal
1.3.1.3 Elimination of Internal Business Volume
1.3.1.4 Currency Translation
1.3.1.4.1 Scenarios for Currency Translation
1.3.1.4.2 Currency Translation Type
1.3.1.4.2.1 Defining Target Currencies Using InfoObjects
1.3.1.4.2.2 Creating Variables for Currency Translation Types
1.3.1.4.2.3 Creating Currency Translation Types
1.3.1.4.2.4 Transferring Exchange Rates for Currencies from SAP Systems
1.3.1.4.2.5 Transferring Global Table Entries for Currencies from SAP System
1.3.1.4.2.6 Exchange Rates for Currencies in Flat Files
1.3.1.4.2.6.1 Uploading Exchange Rates from Flat Files
1.3.1.4.3 Currency Translation During Transformation

1.3.1.4.4 Currency Translation in the Business Explorer
1.3.1.4.4.1 Setting Variable Target Currency in the Query Designer
1.3.1.4.4.2 Multiple Currency Translation Types in One Query
1.3.1.4.5 Currency and Unit Display in Business Explorer
1.3.1.5 Quantity Conversion
1.3.1.5.1 General Information About Quantity Conversion
1.3.1.5.2 Prerequisites for InfoObject-Specific Quantity Conversion
1.3.1.5.3 Quantity Conversion Types
1.3.1.5.3.1 Defining Target Units of Measure Using InfoObjects
1.3.1.5.3.2 Creating Variables for Quantity Conversion Types
1.3.1.5.3.3 Creating Quantity Conversion Types
1.3.1.5.3.4 Transferring Global Table Entries for Units of Measure from SAP
1.3.1.5.4 Quantity Conversion During the Transformation
1.3.1.5.5 Quantity Conversion in the Business Explorer
1.3.1.5.5.1 Setting Variable Target Units of Measure in the Query Designer
1.3.1.5.6 Quantity Conversion Scenarios
1.3.1.5.6.1 Example Data Without Compounding
1.3.1.5.6.1.1 Conversion with Fixed Target Quantity
1.3.1.5.6.1.2 Conversion Using Factors from InfoObjects
1.3.1.5.6.1.3 Conversion with Target Unit of Measure Using Attribute in InfoOb
1.3.1.5.6.1.4 Conversion with Fixed Target Unit of Measure and Dynamic Determi
1.3.1.5.6.2 Example Data With Compounding
1.3.1.5.6.2.1 Conversion with Fixed Target Unit of Measure
1.3.1.5.6.2.2 Conversion Using Factors from InfoObjects
1.3.1.5.6.2.3 Conversion with Target Unit of Measure Using Attribute in InfoOb
1.3.1.5.6.2.4 Conversion with Fixed Target Unit of Measure and Dynamic Determi
1.3.1.6 Local Calculations
1.3.1.7 Constant Selection
1.3.1.7.1 Example: Market Index
1.3.1.7.2 Example: Using Constant Selection with MultiProviders
1.3.1.8 Analysis Authorizations
1.3.1.9 Report-Report Interface
1.3.1.9.1 Process when Calling the RRI
1.3.1.9.2 Editing Sender-Receiver Assignments to the RRI in the BI System
1.3.1.9.3 Receivers
1.3.1.9.3.1 BEx Query as Recipient
1.3.1.9.3.1.1 Example of a BEx Query as a Receiver
1.3.1.9.3.2 Creating a Transaction As a Receiver
1.3.1.9.3.3 Creating a Web Address As a Receiver
1.3.1.9.3.3.1 Examples for Web Addresses as Receiver
1.3.1.9.3.4 iView As Receiver
1.3.1.9.3.5 Creating Your Own Report Type as Receiver
1.3.1.9.4 Maintaining Assignment Details
1.3.1.10 SAP DemoContent for Features
1.3.2 Performance Optimization
1.3.2.1 Performance Optimization with SAP NetWeaver BI Accelerator
1.3.2.1.1 SAP NetWeaver BI Accelerator Index
1.3.2.1.1.1 Technical Information About the SAP NetWeaver BI Accelerator Eng
1.3.2.1.2 Using the BIA Index Maintenance Wizard
1.3.2.1.3 Activation and Provision of Data
1.3.2.1.3.1 Activating and Filling SAP NetWeaver BI Accelerator Indexes
1.3.2.1.3.2 Rolling Up Data in SAP NetWeaver BI Accelerator Indexes
1.3.2.1.4 System Response Upon Changes to Data
1.3.2.1.4.1 System Response Upon Changes to Data: SAP NetWeaver BI Accelerat
1.3.2.1.4.2 Improving Efficiency Using SAP NetWeaver BI Accelerator Delta In
1.3.2.1.5 Status Display and Check Tools
1.3.2.1.5.1 Using the SAP NetWeaver BI Accelerator Monitor
1.3.2.1.5.1.1 Global Parameters for Indexing
1.3.2.1.5.1.2 SAP NetWeaver BI Accelerator Index Design
1.3.2.1.5.2 Checking SAP Net Weaver BI Accelerator Indexes (Transaction RSRV
1.3.2.1.5.3 Checking SAP NetWeaver BI Accelerator Indexes (Check Center)
1.3.2.1.5.4 Statistics for Maintenance Processes of SAP NetWeaver BI Acceler

1.3.2.1.5.5 Traces for SAP NetWeaver BI Accelerator
1.3.2.2 Performance Optimization with Aggregates
1.3.2.2.1 Aggregates
1.3.2.2.1.1 Selection Type "All Characteristic Values" ('*')
1.3.2.2.1.2 Selection Type "Fixed Value" ( F )
1.3.2.2.1.3 Selection Type "Hierarchy Level" ('H').
1.3.2.2.2 Create and Change
1.3.2.2.2.1 Creating the First Aggregate for an InfoCube
1.3.2.2.2.2 Editing Aggregates Manually
1.3.2.2.2.3 Design and Components of Aggregates
1.3.2.2.2.4 Further Editing Functions for Aggregates
1.3.2.2.2.5 Automatic Selection and Optimization of Aggregates
1.3.2.2.2.5.1 Proposals from Queries
1.3.2.2.2.5.2 Proposals from BI Statistics
1.3.2.2.2.5.3 Optimizing Proposed Aggregates
1.3.2.2.3.1 Activating and Filling Aggregates
1.3.2.2.3.2 Rolling up Data into an Aggregate
1.3.2.2.3.3 System Response to Changes to Master Data and Hierarchies
1.3.2.2.3.4 Loading Data into Aggregates Efficiently
1.3.2.2.4 Performing Checks for Aggregates
1.3.2.2.4.1 Check Time
1.3.2.2.4.2 Check Mode
1.3.2.2.4.3 Technical Information
1.3.2.3 Non-Cumulatives
1.3.2.3.1 Modeling Non-Cumulatives with Non-Cumulative Key Figures
1.3.2.3.1.1 Non-Cumulative Key Figures
1.3.2.3.1.2 Time Reference Characteristic

1 BI Platform
Purpose
The Business Intelligence platform serves as a technological infrastructure and offers various analytical technologies and functions in the context of the
Analytic Engine .
The Metadata Repository allows you to display information about the metadata objects for the BI system in the current system, or to use it independently of
BI system operation.
With Documents , you can make context-sensitive information available for BI objects. You can add documents for metadata, master data, and InfoProvider
data.
The Analytic Engine provides OLAP functions and services as well as services for BI Integrated Planning and analysis process design:
Online Analytical Processing (OLAP) prepares information for large amounts of operative and historical data. The OLAP processor allows multi-
dimensional analyses from various business perspectives. It includes the "aggregation" and "calculation" layers.
Within the scope of Business Planning , the analytic engine provides services that allow you to enter data manually and create planning applications in
BI Integrated Planning on the basis of this data.
Special analysis processes such as Data Mining can be implemented using the Analysis Process Designer (APD). Using an analysis process,
information can be combined in the BI system to create new information. This new information can be obtained using analytical processes, such as data
mining methods or simpler, customer-specific calculations and transformations.
OLAP , Business Planning and Analysis Process Design use the "caching" and "security" generic services of the analytic engine.
You use Business Planning to create planning applications. The areas of application range from simple, manual data entry to complex planning scenarios.
Several solutions are available. BI Integrated Planning is the solution that is completely integrated into the BI system.
Integration
The following figure illustrates the integration of the BI platform and its functional areas into the architecture of SAP NetWeaver Business Intelligence:
1.1 Metadata Repository
Use
With the HTML-based metadata repository you can access information about the metadata objects of SAP NetWeaver Business Intelligence from a central
point. This metadata especially includes important object properties and their relationships with other objects.
Features
Information Display
From the SAP Easy Access screen, choose Modeling Data Warehousing Workbench . The metadata repository is displayed.
A navigation area is available on the left-hand side of the metadata repository, and there is a display area on the right-hand side.
In the navigation area, you can choose the objects for which information needs to be displayed:
Activated objects
Local objects from the BI system
Objects from all systems
Business Content (SAP-delivered objects)
The available object types for the selection are listed in the display area. By clicking the link for an object type, you get a list of all objects that belong to this
type. By clicking the link to an object, you get detailed, object-specific information.
To navigate from page to page in the metadata repository, choose ( Display Previous Page ) or ( Display Next Page ). Choose Main Page to call

up the entry page.
Search in BI Metadata
If you choose Search in Metadata Repository in the navigation area, the fields that need to be filled for the search criteria are displayed in the right-hand
area of the screen. When a search request is made, the technical name, short texts, long texts, and SAP metadata object documentation are searched. In
addition, you can also search for specific attributes or options for each object type in an advanced search. For more information, see BI Metadata Search.
For information about managing the BI metadata search in the Documents functional area of the Data Warehousing Workbench, see Tab Page: Indexing
Metadata.
Graphics
The graphic display of metadata objects is available in different formats (VML and SVG). For more information, see Displaying Graphics.
HTML Export
You can use different HTMP export options to save information about Business Intelligence metadata objects as local files. For more information, see HTML
Export.
Metadata Exchange
You use the Transport Connection functional area in the Data Warehousing Workbench to exchange metadata between different systems. For more
information, see Exchanging Metadata in XMI Format.
Metadata Documents
In BI documentation administration, you can create documents for metadata objects and select them to be displayed as online documentation. For more
information, see Document Classes and Document as Online Documentation.
Calling the Metadata Repository as an HTTP Service

The metadata information is automatically available as an HTTP service after the BI system has been installed. For more information, see Calling the
Metadata Repository as an HTTP Service.
1.1.1 BI Metadata Search
Use
You use the TREX search engine to search for BI metadata (such as InfoCubes, InfoObjects, queries, and Web templates) in the following modes: The
simple search is a pure text search; the advanced search allows you to search according to attributes, using specific restrictions, or using a full-text search.
Integration
The BI metadata search is integrated into the functional areas of the Data Warehousing Workbench:
Data Warehousing Workbench
Functional Area BI Metadata Search
Modeling Data Warehousing Workbench search
Administration Simple and advanced search using BI metadata search/BI document administration
(see Tab Page: Metadata Indexing)
Transport Connection Simple and advanced search by choosing Search in the upper toolbar
Documents Simple and advanced search using BI metadata search/BI document administration
(see Tab Page: Metadata Indexing)
BI Content Simple and advanced search by choosing Search in the upper toolbar
Translation Simple and advanced search by choosing Search in the upper toolbar
Metadata repository Simple Search
The BI metadata search is also integrated into some object editors and the BEx open dialog.
Prerequisites
1. The search engine must be fully installed for you to use the full functions for searching in metadata.
If the search engine is not fully installed, you can still use the simple search, which the system then performs in the database. As a result, the
search is slower, case-sensitive, and does not support a search in the attributes.
Make sure that you have performed the following steps:
Installed the TREX search engine
Created an RFC destination in the BI system for the TREX search engine

Entered the RFC destination in table RSODADMIN_INT
For more information, see SAP Reference IMG SAP Customizing Implementation Guide SAP NetWeaver Business Intelligence
Connectivity of TREX.
2. The metadata has to be indexed.
a. The object types relevant for the BI metadata search have to be specified and the metadata has to be indexed initially.
b. You have to schedule the (delta) indexing of metadata as a regular job (transaction RSODADMIN).
You make the required settings in the Administration functional area of the Data Warehousing Workbench. For more information about managing the BI
metadata search, see Tab Page: Metadata Indexing.
Features
The system provides the following options as part of the simple and advanced search functions:
Simple Search
With the simple search, the system searches in one or all object types for the text entered in the technical name and description. The search is not case-
sensitive; it finds objects, even if the capitalization in the text entered is different from the capitalization in the search term.
Advanced Search
With the advanced text search, you can enter more than one search term. You have the following options:
with exact wording
with all search terms
with at least one of the search terms
without search terms
You can choose from the following search options:
Language: You can choose from all installed languages.
Version: By default, the search is performed in the delivered A Version . You can, however, choose to search in the D Version instead.
Search method: The default setting is Normal . You can choose the Fuzzy search instead.
In addition, you can search in the attributes specific to each object type. First select the Object Type . (Input help is available.) The system displays the
relevant attributes in the table. Enter the required values.
Furthermore, you can restrict the search for all object types to last changed by and changed at or to changes made within a specific period of time.
For example, you can search for all queries that were changed during the last month and contain the term "overview" in the text and the
characteristic "customer" in the definition.
Activities
1. Use one of the methods described in the integration section to navigate to the BI metadata search.
2. Choose either the simple or advanced search and, as described in the features section, enter the required search terms, attributes, or restrictions.
3. Choose Start Search .
The system displays a list of the activated and BI Content objects sorted by object type (if you did not restrict them) and object name (technical name).
1.1.2 Displaying Graphics
Use
Depending on the particular object type, the metadata repository supports the graphic display of object-specific information. The data flow for a metadata
object and its structure pertain particularly to this.
Procedure
1. First, determine the graphics format you want to use. To do this, choose Extras in the metadata repository. Graphics VML (Vector Markup
Language, IE5) or SVG (Scalable Vector Graphics) .
The display in VML format is only possible as of MS Internet Explorer 5. Graphics in SVG format can be displayed using a browser plug-in, for
example with MS Internet Explorer 4 and Netscape Navigator 4.
2. Navigate to the object information for those metadata objects that you want to see in a graphic display.
3. If the system supports the graphic display for this object, then links appear in the object information for the graphics that are able to be selected under
Graphic Display :
Network Display of Data Flow : with roles, workbooks, InfoSources, and queries
Schematic Display as Star Schema: with InfoCubes
Schematic Display, Compact: with InfoCubes
Query Preview : with queries
If you want to change the size of a graphic, choose Change Graphics Size . You get to the Change Graphics Size dialog box. The
standard value is 1.00. If necessary, change this value.

By using Print , you can print the graphic displayed.
Furthermore, you can use the context menu of the installed browser in the graphics area.
4. You can navigate by using links from the graphic to the object information for the displayed objects.
1.1.3 HTML Export
Use
You want to copy information about Business Intelligence metadata objects into a local export directory and use them independently of the BI system. You
can use the following HTML export functions in the Data Warehousing Workbench:
Export Function in the . Data Warehousing Workbench view
Menu Path Extras HTML Export Transport connection

Documents
Business Content
Translation
Metadata Repository
Context menu: Export HTML Documentation Transport connection
Business Content
Translation
Note: Selecting Extras HTML-Export always means that the entire HTML documentation is exported. This can usually take up a lot
of time. For this reason, we recommend that you export the HTML documentation via the context menu for the required metadata object, using
an unrestricted search depth.
Features
Menu Extras HTML Export
If you choose Extras HTML-Export, the following functions are available:
Function Description
Generate HTML Pages Generate HTML pages for the metadata objects in the A version (active objects).
Generate HTML Pages (Business Content) Generate HTML pages for the metadata objects in the D version (Business Content
objects).
Save HTML Pages as Local Files Export entire HTML documentation for the metadata objects in the A version.
Save HTML Pages (Business Content) Save entire HTML documentation for the metadata objects in the D version.
Delete Saved HTML Pages Delete HTML pages for metadata objects in the A version generated on the
database.
Delete Saved Pages (Content) Delete HTML pages for metadata objects in the D version generated on the
database.
Context Menu for Metadata Object

In the Transport Connection, Business Content and Translation Data Warehousing Workbench views, you can call up the Export HTML Documentation
function in the context menu of the required metadata objects.
After choosing this function, the How Deep Should the Hyperlinks Be dialog box appears. Here you can choose an unrestricted search depth:
Search Depth Meaning
000 The current HTML page is exported together with its symbols. Pages to which this
page is linked are not included.
001 The current HTML page is exported together with all pages to which this page is
linked.
002 The current HTML page is exported as are all pages to which the current page and
pages linked on the first level are linked.
The length of time required increases as the search depth increases. We therefore recommend you use the lowest possible search depth.
1.1.4 Exchanging Metadata in XMI Format

Use
In order to exchange metadata (BI objects) between different SAP systems, you can use XMI in Transport Connection functional in the Data Warehousing
Workbench (XML Metadata Interchange). A model derived along the lines of the CWM ( Common Warehouse Metamodel ) is used.
Note that the SAP format is used exclusively for exchanging metadata information between SAP systems and therefore contains proprietary
enhancements that cover the SAP-specific functionality of BW enhancements. Because of this, this format cannot be used by CWM-
compatible tools without extra transformations.
More information about the Transport Connection functional area of the Data Warehousing Workbench: Transporting BI Objects.
Integration
You can export or import the XML files ( Download or Upload to/from PC) in the Data Warehousing Workbench.
An ICF Service is also available to you at sap/bw/xml/cwm. You can use this HTTP service to request this metadata in the same way as in the Web server.
In order to request metadata for an object, use the following URL:
<Protocol>://<Server>:<Port>/sap/bw/xml/cwm?/
CLASSID=<Class>&ID=<Name>&DETAIL=X&OBJECTVERSION=A
The following table lists the information that you need to replace the placeholders with:
Components of the URL
Placeholder Information
<Protocol> http or https
<Server>:<Port> Specify the name of the server and the port for the required BI system.
http://ls0027.wdf.sap-ag.de:1080/
sap/bw/xml/cwm?...
For more information, see ICF Services in SAP BW.
<Class> Specify the name of the class for the required BW object.
Example for the class InfoCube : CLASSID=COM.SAP.BW.CWM.OLAP.INFOCUBE
You get the BI model in XML format from the following URL:
http://<Server>:<Port>/sap/bw/xml/cwm?
CLASSID=METAMODEL
<Name> Specify the technical name for the required BI object.
You get an overview of all objects from the URL:

CLASSID=LIST&ID=&DETAIL=&OBJECTVERSION=A
The parameter &OBJECTVERSION=D gives you an overview of all Business
Content objects, namely:
CLASSID=LIST&ID=&DETAIL=&OBJECTVERSION=A
You get an overview of all objects of a specific type by using the ID specification
in the URL.
You can enter the following for InfoCubes for example:

CLASSID=LIST&ID=COM.SAP.BW.CWM.OLAP.INFOCUBE&DETAIL=&OBJECTVER
SION=A
Features
Exchanging metadata involves:
Importing from another system

Exporting into another system
Those objects for which there are BAPIs ( Business Application Programming Interfaces ) are supported with details. If you want an overview
of the object types in your system that have BAPIs available, choose BAPI Explorer (Transaction BAPI) Hierarchical SAP Business
Information Warehouse Warehouse Management .
You can only import these objects after you have changed them. Presently you are only able to import BI objects.
You can export the current BI model according to the XMI (XML Metadata Interchange) standard. This is made possible with the SAP report
RSO_REPOSITORY_EXCHANGE_XML.
For more information about the XMI standard, see the OMG homepage (www.omg.org).
The graphic below illustrates the EXPORT and IMPORT functions.

Calling the Metadata Repository as an HTTP Service
Use
Because the metadata repository is implemented as an HTTP service, you can call the information on the metadata objects for Business Intelligence in the
Web browser of any client using a URL.
Integration
The URL for the HTTP service has to be structure according to the following schema:
<Protocol>://<Server>:<Port>/sap/bw/doc/metadata/
For more information, see ICF Services in SAP BI.
Features
By entering certain page parameters you can call up the following pages specifically:
Main Page of the Metadata Repository

<Protocol>://<Server>:<Port>/sap/bw/doc/metadata/?page=BW_REPOSITORY&SystemID=<SystemIDClient>
An example of <SystemIDClient> is: AB5CLNT003.
List of Object Types for the Metadata Repository

If you only want to call up the right frame with the list of object types, use the following page parameter:
<Protocol>://<Server>:<Port>/sap/bw/doc/metadata/?page=BW_O_TYPES&SystemID=<SystemIDClient>
Information About a Specific Metadata Object

In the Data Warehousing Workbench, navigate to the object, and select F1 help. The Web browser starts in a new window and shows the metadata information
for the desired object. Copy the URL from the address field.
The URL starts with: <Protocol>://<Server>:<Port>/sap/bw/doc/metadata/?page=BW_O_D&SystemID=<SystemIDClient>
An example of this: http://us7031.wdf.sap.corp:50031/

SAP/BW/DOC/METADATA/?page=BW_O_D&SystemID=AB5CLNT003
&ClassID=CUBE&ID=0BWTC_C02&objectVersion=A&sap-language=EN&sap-client=003
1.2 Documents

Use
With BI objects, you can add, link to, and search one or more documents in various formats, versions, and languages. You can add documents for metadata,
master data, and InfoProvider data. There are three corresponding document classes.
More information: Document Classes
Integration
The following figure provides an overview of the components:
Prerequisites
You have given users the authorization to display or edit documents.
More information: Authorizations for Documents and Administration of BI Metadata Search and BI Documents
Features
You can use documents for metadata, master data, and InfoProvider data in Web applications, in Knowledge Management (KM), in the Data Warehousing
Workbench (BEx Web runtime, ABAP), and in the BEx Analyzer. The following table provides an overview of the available tools and options.
Area Description
Data Warehousing Workbench In the Data Warehousing Workbench (BEx Web runtime, ABAP), you can only
access and edit documents that are on the BI server and have not been migrated.
The Administration functional area is available for editing documents BI
Metadata Search / BI Documents. The Documents screen is available for
maintenance transactions for metadata and master data. The same functions for
creating, importing, editing, exporting, and displaying documents are available on
both interfaces. In the Administration functional area (Administration BI
Metadata Search/BI Documents), you can display and edit documents from all
document classes using various search criteria. You can also branch to document
administration.
More information:
Processing Documents on the Documents Screen
Editing Documents in the Document View of DW Workbench
Web applications In Web applications, you can access documents on the BI server and in the portal.
Using the Single Document, Document List, and Analysis Web items, you can insert
context-sensitive documents into the data used in the Web applications and display
the related properties.
More information:
Using Documents in Web Applications
Display of Documents for InfoProvider Data
Knowledge Management In the BEx Web runtime (Java), you can integrate BI documents into portal-based
Knowledge Management using the BI Document Repository Manager, the BI
Metadata Repository Manager, and migration. You can access documents on the BI
server and in the portal. All KM services are available for working with BI
documents.
More information:
Integrating Content from BI into the Portal
BI Documents in Knowledge Management
BEx Analyzer In the BEx Analyzer (BEx Web runtime, ABAP), you can display, create, and edit
documents that were created in the Data Warehousing Workbench, in the master
data maintenance, or in a Web application.
The BEx Analyzer only uses the BI server to store documents. Migrated

documents are not available in the BEx Analyzer. Only migrate documents if they
do not use the BEx Analyzer or do not use it in connection with documents.
More information:
Working with Documents in the BEx Analyzer
1.2.1 Document Classes
Definition
A document class is made up of the documents for one of the following categories of BI objects: Metadata, master data, InfoProvider data. Documents in a
document class are characterized by particular logical document properties.
Use
The following overview shows you the BI objects that you can choose from and the corresponding document classes. For each document class, examples are
provided of where the different documents are typically used.
BI Object Document Class
Metadata META
Aggregate Example of documents for metadata:
Transformation rule Documentation
InfoCube Explanations (characteristic ABC means ...)
InfoObject History/changes
InfoPackage
InfoSet
InfoSource The user can select a document that they want to display in the online
DataStore Object documentation. See Documents as Online Documentation.
Query (including variables, structures, restricted and calculated key
figures)
Reporting Agent scheduling package
Reporting Agent settings
Web item
Web template
Master data MAST

Characteristic value Example of documents for master data:
Screens for personnel numbers
Descriptions and technical specifications of materials
Original documents for order forms
Version documentation (target/actual budget)
InfoProvider data TRAN

Combination of characteristic values Example of documents for InfoProvider data:
Comments on various characteristic values (Sales for material 4711 in Germany
were poor in May, because ..., In May the following key figures were interesting:
It is not possible to assign documents to navigation attributes. Neither is this Delivery quantity Explanation ..., Outstanding payments - ...)
possible if the attribute is a document-relevant characteristic. If this is the case, See also:
you have to model all the characteristics that you want to use for assigning Documents for planning objects in BW-BPS
documents as direct characteristics in the InfoProviders and not as navigation
attributes.
Structure
The following overview shows you the document classes that you can choose from and the corresponding document properties.
Document Class Document properties
META You can set one value for each of the following document properties:
Object Type
Object Name
MAST You can set one value for each of the following document properties:
Characteristic
Characteristic Value
TRAN You can set one value for each of the following document properties:
InfoProvider
Query
You can set more than one value for the following document property:
Key Figure
The characteristics that have been maintained as properties of documents are also
displayed (sorted alphabetically). You can set more than one value for each
document property for these characteristics.

You have to activate any characteristics that you want the system to display in the
maintenance screens for InfoProvider data documents. You do this in the
maintenance screens for characteristics on the Tab Page: General
( Characteristic is Document Property ).
Integration
Document properties are provided by default:
As search criteria in the Documents functional area of the Data Warehousing Workbench.
See Processing Documents in the DW Workbench Documents View.
As logical document properties when you create a document. You can use document properties to assign documents to a BI object. See Creating
Documents
1.2.2 BAdIs for Use in Documents
Use
BAdIs for use in documents are used in the SAP Business Information Warehouse (BW) component, package RSOD KW Document Connection . You find
them in the SAP Customizing Implementation Guide (IMG) under SAP NetWeaver Business Intelligence BI Enhancements BAdIs for Document
Enhancements BAdI for Documents.
Note that BAdIs are only supported for documents on the server (BEx Web runtime, ABAP). They are not supported for documents in BEx
Web runtime (Java).
The following tables provide an overview of the BAdIs defined for use in documents and the corresponding methods:
BAdI for Documents (RSOD_DOC_BADI)

You use this BAdI to access BI documents when saving and reading, and to make customer-specific changes. The individual methods support the following
options:
BAdI Methods
CHANGE_PROPERTIES Change properties of a document
CREATE_PROPERTIES Create properties of a document
DELETE_PROPERTIES Delete properties of a document
STORE_CONTENT Write document content to the database
SELECT Select documents (DW Workbench or Web application)
HIERARCHY_RESOLVE Control hierarchy resolution in reporting
BAdI for Single Document Web Item (RSOD_ITEM_DOC)

You use this BAdI to change HTML generated by the Single Document Web item or to define it yourself. You use this BAdI to:
Display additional properties of the document (such as Last Changed By or Time Changed) in the Web application
Display the content of the document
Add links or pushbuttons for changing or creating documents in the Web application
Methods Description
CHANGE_RENDERING Change output (HTML)
BAdI for List of Documents Web Item (RSOD_ITEM_DOC_LIST)

You use this BAdI to change HTML generated by the List of Documents Web item or to define it yourself. For example, you want to display documents with
their content instead of just displaying links.
Methods Description
CHANGE_RENDERING_CONTEXT Change output of the context (the selection)
CHANGE_RENDERING_FUNCTIONS Change output of the Additional Functions pushbutton
CHANGE_RENDERING_LIST Change output of document list
CHANGE_RENDERING Change entire output of item

BAdI for Maintaining Text Documents on the Web (RSOD_WWW_DOC_MAINT)
You use this BAdI to make customer-specific modifications to how documents are maintained on the Web. The following operations are supported:
Activating version management of documents
Filling the content of new documents from a source document
Determining the short text of a new document from the document properties
Hiding properties (such as InfoProvider or query)
Preventing the creation of new documents (for example, when there is already a document for this combination of characteristics)
Methods Description
DETERMINE_VERSION_HANDLING Determine version handling on the Web
BEFORE_RENDERING Option to change the document before displaying it
Default Settings
The BAdIs can be used multiple times and are not filter dependent.
More Information:
For more information, see the system documentation for interface methods.
To display this documentation, you first have to branch to the interface by double-clicking the interface name. On the Methods tab page of
the Class Builder , choose the Documentation for the method you require.
1.2.3 Hyperlinks to Documents
Definition
A hyperlink links a document of any document class to a second document, without physically including the first document in the second document. Both
documents must have been created in a format that supports hyperlinks, for example, HTML, Microsoft Word, or Microsoft Excel.
Use
A distinction is made between the following document stores:
Stored in the BI system (SKWF) and accessed using the BI Document Repository Manager
Stored in the BI system (SKWF) and accessed using the SAP NetWeaver Application Server (ABAP)
Stored in Knowledge Management (see Migration of Documents into the CM Repository)
Stored in the BI System (SKWF) and Accessed Using the BI Document Repository Manager
The following types of link are possible:
You need the following information if you want to set a link from outside the BI system to a document for a BI object:
Portal server
Port
Name of the document to which you want to link
From this information, you build the URL as follows:
Document Class URL
Metadata http://<Portal Server>:<Port>/irj/go/km/docs/<BI Document Repository

Prefix>/Metadata/ <Object Type>/ <Object Name>/ <Document Name>
Master data http://<Portal Server>:<Port>/irj/go/km/docs/<BI Document Repository

Prefix/MasterData/ <Characteristic Name>/ <Characteristic Value>/ <DOCUMENT>
InfoProvider data http://<Portal Server>:<Port>/irj/go/km/docs/<BI Document Repository

Prefix/InfoProviderData/
Documents that are assigned to InfoProviders and queries:
/BI Document Repository Prefix/InfoProviderData/ <InfoProvider>/ <Query>/
<Document Name>
Documents that are only assigned to InfoProviders (cross query):
/BI Document Repository Prefix/InfoProviderData/ <InfoProvider>/ <Document
Name>
Documents that are used across InfoProviders:
/BI Document Repository Prefix/InfoProviderData/ <Document Name>

The <BI Document Repository Prefix> placeholder includes the prefix that is configured for the BI Document Repository Manager (for example,
/bi_documents).
For more information about this type of storage, access, and the significance of the <BI Documents Prefix> placeholder, see BI Document Repository
Manager.
Stored in the BI System (SKWF) and Accessed Using the SAP NetWeaver Application Server (ABAP)
Server (the SAP NetWeaver Application Server, not the ITS)
Port
Document Class URL
Metadata http://<Server>:<Port>/SAP/BW/DOC/META/FLDMETA/<Document Name>
Master data http://<Server>:<Port>/SAP/BW/DOC/MAST/FLDMAST/<Document Name>
InfoProvider data http://<Server>:<Port>/SAP/BW/DOC/TRAN/FLDTRAN/<Document Name>
Make sure that the name of the document is unique within the document class.
1. You use relative links to link documents that belong to the same document class.
To link to document 02, add the HTML code to document 01, using the following template:
<a href = "Name of document 02"> Text </a>
2. You can enhance the HTML code to link documents that do not belong to the same document class.
For example, if you want to set a link from document 01 (belonging to the META document class) to document 02 (belonging to the TRAN
document class), add the HTML code to document 01 as follows:
<a href = "../../TRAN/FLDTRAN/"Name of document 02"> Text </a>
Stored in Knowledge Management (Migrated Documents)

Portal server
Port
Document Class URL
Metadata http://<Portal Server>:<Port>/irj/go/km/docs/<BI CM Repository Prefix>/<System

Alias>/Metadata/<Object Type>/<Object Name>/<Document Name>
We recommend that you only migrate metadata documents if the metadata is
not going to be transported.
Master data http://<Portal Server>:<Port>/irj/go/km/docs/<BI CM Repository Prefix>/<System

Alias>/MasterData/<Characteristic Name>/<Characteristic Value>/<Document
Name>
InfoProvider data http://<Portal Server>:<Port>/irj/go/km/docs/<BI CM Repository Prefix>/<System

Alias>/InfoProviderData/
Documents that are assigned to InfoProviders and queries:
/<BI CM Repository Prefix>/<System Alias>/InfoProviderData/ <InfoProvider>/
<Query>/ <Document Name>
Documents that are only assigned to InfoProviders (cross query):
/<BI CM Repository Prefix>/<System Alias>/InfoProviderData/ <InfoProvider>/
<Document Name>
Documents that are used across InfoProviders:
/<BI CM Repository Prefix>/<System Alias>/InfoProviderData/ <Document Name>
The <BI CM Repository Prefix> placeholder includes the prefix that is configured for the BI Document Repository Manager (for example, /bi_documents).
The <System Alias> placeholder corresponds to the system alias that is maintained for the system object in the BI system.
For more information about this type of storage, access, and the significance of placeholders, see Migration of Documents into the CM Repository.
1.2.4 BI Security Manager for Documents
Use

The BI Security Manager for Documents protects and controls access to BI documents in Knowledge Management. It can be used for the CM repository, that
is, for documents stored on the portal, and for the BI Document Repository Manager, that is, for documents stored on the BI server.
Features
The BI Security Manager for Documents ensures secure access to documents in the portal by creating a connection to the BI system and checking the user
access authorizations in the back end. This means that you do not need to maintain any additional authorization in KM and can ensure that users in KM can
only display documents for which they have authorization.
The authorization checks performed by the BI Security Manager for Documents can reduce system performance.
The standard ACL Security Manager is faster in terms of performance, but is inappropriate since it requires that the authorizations in the portal
and in the BI system are maintained twice.
If you only want to use documents within BI applications, you do not need a security manager. In the dropdown box, choose Not Set .
In KM you are using an iView for the document search. There are 20 documents in your BI system; ten of these however contain
confidential information that should not be accessed by all users. If you choose the BI Security Manager for Documents for the CM repository,
authorization checks are performed for all 20 documents. If users do not have authorization for the ten confidential documents, they are denied
access to these documents and can only display the ten documents that do not contain confidential information in KM.
Activities
To call the BI Security Manager for Documents configuration, choose System Administration System Configuration Knowledge Management
Repository Managers CM Repository .
1. Set the indicator for the CM repository for which authorizations are to be checked in the BI system when documents are accessed.
2. Then choose Edit .
The properties of the CM repository are displayed in the lower area of the screen.
3. In the dropdown box for the security manager, choose BI Document Security Manager .
1.2.5 Repository Manager for BI
Definition
Repository managers from SAP NetWeaver Business Intelligence enable you to integrate documents and automatically generated metadata documents that
are stored on the BI server into Knowledge Management (KM) of SAP Enterprise Portal. They also enable you to access these documents. The following
repository managers are available:
BI Document Repository Manager
BI Metadata Repository Manager
The BI Document Repository Manager is required to migrate documents from the BI server to the storage of the portal (CM repository). Once the migration is
complete, the BI Document Repository Manager is no longer required.
The BI Metadata Repository Manager integrates documents from the BI system as write-protected documents in KM. The BI Metadata Repository Manager
can be used after migration to access generated metadata documents.
1.2.5.1 BI Document Repository Manager
Definition
Repository manager for documents in SAP NetWeaver Business Intelligence.
Use
The BI Document Repository Manager allows you to integrate documents created in the BI system into Knowledge Management of the portal. The
documents are divided into three document classes: Metadata , Master Data, and InfoProvider Data . The Metadata document class contains manually
created documents using metadata. These documents are not the automatically generated documents from the Metadata Repository. The Master Data
document class contains documents for characteristic values, such as images for personnel numbers, descriptions, and technical specifications for materials.
The InfoProvider Data document class contains documents for a combination of characteristic values, such as comments on key figures.
You can use the Data Warehousing Workbench to create documents or you can create them in Web applications. For more information about displaying,
creating, and changing documents in Web applications, see Using Documents in Web Applications.
Structure
The following information explains the parameters for the BI Document Repository Manager.

Parameters for the BI Document Repository Manager
Parameter Obligatory Description
Description No Description of the repository manager
Prefix Yes URI prefix for which the BI Document Repository

Manager is registered.
The repository is listed in the master directory using this
entry.
The URIs for all resources managed by this repository
manager have this prefix. The prefix is used to identify
the repository manager that is responsible for a
resource with a particular URI. Note that the prefix has
to be entered with a forward slash, for example,
/bi_documents.
The prefix in the BI system must match the prefix in the
portal.
Active + No You can activate or deactivate the repository manager

by setting this parameter.
Hide in Root Folder + No This parameter specifies whether the repository is

listed in the master directory.
If you activate this parameter, the repository is not listed
in the master directory.
Repository Services No Identification of the repository services that you want

to use for a repository.
Property Search Manager Yes Selection of the manager for the property search.
Choose
com.sap.ip.bi.km.repository.manager.bidoc.BidocProp
ertySearchManager.
Security Manager Yes This parameter cannot be changed and specifies the
security manager BI Document Security Manager that
co ntrols access to the repository content. The BI
Document Security Manager provides a connection
to the BI system and checks whether authorizations for
displaying or changing the documents exist.
Send Events + No This parameter specifies whether the repository sends

events when operations such as delete or refresh
content are executed.
The parameter must be activated to allow the repository
to send events. This is necessary, for example, for the
use of services such as the subscription service.
Show empty Folders No If you activate this parameter, you can also display
folders that do not contain any documents. You can
then create new documents in the BI system by
creating new documents in these empty folders using
the repository manager.
If you do not intend to use the repository manager to
create new documents, we recommend that you
deactivate this parameter.
Show technical Names No If you activate this parameter, the technical names of
the BI objects upon which the documents are based
are displayed.
If you deactivate the parameter, you can still see the
technical names of the BI objects using the tooltip.
Read only No This parameter specifies whether the repository is

write-protected.
BI Property Cache No This parameter specifies the cache for BI documents.

By default, the cache is ca_bi_prop . You can also
create a new cache, if required. To do this, choose
Content Management Utilities Caches
Memory Cache . When you set the parameters
Capacity and Default Time-to-Live, take into account
how many documents are accessed simultaneously by
all users. See also: Caches
BI Security Cache No You use this parameter to specify the cache for BI
documents with access authorizations. By default, the
cache is ca_bi_auth . You can also create a new
cache, if required. To do this, choose Content
Management Utilities Caches Memory
Cache . When you set the parameters Capacity and
Default Time-to-Live, take into account how many
documents are accessed simultaneously by all users.
Alias of BI System Yes In this parameter, you enter the alias of the BI system
that you specified in the portal system landscape
directory when you set up the BI system.
The naming convention for the alias is <System

ID>CLNT<MANDT>.
Prefix of BI Metadata Repository No If you are using the BI Metadata Repository Manager in
addition to the BI Document Repository Manager, you
can enter its prefix here. The two repository managers
are now linked and you can, for example, see the
documents created for an InfoObject in addition to the
automatically generated documentation for the
metadata.
If you do not want automatically generated documents
from the Metadata Repository to be displayed, leave
this parameter empty. Any documents for metadata that
you created are still displayed. If the documents for
metadata are already migrated, the generated
metadata documents are no longer displayed.
Configuration
To set up the repository manager for BI documents in the portal, proceed as follows:
1. Log on to the portal.
2. Choose System Administration System Configuration Knowledge Management Content Management Repository Manager
BI Document Repository .
3. Enter the required data.
By choosing Show Advanced Options , you can display a complete list of parameters. A plus sign (+) in the table above denotes advanced
settings options.
Example
Configuration of BI Document Repository Manager
Description = BIDocumentRepositoryManager
Prefix = /bi_documents
Active = activated
Hide in Root Folder = deactivated
Repository services = comment, discussion, properties, rating, subscription

Property Search Manager = com.sap.ip.bi.km.repository.manager.bidoc.BidocPropertySearchManager
Security manager = BIDocumentSecurityManager
Send Events = activated
Show empty Folders = deactivated
Show technical Names = deactivated
Read only = deactivated
BI Property Cache = ca_bi_prop
BI Security Cache = ca_bi_auth

Alias of BI System = BWP_CLNT_000 (<BI System ID>CLNT<MANDT>)
Prefix of BI Metadata
Repository = /bi_metadata
More Information:
Document Structure for Metadata
Document Structure for Master Data
Document Structure for InfoProvider Data
1.2.5.2 BI Metadata Repository Manager
Definition
Repository manager for metadata in SAP NetWeaver Business Intelligence.
Use
The BI Metadata Repository Manager allows you to integrate the metadata created in the BI system (InfoCubes, queries, Web templates, workbooks, and so
on) and their associated documents into Knowledge Management of the portal as write-protected documents. Furthermore, the BI Metadata Repository
Manager allows you to access online links created with BEx Information Broadcasting.
The BI Metadata Repository Manager allows you to access automatically generated HTML-based documents for metadata. The documents correspond to the

information in the Metadata Repository in the Data Warehousing Workbench. In addition, you can create manual documents for metadata, which can be
integrated into Knowledge Management using the BI Document Repository Manager.
Structure
The following information explains the parameters for the BI Metadata Repository Manager.
Parameters for the BI Metadata Repository Manager
Parameter Obligatory Description
Description No Description of the repository manager
Prefix Yes URI prefix that the BI Metadata Repository Manager is

registered for.
The repository is listed in the master directory using this
entry.
The URIs for all resources managed by this repository
manager have this prefix. The prefix is used to identify
the repository manager that is responsible for a
resource with a particular URI. Note that the prefix has
to be entered with a forward slash, for example,
/bi_metadata.
The prefix in the BI system must match the prefix in the
portal.
Active + No You can activate or deactivate the repository manager

by setting this parameter.
Hide in Root Folder + No This parameter specifies whether the repository is

listed in the master directory.
If you activate this parameter, the repository is not listed
in the master directory.
Repository Services No Identification of the repository services that you want

to use for a repository.
Property Search Manager Yes Selection of the manager for the property search.
Choose
com.sap.ip.bi.km.repository.manager.mo.MoPropertyS
earchManager .
Security Manager Yes This parameter cannot be changed and specifies the
security manager BI Metadata Security Manager .
This controls access to the repository content. The BI
Metadata Security Manager provides a connection to
the BI system and checks whether authorizations for
displaying metadata exist.
Send Events + No This parameter specifies whether the repository sends

events when operations such as delete or refresh
content are executed.
The parameter must be activated to allow the repository
to send events. This is necessary, for example, for the
use of services such as the subscription service.
Lock Manager No Leave this field empty.
Show objects data is received from No In data flow before:

If you activate this parameter, links to the online
documentation for the object from which the current
object receives data are displayed.
Show Objects Data is Sent To No In data flow afterwards:

documentation for the objects to which the current
object sends data are displayed.
Show technical Names No If you activate this parameter, the technical names of
the BI objects upon which the documents are based
are displayed.
If you deactivate the parameter, you can still see the
technical names of the BI objects using the tooltip.
Show Usage No Where-used list:

documentation for the objects that the current object
uses are displayed.
BI Property Cache No This parameter specifies the cache for BI documents.

By default, the cache is ca_bi_prop . You can also
create a new cache, if required. To do this, choose
Content Management Utilities Caches
Memory Cache . When you set the parameters
Capacity and Default Time-to-Live , take into
account how many documents are accessed
simultaneously by all users. See: Caches

BI Security Cache nein You use this parameter to specify the cache for BI
documents with access authorizations. By default, the
cache is ca_bi_auth . To do this, choose Content
Management Utilities Caches Memory
Cache . When you set the parameters Capacity and
Default Time-to-Live , take into account how many
documents are accessed simultaneously by all users.
Alias of BI System Yes In this parameter, you enter the alias of the BI system
that you specified in the portal system landscape
directory when you set up the BI system.
The naming convention for the alias is <System
ID>CLNT<MANDT>.
Prefix of BI Document Repository No If you are using the BI Document Repository Manager
in addition to the BI Metadata Repository Manager, you
can enter its prefix here. The two repository managers
are now connected and you are able to see not only
the metadata and its documentation, but also the
corresponding documents.
Configuration
To set up the repository manager for BI metadata in the portal, proceed as follows:
1. Log on to the portal.
2. Choose System Administration System Configuration Knowledge Management Content Management Repository Manager
BI Metadata Repository .
3. Enter the required data.
By choosing Show Advanced Options , you can display a complete list of parameters. A plus sign (+) in the table above denotes advanced
settings options.
For performance reasons, we recommend that you deactivate the following parameters:
Show objects data is received from (data flow before)
Show objects data is sent to (data flow after)
Show usage (where-used list)
For central objects, the where-used list or data flow lists a large number of objects, which makes the online documentation extensive. As a
result, it can take some time to build the online documentation. See also Tab Page: Online Documentation.
Example
Configuration of a BI Metadata Repository Manager
Description = BIDocumentRepositoryManager
Prefix = /bi_metadata
Active = activated
Hide in Root Folder = deactivated
Repository Services = comment, properties

Property Search Manager = com.sap.ip.bi.km.repository.manager.mo.MoPropertySearchManager
Security Manager = BIMetadataSecurityManager
Send Events = activated
Lock Manager = deactivated
Show Objects data is received from = deactivated
Show Objects data is sent to = deactivated
Show technical Names = deactivated
Show usage = deactivated

BI Property Cache = ca_bi_prop
BI Security Cache = ca_bi_auth
Alias of BI System = BWP_CLNT_000 (<System ID>CLNT<MANDT>)
Prefix of BI Document Repository = /bi_documents
More Information:
Document Structure for Metadata
Document Structure for Master Data
Document Structure for InfoProvider Data

1.3 OLAP
Purpose
SAP NetWeaver Business Intelligence uses OLAP technology to analyze the data that is stored in the data warehouse. Online Analytical Processing (OLAP)
characterizes business intelligence as a Decision Support System since it allows decision makers to analyze multidimensionally modeled data quickly and
interactively in accordance with business management needs.
InfoProviders provide the view of the data. Because the data in InfoCubes is stored in a read-optimized form, InfoCubes and MultiProviders based on
InfoCubes are the preferred InfoProvider.
Integration
The OLAP Processor, a component of the BI server, lies between the user and the database: It makes the multi-dimensionally formatted data available to
both the BI front end and, using special interfaces (Open Analysis Interfaces) to third-party administrator front ends too. For this reason, the OLAP processor
is optimized for the analysis and reporting of very large datasets. Users can request ad hoc individual views of business-relevant data using the Business
Explorer (see BI Suite: Business Explorer).
The following graphic displays the status and tasks of the OLAP processor within the data processing process when a multidimensional analysis is executed:
Queries are the basis of every analysis in SAP NetWeaver Business Intelligence. To formally define a multidimensional request, a query determines:
the structure analog to a worksheet (see Structures, Defining Restricted Key Figures, Defining Calculated Key Figures, Defining Exception Cells).
the filter that affects this structure
the navigation space (free characteristics) (see Restricting Characteristics).
The BI system has a number of analysis and navigation functions for formatting and evaluating a companys data. These allow the user to formulate individual
requests on the basis of multi-dimensionally modeled datasets (InfoProviders). Subsequently the user is able to view and evaluate this data from different
perspectives at runtime. The overall functionality for retrieving, processing and formatting this data is provided by the OLAP processor.
In the context of BI Integrated Planning, you can use input ready queries for manual planning. For more information, see BI Integrated Planning and Input
Ready Queries.
Features
The following table offers an overview of the OLAP functions and services implemented in the analytic engine of SAP NetWeaver Business Intelligence.
For more information, see Special OLAP Functions and Services, Performance Optimization and the BI Suite: Business Explorer section.
OLAP functions and services: an overview
OLAP Function Operations in Detail
Navigation Drilldown to characteristic / structure element. Remove element drilldown from the
view (dice)
Expand ( drilldown ) and hide ( drill up ) hierarchy nodes
Exchange drilldown elements (swap)
Filtering Restrict (slice) characteristics to selections (single value, value range, hierarchy
element, exclusion)
Aggregation Standard aggregation: Default, key figure-dependant calculation formula for the
aggregation of single result values)
Exception aggregation: Special aggregation setting in relation to a particular
characteristic. For example, aggregation average of account balance with reference
to the characteristic time
Local aggregation or local calculation: (for example, the calculation of individual
values displayed for normalizing from the overall result)
Layout Layout of the characteristics as key / description

Display / suppress results rows
Change position of hierarchy nodes (up / down)
Result-dependant selection and layout Threshold values (exceptions): (Colored highlighting of uncommon variance in
key figure values)
Conditions: (Key figure-dependent restriction of characteristics according to
defined conditions)
Structuring Hierarchical assignment of characteristic values with drill down for more than one
element (Universal Display Hierarchy)
Generic and business analysis functions Sorting with reference to characteristics and key figures
Calculated key figures and formulas (enables statistical and mathematical
calculation on the basis of key figure values)
Currency translation
Elimination of internal business volume: (business elimination of internal
transactions)
Concepts for optimizing runtime Non-cumulatives

Aggregates
OLAP Cache (can be implemented in cache mode, depending on the query)
Integrated additional functions Variables for parameterization and increased reusability of queries
Report-report interfaces for navigation in different reports
Authorization concept for controlling user authorizations with reference to
accessing data
1.3.1 Special OLAP Functions and Services
Purpose
For an overview of the OLAP functions and services implemented using SAP NetWeaver Business Intelligence, see OLAP.
Features
The following sections describe some of the special OLAP functions of BI in detail:
To be able to calculate the values of key figures, the OLAP Engine aggregates the data of the InfoProvider to the detail level of the query at aggregation.
More information: Aggregation
You can use hierarchies to model values of a characteristic, characteristic attributes, and dimensions of an InfoCube in structured form.
More information: Hierarchies
You can use the Elimination of Internal Business Volume function to eliminate sales volumes relating to movements between two cost centers within
the company when executing a BEx query.
More information: Elimination of Internal Business Volume
You can use currency translation to translate the key figures with currency fields that exist in the source system in different currencies into a standard
currency in the BI system (for example, the local currency or company currency).
More information: Currency Translation
Quantity conversion allows you to convert key figures with units that have different units of measure in the source system into a uniform unit of measure
in the BI system.
More information: Quantity Conversion
Local calculations enable the recalculation of single values and results in accordance with specific criteria. For example, you can create ranked lists or
you can calculate the total for a Top 10 product list locally in the executed query.
More information: Local Calculations
You can use the Constant Selection function to ensure that a defined selection in the Query Designer cannot be changed by navigation and filtering in the
executed query. This allows you to select reference sizes that do not change at runtime.
More information: Constant Selection
Analysis authorizations are required by all users that want to display data from authorization-relevant characteristics or navigation attributes in a query.
More information: Analysis Authorizations
The report-report interface allows you the flexibility to call a jump target (receiver) online from a BEx query (sender) within or outside of the BI system.
Queries, transactions, reports, and Web addresses can be jump targets.
More information: Report-Report Interface
With SAP NetWeaver BI you can run various analysis scenarios. You can find the relevant information in the following sections:
You create slow-moving item lists to enable the display of characteristic values for which no data is available in the InfoProvider. This allows you to
determine characteristic values with NULL values.
More information: Example: List of Slow-Moving Items
The suppression of zero rows and columns allows you to hide rows and columns that contain only zero values (0.00).
More information: Suppression of Zero Rows and Zero Columns
You can use the Constant Selection function to generate a market index for displaying the sales volume values of products in relation to a product
group, for example.
More information: Example: Market Index
Detailed example scenarios are available in the Data Warehouse for selected OLAP functions. These scenarios already contain all objects (InfoProviders with
master data and transaction data and queries) that you need to execute the functions (for example, Elimination of Internal Business Volume) for example
purposes.

More information: SAP DemoContent for Features
1.3.1.1 Aggregation
Use
To enable the calculation of key figures, the data from the InfoProvider has to be aggregated to the detail level of the query and formulas may also need to be
calculated. The system has to aggregate using multiple characteristics. In regard to a selected characteristic, the system can aggregate with another rule for
each key figure (exception aggregation).
Features
During aggregation, the OLAP Engine in BI proceeds as follows:
1. First, standard aggregation is executed. Possible aggregation types include summation (SUM), minimum (MIN) and maximum (MAX). Minimum and
maximum can, for example, be used for date key figures.
2. Aggregation using a selected characteristic occurs after standard aggregation (exception aggregation). The available exception aggregation types include
average, counter, first value, last value, minimum, maximum, no aggregation, standard deviation, summation, and variance. Application cases for
exception aggregation include warehouse stock, for example, that cannot be totaled over time, or counters that count the number of characteristic values
for a certain characteristic. See also: Examples in the Data Warehousing Workbench.
3. Lastly, aggregation using currencies and units is executed. A * is output when two numbers that are not equal to zero are aggregated with different
currencies or units. See also: Currency Translation.
Formulas are calculated once the numbers have been completely aggregated. There are three exceptions to this rule:
For the key figure, a calculation time was selected in which the calculation of the formula is to be done before aggregation. See the section Tab Page
Aggregation in Selection/Formula Properties.
When using a formula variable with replacement from an attribute value in a calculated key figure. See the section Tab Page Aggregation in
Selection/Formula Properties.
During a currency translation that was set up in the Query Designer. See Currency Translation in the Business Explorer.
The sequence in which the values are calculated affects the result of the query. See also the example for the interpretation of query results.
The aggregation types are set during the definition of the key figure. See also: Tab Page: Aggregation. This section contains a detailed description of the
aggregation types.
You can override the aggregation settings using settings in the query (in the Query Designer, BEx Web applications, and the BEx Analyzer). See also:
Calculate Results As and Calculate Single Values As (local aggregation).
You can define the aggregation behavior for formulas and calculated key figures in the Query Designer. See also: Examples in the BEx Query Designer.
Examples in the Data Warehousing Workbench
Examples of Exception Aggregation: Last Value and Average
Non-Cumulative Key Figures:

An example of the use of standard aggregation and exception aggregation for a key figure is a key figure for the non-cumulative value (non-cumulative key
figure).
For non-cumulative key figures such as warehouse stock, you want to summate the warehouse stock relating to various articles and warehouse (standard
aggregation), but determining the final count relating to month (LAST aggregation) (exception aggregation relating to the time characteristic Calendar Month ).
See also: Aggregation Behavior of Non-Cumulative Key Figures.
Numerator:
A further example of the use of standard aggregation and exception aggregation for a key figure is the key figure as a numerator.
You have, for example, an InfoCube called Performance Appraisal :
Pers. No. Type of Appraisal Year No. of Performance Appraisals
4711 Potential assessment 2002 1
4711 Goal achievement 2002 0
4711 Performance appraisal 2002 1
4712 Potential assessment 2002 1
4712 Goal achievement 2002 0
A query would deliver the following result:

Employee 4711 would be counted twice because the different appraisal types are added together, which would make the result incorrect. To avoid this, the key
figure No. of Performance Appraisals has an exception aggregation (for example, Average (Values Unequal to Zero) ) for the characteristic Appraisal Type .
Then the No. of Performance Appraisals is not totaled.
The query then appears as follows:
Examples of Exception Aggregation: Average (AV1)

You want to calculate the average of an overall value by day. The query looks like this:
From Date To Date Period of Time in Days Value Period of Time in Days
Multiplied by Value
20050618 20050620 2 3 6
20050620 20050625 5 2 10
20050625 20050629 4 2 8
20050629 20050630 1 27 27
20050630 20050708 8 44 352
20050708 20050807 30 1 30
20050807 20050807 1 0 0
Sum 51 79 433
You calculate the average as follows:

433 51 = 8.490
To get this result, the key figure must have the exception aggregation Average (AV1), relating to the characteristic Calendar Day (0CALDAY).
For a key figure with the exception aggregation Average (AV1) relating to the characteristic Calendar Month (0CALMONTH), the result is as follows:
From Date To Date Period of Time in Days Value Period of Time in Days
Multiplied by Value
200506 200506 30 3 90
200506 200506 30 2 60
200506 200506 30 2 60
200506 200506 30 27 810
200506 200507 61 44 2684
200507 200508 62 1 62
200508 200508 31 0 0
Sum 274 79 3766
You calculate the average as follows:

3766 274 = 13.744
1.3.1.1.2 Examples in the BEx Query Designer
Example of Exception Aggregation: Counting

The scenario below shows you how to count the results of a calculated key figure in the BEx Query Designer.
You have loaded the following data into your InfoCube:
Region Customer Sales Volume

USD
NY A 400,000
B 200,000
C 50,000
CA A 800,000
C 300,000
You want to use the query to determine the number of customers for which the sales volume is less than 1,000,000 USD. To do so, you create the calculated
key figure Customer sales volume <= 1.000.000 (F1) with the following properties:
General tab page: Formula definition: Sales Volume <= 1.000.000
Aggregation tab page: Exception Aggregation: Total, Ref. Characteristic: Customer
This query would deliver the following result:
Region Customer Sales Volume F1
USD
NY A 400,000 1
B 200,000 1
C 50,000 1
Result 650,000 3
CA A 800,000 1
C 300,000 1
Result 1,100,000 2
Overall result 1,750,000 2
The overall result of the calculated key figure F1 is calculated as follows: Sales volume of customer A (400,000 + 800,000) -> does not fulfill
condition (sales volume <= 1,000,000) -> 0: sales volume of customer B (200,000) -> fulfills condition -> 1; sales volume of customer C
(50,000 + 300,000) -> fulfills condition -> 1. When totaled, this gives 2 as the overall result for F1.
A query with a drilldown by region would give the following result:
Region Sales Volume F1
USD
NY 650,000 3
CA 1,100,000 2
Overall result 1,750,000 2
Due to the assignment of the reference characteristic Customer to the calculated key figure F1 for the exception aggregation, the query also
delivers the required data without a drilldown by reference characteristic.
Example of Exception Aggregation: Enhanced Counting

The scenario below shows you how to count the results of different calculated key figures in the BEx Query Designer. The data from the following example is
enhanced for the purposes of this example: Example of Exception Aggregation: Counting.
You have loaded the following data into your InfoCube:
Country Region Customer Sales Volume
USD
US NY A 400,000
B 200,000
C 50,000
CA A 800,000
C 300,000
In the query, you do not want to determine the number of customers for which the sales volume totals less than 1,000,000 USD (see Example of Exception
Aggregation: Counting) - you want to determine the following values instead:
Number of customers with sales volume between 100,000 and 1,000,000
Number of customers with sales volume between 100,000 and 1,000,000 in at least one region
To be able to calculate these values, you have to create the following calculated key figures:
F1: Customers with sales volume <= 1,000,000
General tab page: Formula definition: Sales Volume <= 1,000,000

F2: Customers with sales volume between 100,000 and 1,000,000
General tab page: Formula definition: (Sales Volume >= 100,000) AND (Sales Volume <=1,000,000)
F3: Customers with sales volume between 100,000 and 1,000,000 in at least one region
For this key figure, you require the secondary key figure S1 (for the aggregation of regions with a sales volume between 100,000 and 1,000,000 USD).
General tab page: Formula definition: (Sales Volume >= 100,000) AND (Sales Volume <=1,000,000)
Aggregation tab page: Exception Aggregation: Maximum, Ref. Characteristic: Region Code
The secondary key figure (S1) is used in F3:
General tab page: Formula definition: Secondary key figure (S1)
This query would deliver the following result:
Country Region Customer Sales Volume F1 F2 F3
USD
US NY A 400,000 1 1 1
B 200,000 1 1 1
C 50,000 1 0 0
Result 650,000 3 2 2
CA A 800,000 1 1 1
C 300,000 1 1 1
Result 1,100,000 2 2 2
Overall result 1,750,000 2 2 3
The overall result of the calculated key figure F2 is calculated as follows:

Sales volume of customer A (1,200,000) -> does not fulfill condition (sales volume between 100,000 and 1,000,000) -> 0; sales volume of customer B
(200,000) fulfills condition -> 1; sales volume of customer C (350,000) fulfills condition -> 1. When totaled, this gives 2 as the overall result for F2.
The overall result of the calculated key figure F3 is clarified by the table below:
Customer Country Region Sales Volume F1 F2 F3 S1
USD
A US NY 400,000 1 1 1 1
CA 800,000 1 1 1 1
Result 1,200,000 0 0 1 1
B US NY 200,000 1 1 1 1
Result 200,000 1 1 1 1
C US NY 50,000 1 0 0 0
CA 300,000 1 1 1 1
Result 350,000 1 1 1 1
Overall result 1,750,000 2 2 3 0
1.3.1.2 Hierarchies
Purpose
In SAP NetWeaver Business Intelligence there are different options for modeling hierarchical structures. The following table gives you an overview:
Hierarchy Type Description
Hierarchy definition for characteristics
Characteristic hierarchy Characteristic values of a characteristic in a tree structure. Characteristic

hierarchies are stored in their own data tables. Like master data, they can be used
in all InfoProviders.
Example: Hierarchy of cost centers that are assembled in cost center groups.
Determining hierarchical structures in InfoCube modeling
In the dimensions of an InfoCube Example: Time dimension. The definitions of InfoObjects 0CALDAY, 0CALMONTH,
and 0CALYEAR form a hierarchy.
Example: 04.09.2003 04.2003 2003
Specification of hierarchical structures in InfoCube maintenance
In the attributes of a characteristic Example: The definitions of InfoObjects 0MATERIAL, 0MATL_GROUP,

0MATL_TYPE, and 0IND_SECTOR form a hierarchy.
To use attributes in the query as hierarchy levels, they have to be defined as
navigation attributes.
The most appropriate type of modeling depends on the individual case. The modeling types differ, for example, with regard to how data is stored in the source
system, performance, authorization checks, the use of aggregates, or whether parameters can be set for the query. You can find a comparison of the three
types of hierarchy modeling under Options for Hierarchical Modeling.
In addition, you can organize the elements of a structure hierarchically in query definition. Hierarchies for characteristics are not required for
these functions.
You can display one or both axes (rows and columns) as a hierarchy.
For more information about the Structures with Hierarchical Display and Display as Hierarchy ( Universal Display Hierarchy ) functions for
the BEx Analyzer, see Working with Hierarchies.
You can use the Display as Hierarchy function to display the different ways of modeling hierarchical structures (named in the table above) in
essentially the same format in the query.
The following sections deal exclusively with the maintenance of characteristic hierarchies.
Avoid grouping properties that belong to semantically different dimensions such as Time, Product, Customer, and Countries in one
artificial characteristic.
Example: Distribution Channel and Product Group in artificial characteristic Profit Center .
If you want to define characteristic hierarchies to use in reporting to display different views, we do not recommend that you code separate
dimensions in one artificial characteristic. This has the following drawbacks:
The hierarchies are unnecessarily large. System performance is negatively affected during reporting. (A hierarchy can include at most
50,000 100,000 leaves, see Creating Hierarchiessap.)
Comprehensive change runs occur too frequently.
Characteristic hierarchies also allow you to create queries for reporting in several ways. In the Query Designer you can use characteristic hierarchies in the
following ways:
As a display hierarchy for a characteristic, if this needs to be displayed as a hierarchy (see Characteristic Propertiessa)
As a selection for specific characteristic values, if a characteristic needs to be restricted to a hierarchy or to hierarchy nodes (see Restricting
Characteristics: Hierarchiessa)
Integration
In InfoObject maintenance you have to specify whether a characteristic can have hierarchies (see Creating InfoObjects: Characteristic). A characteristic of
this type is called a hierarchy basic characteristic.
Hierarchies have to (and can only) be created for hierarchy basic characteristics. All characteristics that reference a hierarchy basic characteristic
automatically inherit the corresponding hierarchies. A hierarchy basic characteristic can have as many hierarchies as required.
An example of a hierarchy basic characteristic is 0COSTCENTER.

In InfoObject maintenance, the properties of all the hierarchies for the respective characteristic are defined (see Hierarchy Properties).
Features
Loading hierarchies
You can load characteristic hierarchies into your BI system:
From a source system
Using the scheduler in the Data Warehousing Workbench (see Loading Hierarchiess)
Using a process chain (see Loading Hierarchies Using Process Chainssa)
From or into another BI system
Using the data mart interface. You cannot transport hierarchies into another BI system because hierarchies are data (see Using the Data Mart
Interfacesap).
Creating hierarchies
You can create characteristic hierarchies in your BI system.
Note that the size of the hierarchy influences performance (see Creating Hierarchies).
Editing hierarchies
In hierarchy maintenance for the BI system, you can change, copy, delete, or set reporting-relevant hierarchy attributes in characteristic hierarchies (see
Editing Hierarchies).
Activating hierarchies
To use hierarchies in reporting, you have to activate your hierarchies (see Editing Hierarchies).
The BI system predefines all useful hierarchies for time characteristics. Activate a useful selection from the complete list of proposals (see Activating Virtual
Time Hierarchies).
Modifying hierarchy changes

When you create or load new hierarchies you also need to create the corresponding aggregates. When you change a hierarchy or activate a changed
hierarchy, all existing aggregates are modified automatically (see System Response Upon Changes to Master Data and Hierarchies).
The system likewise modifies BI accelerator indexes during hierarchy and attribute change runs (see System Response Upon Changes to Data: BI

Accelerator Index).
1.3.1.2.1 Options for Hierarchical Modeling

Comparison of modeling in different hierarchical structures
Characteristic Hierarchy Hierarchical Structures in InfoCube Dimensions or Hierarchical Structures in Attributes Characteristics
DataStore Objects
As Posted view is not possible. As Posted view is possible. As Posted view is not possible.
Different views (such as version, key date) of the data Different data views are not possible. Exception: The
are possible. view for the key date is possible if the characteristic or
respective attributes are time dependent.
Cross-InfoProvider Only valid for an InfoProvider Cross-InfoProvider, because it is modeled in the master
data.
Changeable Not changeable, unless you reload the InfoProvider. Changeable (with master data changes or with the
addition of attributes).
Drill-down path is defined by the structure. Drill-down path is not defined by the structure. Levels Drill-down path is not defined by the structure. Levels
can therefore be skipped. can therefore be skipped.
Duplicate leaves are always displayed. Duplicate leaves are only possible in As Posted view. Duplicate leaves are not possible.
Balanced and unbalanced hierarchies are possible. Hierarchy structures have to be balanced. Hierarchy structures have to be balanced.
The following sections deal exclusively with the maintenance of characteristic hierarchies.
Example
The following graphic shows a sales hierarchy as a typical example of a characteristic hierarchy in the BEx Analyzer.
The following graphic shows a hierarchical structure modeled in the dimensions of an InfoCube in the BEx Analyzer.
Using the Display as Hierarchy (Universal Display Hierarchy) function, you can also display the modeling as a tree in the query, like the characteristic
hierarchy shown above (see Working with Hierarchies).

1.3.1.2.2 Hierarchy Nodes
Definition
Hierarchy nodes are components of a characteristic hierarchy. A characteristic hierarchy is assigned to a hierarchy basic characteristic and therefore is
affected by the valid hierarchy properties Version Dependency , Time Dependency , Interval , and Sign Reversal for all hierarchies assigned to this
characteristic (see Hierarchy Properties).
The structure of a characteristic hierarchy is defined by the link relationships among the hierarchy nodes.
Each node has exactly one parent node (predecessor). The depth (the level) of the node corresponds to the number of its predecessors increasing up to
the root of one. This means that the roots have level 1.
The assigned quantity of children or subnodes (successors) is assigned to each node. The degree of a node corresponds to the number of its
successors.
Nodes that show special features in one of the two relationships are roots (nodes) and leaves. All nodes are indicated as inner nodes whose degree is
not zero, meaning they have successors.
With regard to the structure of a hierarchy, the hierarchy nodes are assembled into hierarchy levels and subtrees.
Depending on whether a node refers to a hierarchy basic characteristic or not, we differentiate postable and not postable nodes.
All nodes (except for leaves and link nodes) can only occur once in a hierarchy. You can find additional information under Modeling Nodes and Leaves and
Link Nodes.
Structure
Special hierarchy nodes
Hierarchy Nodes Description
Root (nodes) A node that is not assigned under any node and has no parent node (predecessor).
A hierarchy can have more than one root node.
Leaf A node without lower-level nodes (successors). Leaves are postable, but are not
postable nodes (see table below Postability of Nodes).
Leaves are always characteristic values for the hierarchy basic characteristic.
Value specification: The value is moved from the InfoProvider.
Interval A quantity of leaves that are indicated by their lower and upper limit.
Inner nodes A node having successors, meaning all nodes except for leaves.
Grouping of hierarchy nodes
Grouping Description
Hierarchy level A hierarchy level consists of all nodes with the same depth.
Root nodes have depth (level) 1. The depth of a node corresponds the number of
parent or grandparent nodes up to the root node + 1 (increased by one)
A hierarchy can have a maximum of 98 levels. Each level can have a name.
Subtree A subtree includes a node (root node of the subtree) with its lower-level or
subnodes.
Nodes that are on the border of a subtree are called border nodes. This is important
for hierarchy authorizations (see Maintaining Authorizations for Hierarchies).
Postability of nodes
Postability Description
Postable nodes A node that corresponds to a characteristic value for the hierarchy basic
characteristic.
(A node that corresponds to a characteristic value for a characteristic that
references the hierarchy basic characteristic. This definition includes the hierarchy
basic characteristic.)
In contrast to a leaf, additional nodes or leaves are assigned under a postable
(inner) node.
Value specification: The value of a postable node is specified by the aggregation of
the values of its lower-level nodes and of its value in the InfoProvider. You can find
an example under Modeling Nodes and Leaves.
Not postable nodes A node that does not refer to a hierarchy basic characteristic and is not a postable
node (see Text Nodes, External Characteristic Nodes ).
Value specification: The value of a node that is not postable is specified by the
aggregation of the values of its children nodes.
Text nodes A text node is a new, artificial term. Text nodes are special characteristic nodes
for the artificial characteristic 0HIER_NODE.
External characteristic nodes A node that is identified by any specification of any InfoObject is an external
characteristic node .

In order to be able to use a characteristic in the hierarchy as an external
characteristic node, this has to be explicitly selected in the InfoObject maintenance
for the hierarchy basis characteristic.
Not assigned The system automatically creates a root node REST_H, under which all
characteristic values hang. These characteristic values exist in the master data, but
are not explicitly arranged in the hierarchy.
The node Not Assigned guarantees that no data is lost when activating a
presentation hierarchy (see Characteristic Properties). In the query, this node is
always collapsed first and also does not react to Expand to Level . However, it can
be explicitly opened.
Hierarchy balance
Hierarchy type Description
Unbalanced A hierarchy whose leaves are on different levels is called an unbalanced hierarchy.
If different sources of information are delivered with a different degree of detail (for
example, one to the Material level, another only to the Material Group level), this
can cause unbalanced hierarchies (see the example below).
Balanced A hierarchy whose leaves have all the same depth is called a balanced hierarchy.
A balanced hierarchy, in which all nodes for a level have the same semantics (such
as characteristic nodes with the same characteristic), is called a Named Level
Hierarchy (see example 1 below). In the level maintenance you can assign the
levels for the respective texts (see Level Maintenance).
Typical examples of these hierarchies are geographic hierarchies, for example, with
the levels Continent Country State Region City or time hierarchies (see the
example below).
SAP NetWeaver Business Intelligence can process both balanced as well as unbalanced hierarchies without restriction.
Example
Example 1
The following graphic gives an example of a hierarchy for InfoObject Month 0CALMONTH to illustrate the relationships between the hierarchy nodes and their
grouping in hierarchy levels.
This time hierarchy is a typical example of a balanced hierarchy. It has several root nodes because the nodes with characteristic values 2002 and 2003 for the
InfoObjects transferred in addition to the time characteristic Year 0CALYEAR ( external characteristic node ), do not commonly hang under a special parent
node (like a text node Year ).
The hierarchy has three levels. Since each level corresponds to an InfoObject (0CALYEAR, 0CALQUARTER, 0CALMONTH), it concerns a Named Level
Hierarchy .
Postable nodes are green, while nodes that cannot be posted are displayed in yellow. The definition of the nodes 1.2002/0CALQUARTER and
1.2003/0CALQUARTER are equivalent. The specification of intervals as a summary of several leaves only serves as a more comfortable entry, but is not a
new structure component.
Example 2a
The following graphic gives an example of a hierarchy for InfoObject Customer to illustrate the relationships between the hierarchy nodes and their grouping in
hierarchy levels. This customer hierarchy is a typical example of an unbalanced hierarchy and only has one root node. Postable nodes and leaves are green,
while nodes that cannot be posted are displayed in yellow.

Example 2b
The following graphic gives an example of a hierarchy for the InfoObject Customer to illustrate the display of such a hierarchy for the time of your modeling in
the hierarchy maintenance. The different node types are displayed as follows:
Folder symbol: Text nodes, in this case the root node Customer Hierarchy
Yellow InfoObject symbol: Nodes that cannot be posted with characteristic values for the additionally transferred InfoObjects Region ( External
Characteristic Nodes ) in the customer hierarchy
Green InfoObject symbol: Postable nodes and leaves for the InfoObject Customer
See also:
Link Nodes
Loading Data as Subtrees
Creating Hierarchies
Modeling Nodes and Leaves
Editing Hierarchies
Hierarchy Properties
1.3.1.2.2.1 Link Nodes
Definition
A link node is a hierarchy node that refers to another hierarchy node, which is known as the original node.
Use
With a link node you can hang the subtree that is under the corresponding, original node several times in a hierarchy.
Structure

The link node has the same name (NODENAME) as the original node externally, while internally it keeps another ID (node ID).
The link node succeeds all properties and subtrees for the original node. It has no children of its own. The children transferred from the original node are not
displayed in the hierarchy maintenance.
Link and original nodes differ with regard to their parent nodes and neighboring nodes.
These special features are expressed by the indicator that is set with the link node.
Integration
Loading link nodes
The link node has its own NODEIDand PARENTID when loading. The CHILDID has to be blank. NODENAME, INFOOBJECT, and the time intervals (fields of the
from-to date), if necessary, are identical to the values for the original node. The link indicator must be set.
You can find additional information using the named fields under Downloading Hierarchies from Flat Files.
Example
The following graphic illustrates how a specific, customer organization hangs both under the Sales Organization New York as well as under the Sales
Organization California .
In the hierarchy maintenance, only the link node is displayed as a reference to the original. The arrow clarifies this relationship. In the query, the children nodes
transferred from the original node are contrasted here in white.
The value is not counted twice for the overall total Sales Organization USA.
See also:
1.3.1.2.3 Loading Hierarchies
Use
You can load hierarchies from different source systems:
From an SAP system
Since the metadata is already delivered, you can directly load the standard hierarchies from an SAP system.
From an external system (BAPI, file)
If you want to load hierarchies from an external system, you have to first maintain the metadata for this hierarchy.
Furthermore, you can load hierarchies using the data mart interface from another BI system. See Hierarchies and Using the Data Mart
Interface.
Prerequisites
In InfoObject maintenance, the indicator With Hierarchies is set for the hierarchy basic characteristic. This means that the characteristic can have
hierarchies.
If you load a hierarchy, you must have selected the permitted characteristics in the InfoObject maintenance. See Tab Page: Hierarchy in the InfoObject
maintenance.
To load hierarchies from external systems, you have to edit the metadata in the transfer structure maintenance. See Uploading Hierarchies from Flat Files.

Procedure
1. In the Data Warehousing Workbench under Modeling , select the InfoSource tree.
2. Select the InfoSource (with direct update) for the InfoObject, to which you want to load the hierarchy.
3. Choose Additional Functions Create Transfer Rules from the context menu of the hierarchy table object for the InfoObject. The Assign Source
System dialog box appears.
4. Select the source system from which the hierarchy is to be loaded. The InfoSource maintenance screen appears.
If the DataSource only supports the transfer method IDoc, then only the transfer structure is displayed (tab page DataSource/Transfer Structure ).
If the DataSource also supports transfer method PSA, you can maintain the transfer rules (tab page Transfer Rules ).
If it is possible and useful, we recommend that you use the transfer method PSA and set the indicator Expand Leaf Values and Node
InfoObjects . You can then also load hierarchies with characteristics whose node name has a length >32.
5. Save your entries and go back. The InfoSource tree for the Data Warehousing Workbench is displayed.
6. Choose Create InfoPackage from the context menu (see Maintaining InfoPackages). The Create InfoPackage dialog box appears.
7. Enter the description for the InfoPackage. Select the DataSource (data element Hierarchies ) that you require and confirm your entries.
8. On the Tab Page: Hierarchy Selection, select the hierarchy that you want to load into your BI system.
Specify if the hierarchy should be automatically activated after loading or be marked for activation.
Select an update method ( Full Update, Insert Subtree, Update Subtree ).
More information: Loading Data as Subtrees

If you want to load a hierarchy from an external system with BAPI functionality, make BAPI-specific restrictions, if necessary.
9. If you want to load a hierarchy from a flat file, maintain the tab page: external data.
10. Maintain the tab page: processing.
11. Maintain the tab page: updating.
12. To schedule the InfoPackage, you have the following options:
(Manually) in the scheduler, see Scheduling InfoPackages
(Automatically) using a process chain (see Loading Hierarchies Using a Process Chain)
When you upload hierarchies, the system carries out a consistency check, making sure that the hierarchy structure is correct. Error messages
are logged in the Monitor. You can get technical details about the error and how to correct it in the long text for the respective message.
Result
The hierarchy structure and the node texts or intervals are loaded. The structure information and the hierarchy texts are stored in the BI system. You can edit
the hierarchy.
In order to be able to use the hierarchy in reporting, the hierarchy has to be activated. If you have not selected the indicator for Loading Hierarchyand Note
for Activation or Activate in the InfoPackage, you can activate the hierarchy later (see Editing Hierarchies).
If there are aggregates for a hierarchy and the hierarchy is marked for activation, it is activated after the next change run.
Loading Hierarchies Using a Process Chain
Use
If you want to automatically load and schedule a hierarchy, you can include this as an application process in the procedure for a process chain.
Prerequisites
You have already created an InfoPackage for loading your hierarchy (see Loading Hierarchies)..
Procedure
You can load a hierarchy into a process chain in the following ways:
You can create your process chain from the InfoPackage maintenance by choosing Process Chain Maintenance . The system takes you step by step
through the creation of the process chain.
You can call process chain maintenance directly from the SAP Easy Access Menu : Choose Administration Process Chains . Follow these steps:
1. In the Data Warehousing Workbench symbol bar, choose Process Chains . The Process Chain Maintenance Planning View screen appears.
2. In the left-hand screen area of the required display component, navigate to the process chain in which you want to insert the hierarchy loading
process. Double-click to select it. The system displays the process chain planning view in the right-hand screen area.
If no suitable process chain is available, create a new process chain. More information: Creating Process Chains
3. To insert a process for loading a hierarchy, choose Process Types in the left-hand area of the screen. The system displays the available process
categories.
4. In the process category Loading Process and Postprocessing , choose the application process type Execute InfoPackage .
5. Insert the Execute InfoPackage application process type with drag and drop into the process chain. The dialog box for inserting process variants
appears.
6. Use the input help to select the InfoPackage that you want to include in the process chain.
7. Confirm your entries. Add the processes Save Hierarchy and Change Run to your process chain.

You can specify multiple InfoPackages in this process variant so that multiple hierarchies can be saved with one variant. However, the
sequence specified in the variant is not maintained here. If you do want to keep the sequence, for example when saving hierarchies as a
subtree, you need to insert a Save Hierarchy process after each hierarchy loading process. These Save Hierarchy processes have to be
saved serially, one after the other.
Hierarchy-specific processes
Process Information
Save hierarchy This process always has to be included in a process chain, by which a hierarchy is
loaded. If the Saving Hierarchies process is missing or is not used, the
InfoPackage goes nowhere. This means that the hierarchy is not saved in the BI
system.
Set the indicator for Activate Hierarchies After Loading or Note for Activation if the
hierarchy needs to be automatically saved after the load and activated. The
respective option in the InfoPackage is not sufficient, because it is only used if the
hierarchy loading process (manual) is scheduled using this InfoPackage (see
Loading Hierarchies).
If you do not set the indicator for activating the hierarchy in the process Do Not
Save Hierarchy , only a modified version of the hierarchy (M version) is saved in the
BI system. The hierarchy, however, is not directly activated.
Change Run This process is need if the hierarchy occurs in aggregates.
If you set the indicator for Activate Hierarchies after Loading or Note for
Activation in the Save Hierarchy process and have adopted the Change Run
process in the chain, the hierarchy is activated by the change run.
If you are not using any aggregates, you can delete this process from the process
chain.
Proceed further as described in Creating Process Chains.
Result
You have included your hierarchy loading process in a process chain.
Example
The following graphic illustrates an example of how a process chain is used to load a hierarchy.
Special Features when Loading using the PSA
Use
When loading hierarchies using the PSA transfer method, a much more flexible option is at your disposal for processing hierarchies in comparison with the
Idoc transfer method.

Prerequisites
A hierarchy DataSource from a SAP source system must support loading by using a PSA.
Functions
Error treatment
By storing hierarchies in PSA tables, the system allows you to make manual corrections when errors arise.
The system generates up to 5 PSA tables for a hierarchy DataSource. These tables contain the following hierarchy segments:
Hierarchy header
Texts for hierarchy header
Hierarchy node
Node texts
Intervals
You only need the interval segment when the DataSource supports intervals in hierarchies and this is indicated in InfoObject maintenance.
If you are editing the hierarchy in the PSA, you can select a hierarchy segment in the selection dialog. The system displays each segment individually in a
table.
Flexible attributes for the hierarchy header and hierarchy node

Attributes for the hierarchy header are settings that are valid for the display and processing of the entire hierarchy in the query. You can find additional
information in the table Functions for Displaying and Processing Hierarchies in a BEx Query under Functions of Hierarchy Processing.
Attributes for hierarchy nodes are hierarchy attributes that are selected for the hierarchy basic characteristic in InfoObject maintenance and which are valid
for all hierarchies for this characteristic. See Hierarchy Properties and Tab Page: Hierarchy.
Checking permitted node characteristics

When transferring hierarchies via the RFC, the system checks for which characteristics characteristic values with hierarchy nodes are allowed to be identified.
The permitted InfoObjects must be selected via External Characteristics in Hierarchies.
If no InfoObject is selected, only text nodes (for the artificial characteristic) are allowed as inner nodes.
All selected InfoObjects are included together with the characteristics compounded to them in the communication structure for hierarchy nodes.
Communication structure and transfer rules for hierarchies

If a hierarchy structure is loaded via the transfer method PSA, you can then define the transfer rules. The result is the same flexible transformation options as
is the case for transaction data, attributes and texts, excluding the fact that it is not possible to create a start routine.
In the InfoSource maintenance, there are the following views of the transfer rules:
View for the hierarchy header segment
View for the hierarchy node segment
For the hierarchy header, you can set the properties of the hierarchy header and the properties of the file structure via Hierarchy Structure.
In the following example, the field KOKRS is assigned to the field Controlling Area (0CO_AREA) and the field KOSTL is assigned to the field
Cost Center (0COSTCENTER) using the transfer rules. The alpha conversion routine is executed for KOKRS. The node has the hierarchy
property Reversing the Sign (0SIGNCH). This is also uploaded. As InfoObject 0COSTCENTER is compounded to InfoObject 0CO_AREA,
the characteristic values in NODENAME are saved added to one another.
See also:
Structure of a Flat Hierarchy File for Loading Using a PSA
1.3.1.2.3.3 Loading Data as Subtrees
Use

After loading a hierarchy, you can store it as a subtree, provided that a hierarchy already exists under the specified technical name in the BI system and this
target hierarchy contains the root nodes of the subtree hierarchy that you want to load.
You use subtree hierarchies, for example, to combine hierarchies from various source systems in a single BI system.
Prerequisites
1. Every subtree hierarchy must have the same technical name as the target hierarchy. Where necessary, you have renamed the subtree hierarchy in
accordance with the load process (see Tab Page Select Hierarchy).
The loaded hierarchy is only saved as a subtree if a hierarchy for the hierarchy basic characteristic already exists in BI under the specified key (the key
consists of the technical name of the hierarchy, a to-date, and a hierarchy version). By selecting the Subtree Insert or the Subtree Update option, you
tell the BI system to include the loaded hierarchy in a target hierarchy with the same technical name.
2. If you want to include a hierarchy as a subtree in a target hierarchy, the root node of the subtree hierarchy must be included as a node in the target
hierarchy. It must also have the same technical properties as this target hierarchy node. In both the target hierarchy and subtree hierarchy this interface
node relates to the same InfoObject. It has the same technical name in the target hierarchy as it has in the subtree hierarchy and has the same to-date
when the variables are time dependent.
3. The target hierarchy must not contain any additional subtree hierarchy nodes, unless it satisfies the prerequisites of a valid double-node in the new
complete hierarchy.
Features
When you load a hierarchy and execute a subtree insert, the hierarchy is included as a subtree in an existing hierarchy, without the system deleting any
nodes from the target hierarchy.
If a subtree is inserted a second time, each subtree hierarchy node under the interface node of the target hierarchy is duplicated, causing the
loading process to terminate.
When you load a hierarchy and execute a subtree update, the hierarchy is included as a subtree in an existing hierarchy. The system replaces the old subtree
with the new one.
If a subtree update is executed again, all the nodes under the interface node in the target hierarchy are deleted before the new subtree is
inserted.
Activities
In the scheduler, on the Select Hierarchy tab page, carry out the following steps to store a hierarchy as a subtree in BI.
1. After loading, change the technical name of the subtree hierarchy into the technical name of the target hierarchy. Choose Rename Hierarchy After
Loading and enter the technical name.
2. Choose the Subtree Insert update method if you want to include the hierarchy as a subtree in an existing hierarchy, without the system deleting any
nodes from the target hierarchy.
or
Choose the Subtree Update update method, if you want to include the hierarchy as a subtree in an existing hierarchy and you want the system to delete
the old subtree and replace it with the new one.
Example
Example 1
The scenario, on which this example is based, is that the hierarchies for InfoObject 0CUST_SALES have text nodes as root nodes and these are represented
by the InfoObject 0HIER_NODE with the characteristic value ~ROOT. Otherwise, the hierarchies would consist only of nodes that can be posted to from the
InfoObject 0CUST_SALES
If the InfoObject 0SOURCESYSTEM is compounded with 0CUST_SALES, you can combine hierarchies from heterogeneous SAP systems into a single
hierarchy in BI. If a hierarchy is uploaded, the InfoObject 0SOURCESYSTEM is filled automatically with the corresponding source system ID. If identical
nodes arrive from different source systems, the compounding with the 0SOURCESYSTEM prevents the nodes being duplicated in the target hierarchy. In this
example, the interface node is the root node of the 0CUST_SALES hierarchy.
In the InfoPackage for the corresponding source system, you select the name of the hierarchy that you want to load. In this example, the same technical
name is always used in the various source systems and suggested by the system as the default technical name. On the Select Hierarchy tab page in the
scheduler, specify that you want the uploaded hierarchies to always be given the same technical name in BI, if this is not already the case. You can also set
the update method here.
If, after a full update, the subtree insert option is used to store all additional hierarchies as subtrees of one of these hierarchies, you end up with a hierarchy
with a root node, under which hang all the nodes that used to hang under the root nodes of the hierarchies specific to the source system.
If you use the subtree update option, you get a target hierarchy containing only the most recently loaded subtree. This is because all the nodes under the
interface node are deleted before the new subtree is added.
Example 2
This example assumes that there are different SET hierarchies for the InfoObject 0COSTCENTER, such as for Europe, Mexico, and USA. It is also assumed
that the nodes of one hierarchy do not appear in any other hierarchy.
In BI, in the hierarchy maintenance screen, you create a WORLD hierarchy with three interface nodes belonging to the SET hierarchies mentioned above.On
the Select Hierarchy tab strip in the scheduler, you specify that, after loading, you want the three SET hierarchies to be stored as a subtree under the same
technical name as the WORLD hierarchy.
When the SET hierarchies are loaded, you get a hierarchy, under whose root nodes the three hierarchies Europe, Mexico and USA hang.

When the SET hierarchies are loaded, you get a hierarchy, under whose root nodes the three hierarchies Europe, Mexico and USA hang.
If you use the subtree insert option in this example, the scenario must be recreated the next time you upload, otherwise, the hierarchies will be duplicated.
You recreate the scenario by deleting the nodes and subtrees that hang under the interface nodes, before you reload the data.
If you use the subtree update option, you are able to reload the individual hierarchies as many times as you like, because the old subtree is deleted each
time.
1.3.1.2.4 Creating Hierarchies
Prerequisites
In InfoObject maintenance, the hierarchy basic characteristic is set as a characteristic with Hierarchies (see Tab Page: Hierarchy).
Procedure
You can create hierarchies in two ways; either from the SAP Easy Access Menu or hierarchy maintenance in the Data Warehousing Workbench.
On the SAP Easy Access screen, choose Modeling Master Data Maintenance Hierarchies . The Initial Screen Hierarchy Editing dialog box
appears.
You are in the Data Warehousing Workbench in the Modeling functional area. You can access hierarchy editing in the following ways:
In the InfoObject tree, you can choose Create Hierarchy from the context menu of the required InfoObject.
I n the Data Warehousing Workbench , you can call hierarchy maintenance in the symbol bar by choosing Edit Hierarchies . The Initial Screen
Hierarchy Editing dialog box appears.
Access from InfoObject Tree

1. In the Data Warehousing Workbench under Modeling, choose the InfoObject tree .
2. If you have assigned the hierarchy basic characteristic to an InfoObject catalog, select the corresponding InfoObject catalog for an InfoArea.
If the hierarchy basic characteristic does not belong to an InfoObject catalog, choose the InfoArea Non-Assigned Nodes and the InfoObject Catalog
Non-Assigned Characteristics.
3. Select the characteristic for which you want to create a hierarchy and choose Create Hierarchy from the context menu. The Create Hierarchy dialog box
appears. The InfoObject name appears by default.
4. Enter a hierarchy name and description (short, medium, long). Other fields may be displayed, depending on which hierarchy properties were selected for
the hierarchy basic characteristic.
Fields used to enter the Validity (valid to, valid from) for the hierarchy property Total Hierarchy Time-Dependent
Fields used to specify the Hierarchy Version for the hierarchy property Hierarchies Version-Dependent.
5. Confirm your entries. The Maintain Hierarchy screen appears. You can define the structure of a hierarchy here.
6. To create a hierarchy node, you first need to choose an insertion mode: Insert as First Child or Insert As Next Neighbor (see Hierarchy
Editing Functions).
7. Choose the type of node you want to create: Text Node, Characteristic Node, <Hierarchy Basic Characteristic Node> or Interval (see Hierarchy
Nodes)
The system inserts the required node. The following symbols are used:
Nodes that cannot be posted
Text Nodes
Foreign Characteristic Nodes
Nodes that can be posted
< Hierarchy Basic Characteristic Node >
Intervals
You can insert additional nodes in the context menu for a node. You can also call editing functions for the selected node.
8. Repeat this procedure until the hierarchy structure has been set. For more information, see Modeling Nodes and Leaves.
A hierarchy can contain 50,000-100,000 leaves at most. If your hierarchy is larger, you should insert a level that is used as a navigation
attribute or preferably as a separate characteristic in the dimension table.
9. You can use Level Maintenance and Hierarchy Attributes to set how the hierarchy is to be displayed and processed in reporting (see Level
Maintenance and Hierarchy Attributes).
10. Save the hierarchy.
11. Activate the hierarchy. See Editing Hierarchies.
Access Using Edit Hierarchies

1. In the Data Warehousing Workbench symbol bar, choose Edit Hierarchies . The Initial Screen: Hierarchy Editing dialog box appears with a list of all
the hierarchies in your BI system.
2. Restrict this list to the required hierarchy basic characteristic or select an existent hierarchy for it. (For more information about this dialog box, see Editing
Hierarchies.)
3. Choose Create Hierarchies . The Create Hierarchy dialog box appears. The InfoObject name appears by default. The subsequent steps are the same
as those described above (4.-11.).
Result
The hierarchy is activated ( ) and can be used in aggregates and in reporting.

See also:

Editing Hierarchies
Hierarchy Editing Functions
1.3.1.2.4.1 Modeling Nodes and Leaves

The following section looks at how hierarchy nodes can appear in duplicate in a hierarchy, both for real and only in a BEx query display:Link Nodes
A node and the complete sub-tree under this node can be inserted several times into a hierarchy as a link node (see Link Nodes). All leaves of this node
appear more than once in the overall hierarchy.
Duplicate Leaf
In hierarchy maintenance, it is possible to hang a leaf (characteristic value) under as many different nodes as you require. A leaf can, however, only be
positioned once directly under the same node.
For both duplicate leaves and leaves in subtrees under link nodes, the values of the duplicate leaves are only considered once by the system
internally. When aggregating, the system automatically calculates what are called correction leaves for the superordinate node.
If a leaf Lo lies three times amongst the descendants of a node No , the value is added three times internally and then subtracted twice by the
correction node.
Postable Nodes
Starting point:
Change:
If an additional leaf L1 and/or a node L1 is added to the hierarchy node B , node N becomes a postable node N'. Leaf L lies under node N' , followed by L1 and
node N1 . Leaf L is not displayed in hierarchy maintenance, but is displayed in the query. Node N1 does not have a value: It is displayed in hierarchy
maintenance but not in the query.
A cost center hierarchy is a typical case that shows how useful this display behavior can be: If L is the cost center in question, the superior of B 1 und K 1 , it is
important to be aware of the costs that are directly posted to the cost center B and not to one of the subordinate cost centers.
Via Hierarchy Attributes you can set up that leaves such as Leaf L in our example- are not displayed in the BEx Query (see Hierarchy Attributes).

1.3.1.2.5 Editing Hierarchies
Prerequisites
You have created a hierarchy for the required hierarchy basic characteristic (see Creating Hierarchies).
Procedure
You can create hierarchies in two ways: Either from the SAP Easy Access Menu or in the Data Warehousing Workbench from hierarchy maintenance.
On the SAP Easy Access screen, choose Modeling Master Data Maintenance Hierarchies . The Initial Screen Hierarchy Editing dialog box
appears. For more information, see section Accessing from Editing Hierarchies .
You are in the Data Warehousing Workbench in the Modeling functional area. You can access hierarchy editing in the following ways:
You can select an editing function in the context menu of a hierarchy in the InfoObject tree.
I n the Data Warehousing Workbench , you can call hierarchy maintenance in the tool bar by choosing Edit Hierarchies .
Access from InfoObject tree

1. In the Data Warehousing Workbench under Modeling, choose the InfoObject tree .
2. If you have assigned the hierarchy basic characteristic to an InfoObject catalog, select the corresponding InfoObject catalog for an InfoArea.
If the hierarchy basic characteristic does not belong to an InfoObject catalog, choose the InfoArea Unassigned Nodes and the InfoObject Catalog
Unassigned Characteristics.
3. Select the characteristic hierarchy you want to edit and choose an editing function in the context menu. The following table gives you an overview of the
available functions:
Editing functions
Function Information
Display The Display Hierarchy screen appears.
Change The Change Hierarchy screen appears.
Copy If several versions of the hierarchy are available, the Selection of Hierarchy Object
Version dialog box appears. Choose the variant you want to use.
The Save Hierarchy As dialog box appears. Enter a hierarchy name.
If the hierarchy is version or time dependent, enter the hierarchy version and the
validity date (see Hierarchy Properties).
You can enter descriptions (short, medium and long) for the hierarchy that you want
to copy.
Delete Confirm the prompt if you do actually want to delete the hierarchy.
Activate The system notifies you of whether activation was successful.

In cases where it is not possible to activate the hierarchy, a dialog appears with the
error log.
If the hierarchy is already used in an aggregate, you can choose
whether you want to activate the hierarchy directly and thereby delete the
aggregate
whether you want preselect the hierarchy for activation.
In the latter case, you need to run the change run for this hierarchy. This updates all
the aggregates contained in the hierarchy and activates the hierarchy. (See System
Response Upon Changes to Master Data and Hierarchies)
Access from Edit Hierarchies

1. In the Data Warehousing Workbench tool bar, choose Edit Hierarchies . The Initial Screen: Hierarchy Editing dialog box appears, with a list of all
the hierarchies in your BI system.
2. You can restrict the list to hierarchies for a particular characteristic. Input help is available for the Restriction to Hierarchy Basic Characteristic field.
After selecting the required hierarchy basic characteristic, choose Filter.
3. If you want to see details about a hierarchy, choose Details . A dialog box appears which contains the following entries:
Internal hierarchy ID
Short description
Hierarchy name
Hierarchy type
InfoObject
Version
Valid to
Valid from
Source system
Request no.
Person responsible
Number of levels in hierarchy
Largest node ID of hierarchy
Hierarchy is consistent
Root node ID
Language key
Medium description

Long description
4. Select the hierarchy you want to edit and then choose an editing function from the table above: Change Hierarchy , Display Hierarchy , Delete
Hierarchy , Copy Hierarchy , Activate Hierarchy .
The function Create Hierarchy is also available (see Creating Hierarchies).
See also:
Hierarchy Maintenance Functions

1.3.1.2.5.1 Functions of Hierarchy Processing
Use
In the hierarchy processing, a range of functions for displaying and processing hierarchies and their attributes is available.
Hierarchy properties, which are valid for all hierarchies for a hierarchy basic characteristic, cannot be changed here (see Hierarchy Properties).
Features
You can select the following functions from two toolbars in the hierarchy maintenance. The upper application toolbar has available functions that concern the
entire hierarchy. The lower application toolbar mainly offers functions for node maintenance:
Functions for the entire hierarchy
Function What You Need to Know
Header Data The dialog box Display Hierarchy Header or Change Hierarchy Header appears.
They contain additional information about technical properties for your hierarchy:
Hierarchy name
Description (short, medium, long)
Object version
Person responsible
Last changed by, change date, change time
Source system
Request no.
Hierarchy ID
Display <-> Change You can switch between the display and change mode. This affects other functions.
Hierarchy Consistency Check The system checks the technical correctness of the hierarchy structure:
Technical correctness of individual nodes, for example:
Time dependency (see Hierarchy Properties)
Duplicate nodes (see Modeling of Nodes and Leaves)
Valid characteristic values
Technical correctness of the structure, for example:
Nodes that are not included in the hierarchy
Nodes can only have one superior node
Activating Hierarchies See Editing Hierarchies (Processing Functions table).
Functions for displaying and processing the hierarchy in a BEx query
Function What you need to know
Level Maintenance You can specify free texts for hierarchy levels that are displayed in the BEx query
context menu (see Level Maintenance).
Hierarchy Attributes You can make specifications for the display and processing of hierarchies in
reporting (see Hierarchy Attributes).
Modes for adding hierarchy nodes
Add as First Child The source node is added directly under the target node as the first child.
Add as First Neighbor The source node is added next to the target node on the same level.
The Drag&Drop relationship is also controlled with these insertion modes. If you want to hang several nodes at the same time with Drag&Drop,
choose the insertion mode you want, highlight the hierarchy nodes (if necessary, by pressing the Ctrl button), and drag the selected hierarchy
nodes with Drag&Drop to the place you want.
Displaying inactive/active versions

Display Inactive Version
Display Active Version
In Display Mode, you can switch between the active and modified version of a hierarchy. If there is only one version, or if you are in the
Change Mode , this function is inactive.
Jumping to other maintenance transactions
Edit Master Data You arrive at the master data maintenance for the hierarchy basic characteristic.
There you can create new data, for example, that you can subsequently add to the
hierarchy.
Edit InfoObjects InfoObject maintenance for the hierarchy basic characteristic appears, directly on
the Hierarchy tab page.
Monitor The monitor for the Data Warehousing Workbench appears, directly at the last
request loaded.
Functions for editing hierarchy nodes
Detail The dialog box Display Node or Change Node appears. This provides detailed
information about a node.
Create and Delete Node These functions are only available in Change Mode .
Text Nodes See Text Nodes in the Postability of Nodes table under Hierarchy Nodes.
Characteristic Nodes See External Characteristic Nodes in the Postability of Nodes table under
Hierarchy Nodes.
<Hierarchy basic characteristic node> See Postable Nodes in the Postability of Nodes table under Hierarchy Nodes.
Intervals See Interval in the Special Hierarchy Nodes table under Hierarchy Nodes. For
more information, see Intervals
Delete Nodes You can delete both individual as well as several nodes. To delete several nodes at
the same time, select these (if necessary, by pressing the Ctrl button). The system
deletes those nodes and that part of the subtree.
Special features of root nodes:

You can create additional root nodes. You use a new node to Insert as Next Neighbor . In this way, you can allow several subtrees to be
displayed in the query without having them be subordinate to a root node.
You can insert an already existing node as the root node by dropping it into the background.
Functions for displaying subtrees
Drill Down Subtree The subtree under the selected node is expanded.
Collapse Subtree The subtree under the selected node is compressed.
Functions for displaying technical information
Display Technical IDs The following columns are displayed as standard:

< Hierarchy name >
InfoObject
Node name
Link indicator
In addition, the following columns are displayed:
ID (internal ID number for the hierarchy node itself)
Parent ID (ID for parent node)
Child ID (ID for first child node)
Next ID (ID for next neighboring node)
Goto Node ID The dialog box Selection of Node with Node ID appears. Specify the node ID for
the node to which you want to go. The corresponding node is selected in the tree.
See also:
Creating Hierarchies

Editing Hierarchies
1.3.1.2.5.2 Level Maintenance
Use
In hierarchy maintenance, you can fix the structure of the hierarchy, by assigning the hierarchy nodes to particular levels. In the level maintenance, you can
also enter free texts for these hierarchy levels. These texts are shown in the context menu when navigating in the query.
Prerequisites
You are in the change mode for the hierarchy (see Edit Hierarchy).
Functions
In the hierarchy maintenance, via the button Level Maintenance, you can access the screen for maintaining hierarchy levels.
In the left-hand screen area Maintain Level Descriptions for Display in the Query, you can see a list of all hierarchy levels and associated descriptions. By
double clicking on the level or by clicking on a description, you can access a dialog box in which you can enter new descriptions for a node level. Enter as
expressive descriptions as you can for the different hierarchy levels.
If you choose not to enter texts for the hierarchy levels, BEx uses the generic names Level 01, level 02, level n .
Example
For a geographical hierarchy with three levels, change the short description of the individual levels as follows:
Level 1: In place of Level 01, enter Continent .
Level 2: In place of Level 02, enter Country.
Level 3: In place of Level 03, enter Region .
When navigating in the query, after choosing Expand Hierarchy from the BEx context menu or from the enhanced context menu in the Web, you have access
to the following options:
Expand Hierarchy
Continent
Country
Region
1.3.1.2.5.3 Hierarchy Attributes
Use
In hierarchy maintenance, you can set hierarchy attributes and, as a result, influence the display and processing of hierarchies in reporting.
When loading hierarchies, the hierarchy attributes are transferred from the old active version of the hierarchy. When loading via the PSA, they
can be overridden by transfer rules.
Prerequisites
You are in the change mode for the hierarchy (see Edit Hierarchy).
Functions
You can use the pushbutton Hierarchy Attributes in hierarchy maintenance to set the following Display Parameters for the Hierarchy Display in the Query.
Do Not Display Leaves for Inner Nodes in the Query

A postable node with lower-level nodes is displayed in the query by default with a leaf with the same text inserted under it (see Modeling Nodes and Leaves).
If you set this indicator, these (additional) leaves are suppressed.

If the aggregation of values of the lower-level nodes does not return a sensible value for the postable node, you can use this option for a
technical correction. The correction value which you post to the postable node in this case is hidden.
Display Behavior for Leaves of Inner Nodes Can Be Changed

You can set whether it is to be possible to change the above display behavior at query runtime. The changeability of the display behavior has the following
possible values:
' ' : The display behavior cannot be changed in the query.
'X': The display behavior can be changed in the query.
Suppressing the Not Assigned Node

If there are characteristic values that do not appear in the hierarchy, a Not Assigned node is added to the hierarchy by default. If you set this indicator, no
Not Assigned node is created for the hierarchy (REST_H, see Hierarchy Nodes).
If the hierarchy is selected as a presentation hierarchy, only those characteristic values are filtered that do not appear as leaves or postable
nodes in the hierarchy. This is the case even if they are posted to data.
There are 1000 characteristic values for the characteristic material. A hierarchy with material groups from a total of 100 materials is defined
for it. The remaining (1000-100), that is 900 characteristic values, are positioned under node Not Assigned. If you set the indicator for
Suppressing Not Assigned Nodes, these 900 characteristic values are filtered out.
Another typical example of where this is used is with a hierarchy that only contains the cost centers of one of many controlling areas.
Set this indicator when the hierarchy only contains one (relatively small) proportion of the characteristic values. This may well improve performance.
If a characteristic has a large number of values but only a fraction of them appear in the hierarchy, the Not Assigned node has a lot of nodes and the internal
hierarchy presentation is very large. This can lead to longer runtimes and problems when saving.
Root / Sum Position

Here you can determine,
whether the root and therefore the sum item of the hierarchy is displayed bottom right in the query, with the leaves at the top
whether the root and therefore the sum item of the hierarchy is displayed top right in the query, with the leaves at the bottom
This setting can be overridden in the Query Designer (see Characteristic Properties): Select the option Position of Lower-Level Nodes in the
User Setting column i n the dialog box Characteristic Properties, under the group header Hierarchy Properties , and choose up or down
as the value.
You can also override this setting in the BEx Analyzer as well as in the Web using the appropriate entry in the context menu.
Start Drilldown Level

Here you can determine how many hierarchy levels in the query are included in drilldown when it is first performed. If no number is entered, then three levels
are displayed.
This setting can be overriden in the Query Designer (see Characteristic Properties): In the dialog box Characteristic Properties, under the
group header Hierarchy Properties, select the option Expand to Level in the column User Setting , and enter the value >0.
You can also override this setting in the BEx Analyzer as well as in the Web using the appropriate entry in the context menu.
Activating Virtual Time Hierarchies
Use
You can use this function to release hierarchies for time characteristics with which you want to work in reporting. You can choose the hierarchies you want to
use from a list of suitable hierarchies for a time characteristic. The selected hierarchies are then made available for you in reporting.
The hierarchies for time characteristics are not saved in the database tables, but generated virtually in the main memory. Hence, the reason
they are called Virtual Time Hierarchies.
Procedure
1. In the SAP Reference IMG, choose BI Customizing Implementation Guide Business Intelligence Reporting-Relevant Settings
General Reporting-Settings Set F4 Help and Hierarchies for Time Characteristics / OLAP Settings .
2. Choose the Virtual Time Hierarchies tab page .
In the left-hand area, you can see the active time characteristics in the system (such as date, month, calendar month, and fiscal year/period), for which
hierarchies have been made available in characteristic maintenance.
3. Choose the required time characteristic using the button (for example, date).
In the upper screen area, you can see the hierarchies suitable for the time characteristic.
4. Select the required hierarchies by double-clicking on them or using Drag&Drop to move them into the lower-right screen area.
The hierarchy tree symbol shows that the selected hierarchies are active and listed in the lower area.
5. You can now select the start level for the activated hierarchies in the lower screen area, and enter short, medium, and long descriptions.
With the start level, you determine the level to which the hierarchy is expanded in the opening drilldown.

If you do not enter a description, the system creates one automatically.
6. Choose Save .
Result
You have activated virtual time hierarchies and can now use them in the Query Designer for reporting.
1.3.1.2.7 Hierarchy Properties
Definition
Hierarchy properties are properties of all hierarchies for a hierarchy basic characteristic, delivered by SAP and freely-definable according to the needs of the
customer.
Use
Hierarchy properties are fixed in InfoObject maintenance for a characteristic and are valid for all hierarchies that have been created for this characteristic.
Note that hierarchy attributes are fixed in hierarchy maintenance and only apply to the hierarchy that is currently opened. You can find more
information under Hierarchy Attributes.
Structure
The following hierarchy properties are available:
Version dependency
Time dependency
Intervals
Reversing the sign
1.3.1.2.7.1 Hierarchy Version
Use
Characteristic hierarchies can be used in different versions. This option should be selected when hierarchy versions are to be addressed in reporting.
Integration
If there are different hierarchy versions in the source system, you can map these into BI. You can also generate different versions for one and the same
hierarchy from the source system.
Features
In InfoObject maintenance, you specify whether the hierarchy basic characteristic has the property Version-Dependent Hierarchies (see Tab Page:
Hierarchy).
In the master data maintenance for characteristic 0HIER_VERS, you can create and change hierarchy versions (see Maintain Hierarchy Versions).
In the hierarchy maintenance you edit the hierarchy versions (see Editing Hierarchies).
In reporting you can use the different hierarchy versions, for example, for comparisons. You can display the hierarchy version data sequentially or
simultaneously in different columns. Variables can be used to set parameters for the different versions.
Example
For example, you can create a company structure by area for different hierarchy versions for the InfoObject Main Area in order to execute a plan-actual
comparison in a query.
Plan-actual comparison with hierarchy versions
Hierarchy version PLAN Hierarchy version ACTUAL

Main Area NORTH Main Area NORTH
Area 1
Area 2 Area 2
Main Area SOUTH Main Area SOUTH
Area 1
Area 3 Area 3
Area 4 Area 4
See also:
1.3.1.2.7.1.1 Maintaining Hierarchy Versions
Procedure
1. From the main menu in the Data Warehousing Workbench, select Tools Maintain Hierarchy Versions . The Characteristic 0HIER_VERS
Maintain Master Data: Selection screen appears.
2. Select a hierarchy version that is already available in the system. Input help is available.
If you want to create or modify versions in a particular language, select the corresponding language key.
3. Choose Execute . The Characteristic 0HIER_VERS Maintain Master Data: List screen appears.
4. You use the Change function to modify existing versions and the Create function to create new hierarchy versions. A dialog box appears, in
which you specify the hierarchy version and enter a long description for it. (The language is set to correspond to the language key that you specified on
the selection screen.)
5. Enter the appropriate texts.
6. Choose Continue .
In the hierarchy maintenance screen, you can create various hierarchy versions under the same technical name by copying a hierarchy and
saving the copy as a different hierarchy version. However, you can only specify the description of the hierarchy version in the master data
maintenance screens of the 0HIER_VERS characteristic .
Result
You have modified an existing version of a hierarchy or created a new hierarchy version including a descriptive text. You can use this version when you create
a hierarchy with versions.
The texts for the hierarchy version and the description are independent of the hierarchy basic characteristic.
If, for example, the version 001 has the text Plan, each hierarchy version 001 has the text Plan, regardless of which hierarchy basic
characteristic was used to define the hierarchy.
See also:
Hierarchy Versions
1.3.1.2.7.2 Time-Dependent Hierarchies
Use
In a hierarchy that is not time dependent, the characteristic values are always the same.
If you want to create views of a hierarchy that are valid for a specific time period, you need to create the entire hierarchy as time dependent.
If you want to model relationships that change time-dependently, you need to create the hierarchy structure time-dependently.
Functions
In InfoObject maintenance, you can set whether and in which ways a hierarchy is time dependent. You can choose from the following:
whether the hierarchy is not time dependent ( Hierarchy Not Time-Dependent). This is set by default.

whether the entire hierarchy is time dependent ( Entire Hierarchy Time-Dependent).
whether individual node relationships are time dependent ( Hierarchy Structure Time-Dependent)
whether a temporal hierarchy join is used with time-dependent hierarchy structures ( Use Temporal Hierarchy Join )
Entire Hierarchy is Time-Dependent

You can either load time-dependent hierarchies (see Loading Time-Dependent Hierarchies) or create them in the BI system (see Creating a Hierarchy). When
you create a time-dependent hierarchy, you have to enter a validity interval ( valid to and valid from fields).
If an entire hierarchy is time dependent, the system creates hierarchy versions that are valid for separate intervals. The system automatically uses the
current valid version in this case. The hierarchy valid in each case can be uniquely identified by its technical name and the From-To Date.
In the InfoObject tree of the Data Warehousing Workbench, all time-dependent hierarchies under the associated InfoObject are displayed with the
corresponding To Date , for example Time-Dependent Hierarchy 05/31/2000 .
In reporting, the system returns the valid hierarchy when a query is executed using the query key date.
Within a restructuring company areas, you can create time-dependent versions of a hierarchy for the Main Area InfoObject. This enables you
to compare the restructuring over different time periods in a query.
Time-dependent hierarchy 01/01/1999 - 05/31/1999 Time-Dependent Hierarchy 06/01/1999 - 12/31/1999
Main Area NORTH Main Area NORTH
Area 1
Area 2 Area 2
Main Area SOUTH Main Area SOUTH
Area 1
Area 3 Area 3
Area 4 Area 4
In reporting, you can work in the individual columns of the report structure with fixed date values. You may want to do this to compare Main
Area North in the Time-Dependent Hierarchy 05/31/2000 with Main Area North in the Time-Dependent Hierarchy 06/01/2000 ( simulation).
Time-Dependent Hierarchy Structures

You can either load time-dependent hierarchies (see Loading Time-Dependent Hierarchies) or create them in the BI system (see Creating a Hierarchy).
In hierarchy maintenance, you can determine a valid time interval for each hierarchy node ( Valid to and Valid from fields).
In reporting, a hierarchy with time-dependent hierarchy structures is created either for the current key date or for the key date defined for the query. In
addition, you can evaluate a hierarchy historically using the temporal hierarchy join.
You can assign an employee to different cost centers at different times within the context of a restructuring.
In the context menu of a hierarchy, choose Display Hierarchy to access the hierarchy display: Each node and leaf has been given a date symbol. Hierarchy
nodes that are assigned to different places in the hierarchy structure, depending on the time, are displayed more than once. By double clicking on a hierarchy
node, you can display the associated validity period for the node relation.
In the following example, you can double click on the Jones leaf to see that the worker Jones was assigned to region USA between
01/01/1999 and 05/31/1999 and Puerto Rico from 06/01/1999 to 12/31/1999.
In order to use a hierarchy with a time-dependent hierarchy structure in reporting, you require the following settings in the BEx Query Designer:
a. If you want to evaluate a hierarchy with a time-dependent hierarchy structure for a fixed key date, enter the key date in query definition.
b. If you want to evaluate a hierarchy with a time-dependent hierarchy structure historically, for a key date that is to be derived from the data, choose
the temporal hierarchy join option and specify the derivation type for the key date.
For a more detailed description of the functions and differences between the two evaluation views, see Time-Dependent Hierarchy Structures in the Query.
In maintenance of the key date derivation type (RSTHJTMAINT) determine the rule you want to use to determine the key date from the data. In this way you
determine the time characteristic and way in which the key date is to be derived.
1. First determine the time characteristic.
If you choose a Basic Time Characteristic as a time characteristic (for example, 0CALDAY, 0CALMONTH, 0FISCPER), you can use a key date

derivation type of this kind for all InfoProviders that contain exactly one time characteristic that references the selected basic time characteristic. If there
are several time characteristics in an InfoProvider that reference the basic time characteristic, you have to either determine the time characteristic more
specifically or select a particular time characteristic from a particular InfoSet ( Time Characteristic from InfoSet ).
2. Determine how you want the key date to be derived from the time characteristic.
The following derivation types are available:
First day of the period
Last day of the period
Delay by number of days (you specify this in the Delay by Days field). In this case, the key date is calculated from the first day in the period plus the
number of days specified minus 1. If the key date does not fall within the period, the last day of the period is used.
Key date derivation type with (basic characteristic = 0CALMONTH, derivation type = first day of period):
For January 2005 the key date is calculated as 1/1/2005.
For February 2005 the key date is calculated as 2/1/2005.
Key date derivation with (basic characteristic = 0FISCPER, derivation type = delay by number of days and delay = 29):
For K4/01.2005 the key date is calculated as 1/29/2005.
Note that the way in which you determine the key date derivation type affects performance. The number of data records that the OLAP
processor reads corresponds to the level of detail on which the time characteristic and the leaf level lie. For this reason, choose the time
characteristic as approximately as possible in order to keep the hierarchy small.
A small hierarchy has 100 leaves. For a period of 12 months, the OLAP Processor reads 1200 data records at month level. At day level, it
reads 36500 data records.
See also:
Maintaining Hierarchy Versions

Time-Dependent Hierarchy Structures in the Query

The following example explains the features and different analysis options with time-dependent hierarchy structures.
Time-Dependent Hierarchies
The time-dependent hierarchy for characteristic M has the following structure:
Hierarchy for Characteristic M
Successor Node Predecessor Node Valid From Valid Until
Root node 1.1. 31.12.
Node1 Root node 1.1. 31.12.
Node2 Node1 1.1. 16.2.
Leaf1 Node2 1.1. 16.2.
Leaf2 Node2 1.1. 31.1.
Node4 Node1 1.1. 31.12.
Leaf2 Node4 1.2. 31.12.
Leaf3 Node4 1.1. 31.12.
Node2 Node3 17.2. 31.12.
Leaf1 Node2 17.2. 31.12.
Leaf4 Node2 17.2. 31.12.
Node5 Node3 1.1. 31.1.
Leaf5 Node5 1.1. 31.1.
Leaf5 Node6 1.2. 31.12.
The following figure outlines the hierarchy from a modeling perspective:

InfoProviders
An InfoProvider with the characteristics Characteristic M , Day , Month and the key figure Key Figure contains the following data:
InfoProvider Data
Characteristic M Day Month Key Figure
Leaf1 15.1. Jan 10
Leaf2 15.1. Jan 20
Leaf3 15.1. Jan 30
Leaf4 15.1. Jan 40
Leaf5 15.1. Jan 50
Leaf1 15.2. Feb 25
Leaf1 28.2. Feb 5
Leaf2 15.2. Feb 15
Leaf3 28.2. Feb 5
Leaf4 28.2. Feb 35
Leaf5 28.2. Feb 25
Fixed Key Date

A query based on this InfoProvider contains three structural elements; key figure restricted to January Key Figure(Jan) , key figure restricted to February Key
Figure(Feb) , key figure restricted to the whole year key figure and the characteristic CharacteristicM in the columns.
The hierarchy has a fixed key date (15.2.) and is being used as a presentation hierarchy.
The InfoProvider data specified above produces the following result in the query:
Query Result
Key Figure (Jan) Key Figure (Feb) Key Figure
Overall Result 150 110 260
* Root 110 75 185
** Node1 60 50 110
*** Node2 10 30 40
**** Leaf1 10 30 40
*** Node4 50 20 70
**** Leaf2 20 15 35
**** Leaf3 30 5 35
** Node6 50 25 75
*** Leaf5 50 25 75
* Non-assigned 40 35 75
** Leaf 4 40 35 75
The following graphic illustrates the query results:

Temporal Hierarchy Join
Query1: Presentation hierarchy
The hierarchy has a temporal hierarchy join and is being used as a presentation hierarchy. The key date is derived from the posted data.
The InfoProvider data specified above produces the following result in the query:
Query1 Result
* Root node 110 110 220
** Node1 60 45 105
*** Node2 30 25 55
**** Leaf1 10 25 35
**** Leaf2 20 20
*** Node4 30 20 50
**** Leaf2 15 15
**** Leaf3 30 5 35
** Node3 50 40 90
*** Node2 40 40
**** Leaf1 5 5
**** Leaf4 35 35
*** Node5 50 50
*** Leaf5 50 50
** Node6 25 25
*** Leaf5 25 25
* Non-assigned 40 40
** Leaf4 40 40
The following graphic illustrates the query results:

The value of leaf1 on 15.2. is assigned to node2 which has node1 as its predecessor because leaf1 belongs to this hierarchy path on the posting
day.
The value of leaf1 on 28.2. is assigned to node2 which has node3 as its predecessor because leaf1 belongs to this hierarchy path on the posting
day.
The value of leaf4 on 15.1. is assigned to the non-assigned node because leaf4 did not belong to this hierarchy on the posting day.
Query2: Restriction for key figure
A query based on the data specified above, with one structural element key figure restricted to node2 key figure(node2) and month in the columns, produces
the following result:
Query2 Result
Key Figure(Node2)
Jan 30
Feb 65
Result 95
The value for January is the total of the values ( leaf1, 15.1. ) and ( leaf2, 15.1. ).
The value for February is the total of values ( leaf1, 15.2. ) ( leaf2, 28.2. ) and ( leaf4, 28.2. ).
Query3: Presentation hierarchy with filters on nodes
If, in addition, query1 is filtered using characteristicM = node2 , the following result is produced:
Query2 Result
* Node2 30 25 55
** Leaf1 10 25 35
** Leaf2 20 20
* Node2 40 40
** Leaf1 5 5
** Leaf4 35 35
1.3.1.2.7.2.2 Loading Time-Dependent Hierarchies
Entire Hierarchy is Time-Dependent

The procedure for loading time-dependent hierarchies is described under Loading Hierarchies. Also note the following special features when loading time-
dependent hierarchies.
If you load a time-dependent hierarchy into a BI system and a hierarchy with the same technical name exists in this system already, the new hierarchy
overrules the old one. If the time interval of the hierarchy that you want to load does not completely match the time interval of the existing hierarchy, the time
interval of the existing hierarchy is adjusted accordingly.
If the time interval of the new hierarchy overlaps the time interval of the existing hierarchy, the time interval of the existing hierarchy is reduced
so that the two time intervals run seamlessly into one another.
This does not apply if the time interval of the existing hierarchy contains the time interval of the new hierarchy, meaning that the from-date of
the new hierarchy is greater than the from-date of the existing hierarchy and the to-date of the new hierarchy is less than the to-date of the
existing hierarchy. In this case, the new hierarchy cannot be loaded. You have to change the time interval for either the new hierarchy or the
existing hierarchy, so that the time interval of the new hierarchy is not contained in the time interval of the existing hierarchy.
If there are existing hierarchies with time intervals that are included in the time interval of a new hierarchy, the existing hierarchies are deleted.
If you do not want to specify the validity of a hierarchy in advance, you specify the current date as the from-date and the latest date possible
as the to-date, for example, 12.31.9999. You do the same for any other hierarchies that are subsequently loaded. When you load each
hierarchy, the system automatically sets the to-date of the last hierarchy that was loaded as the day before the from-date of the new
hierarchy. This procedure applies only to hierarchies that support transfer rules, see Special Features when Loading Data using the PSA.
Hierarchy Structure is Time-Dependent

In the scheduler, you select the time intervals that you want to load. For more information, see Tab Strip: Update in the Time Selections for Time-Dependent
Data section.
Whether the hierarchy is extracted as time-dependent or not depends on the properties the hierarchy has in the SAP source system and in the DataSource.

There are two DataSources for the InfoObject 0CUST_SALES:
The first DataSource extracts the hierarchy that is valid for the current date. The extracted hierarchy is not time-dependent.
The second DataSource extracts the complete hierarchy as time-dependent.
You are able to load a time-independent DataSource for an InfoObject, whose hierarchies are set as time-dependent. The date fields are set to the lowest
(1.1.1000) and the highest (12.31.9999) dates possible. On the other hand, you are not able to load a time-dependent DataSource for an InfoObject, whose
hierarchies are not time-dependent, because the time-dependent hierarchy nodes will be duplicated at various points in the hierarchy.
See also:
Time-Dependent Hierarchy
1.3.1.2.7.3 Intervals
Use
Under both postable and not postable nodes you can hang an interval instead of a quantity of leaves. An interval includes a quantity of characteristic values
for the hierarchy basic characteristic and is defined by its lower limit (the From-<Characteristic Value> ) and its upper limit (the To-<Characteristic Value> ).
Since an interval corresponds to a quantity of leaves, you cannot hang additional objects under an interval. (For more information about the individual hierarchy
nodes, see Hierarchy Nodes.)
Features
In the InfoObject maintenance, you define whether intervals in hierarchies are permitted for the hierarchy basic characteristic (see Tab Page: Hierarchy).
In the hierarchy maintenance, you model the hierarchy with intervals, if necessary.
If you add an interval to a hierarchy in the hierarchy maintenance, the system creates a node for the 0HIER_NODE artificial characteristic. This node
represents the interval. The limits of the interval are entered in the /BI*/H<IOBJNM> hierarchy table, which is generated for each hierarchy basic
characteristic, into the LEAFFROM and LEAFTO fields. The description of the interval is comprised of the description for the characteristic values
selected for these fields.
You can also create intervals for such characteristic values for which no master data has yet been posted. If you post new data for the respective
characteristic values, the system automatically arranges it. In this way you can avoid having to enhance the hierarchy when accessing master data again.
In reporting, an interval is not displayed as a node, but rather as triggered: All leaves, which are in the interval and for which data is posted in the
InfoProvider, are displayed.
Example
Example 1 Cost Element Hierarchy
In a hierarchy for the Cost Element (0COSTELMNT) InfoObject, you want to add cost elements 100 to 1000 as an interval under the Material Costs node.
Until now, your BI system posted for the hierarchy basic characteristic only the characteristic values 100 to 500 in the InfoProvider.
1. Create the Material Costs text node.
2. You can create the interval directly under the Material Costs node. In this case, the leaves for the individual cost elements are likewise displayed
directly under the Material Costs node in the query.
However, if you also want to see a node in the query that summarizes the cost elements included in the interval, you can then create a Cost
Element 100 to 1000 text node under the node.
This way of modeling intermediate nodes is also suitable, for example, for a customer hierarchy in which you do not want see all customers at
the same time, but rather want to display groups, such as Customers A-C and Customers D-F .
3. Under the Material Costs (or Cost Element 100 to 1000 ) parent node, create an interval for Cost Element InfoObject.
4. Specify the interval limits in the Create Interval dialog box. Since the Controlling Area (0CO_AREA) InfoObject is compounded to the Cost Element
(0COSTELMNT) InfoObject, specifying the required controlling area you want is also necessary. Example:
From-ContArea 1000
From-CostElmnt 100
To-ContArea 1000
To-CostElmnt 1000
Long Description 10000000000100 10000000001000
The Node Level corresponds to the place where you add the interval.
If the interval nodes (or a part of the values) in the hierarchy already exists, you receive a Warning: Duplicate Nodes . Usually, the user does
not want values to occur multiple times in a hierarchy. However, you can decide whether the system is to transfer the duplicate nodes. (The
latter is the default setting.)
In the query, the leaves with values 100 to 500 are displayed in the cost element hierarchy under the node Material Costs (or Cost Element 100 to 1000 ).
If cost elements are added to the material costs, and you create the master data for the values from 501 , the new cost elements are automatically displayed
in the query as soon as the transaction data has been loaded.
The following graphic shows both types of modeling cost element hierarchies:

Example 2 Time Hierarchy
Another typical example for the use of intervals is the time hierarchy (see Hierarchy Nodes, Example 1).
See also:
1.3.1.2.7.4 Sign Reversal
Use
In some applications (for example, in finance applications), you may want to be able to select by node whether the sign for a key figures should be reversed.
To do this, you can load the attribute Sign Reversal onto the hierarchy or you can set it in hierarchy maintenance for each hierarchy node. In the query, you
can then reverse the sign in formulas by multiplication with a formula variable (replacement path from Sign Reversal hierarchy attribute).
Prerequisites
To be able to use this function, the hierarchy must have flexible hierarchy structures. This is the case when the hierarchy is loaded via the PSA and, as a
result, has transfer rules. Refer to Special Features when Loading using the PSA.
Functions
In InfoObject maintenance, define whether reverse sign function is possible for the hierarchy basic characteristic (see Tab Page: Hierarchy). If reversing the
sign is activated for hierarchies, the attribute 0SIGNCH is included in the communication structure for hierarchy nodes. You can find an example under Special
Features when Loading using the PSA.
In hierarchy maintenance, you can specify whether the sign for transaction data booked to this node is to be reversed for each hierarchy node.
In the query definition, create a formula variable for reversing the sign.
You can find additional information about this procedure under Using Sign Reversal.
Example
You have a hierarchy based on receipts and expenditure. According to accountancy logic, income is displayed with a negative sign and expenses are shown
with positive sign. Adding these values produces the profit.
Under certain circumstances, it may be advisable to circumvent accountancy logic and display the query income with a positive sign. This is where reversing
the sign comes in. In our example, one would only activate sign reversal for income.
The following graphic illustrates such a case: Reversing the sign is activated for the node REV ( Revenue) and its sub-nodes. In the third column, the
amounts appear without sign reversal, that is, with a negative sign. In the fourth column, the amounts are calculated using a formula variable with reversing the
sign and then displayed as a positive value.

See also:
1.3.1.2.7.4.1 Using Sign Reversal
Procedure
Setting sign reversal for a hierarchy basic characteristic
In InfoObject maintenance, you define whether or not sign reversal is possible for the InfoObject (see Tab Page: Hierarchy). The Sign Reversal for Nodes
setting determined here applies to all hierarchies that are based on this InfoObject. If sign reversal is allowed for hierarchies, the attribute 0SIGNCH is included
in the communication structure for the hierarchy nodes.
Sign reversal for hierarchy nodes
Determining sign reversal What You Need to Know
Set sign reversal per node in hierarchy maintenance Choose Change Node from the context menu of a hierarchy node to set sign
reversal for this node. Note: The sign reversal only applies to the node itself not to
its children or subnodes.
Load the sign reversal hierarchy attribute flexibly See Special Features when Loading Data via the PSA.
BEx Query Designer: Creating formula variables

You have loaded data into your InfoProvider. To be able to use sign reversal in reporting, you have to define a formula variable in the query definition:
1. You are in the Query Designer. Under Key Figures , use the context menu to choose New Formula. The Formula Builder opens.
2. Under Formula Variables, choose New Variable from the context menu. The variables wizard appears.
3. Enter a name and a short text for the variable. Choose Replacement Path as the processing type .
4. Choose your hierarchy basic characteristic.
5. Choose Hierarchy Attribute as the replacement. The attribute Sign Reversal is automatically displayed.
6. Save your formula variable. When defining the formula variable, you get the factor 1 or 1, with which you can multiply the required key figure.
For more information, see Defining Variables.
See also:
Sign Reversal
Elimination of Internal Business Volume
Use
You can use this function to eliminate the internal business volume when executing a BEx query. In other words, the effect of this function is that revenues
made between two cost centers in an organization are no longer displayed.
Prerequisites
You have an InfoProvider that includes two characteristics (sender and receiver) that contain the same reference (and, thus, contain the same master data)
and are on the same level within the hierarchy.

Note that you can only create aggregates for InfoCubes which contain both characteristics (sender and recipient).
Features
To eliminate internal business volume in an InfoProvider, you have to create a key figure with a reference. You then include these in the InfoProvider. The
value is kept here after the elimination during the query, but is not included in the fact table for the InfoCube (or in the DataStore object).
Creating the reference key figure

When creating a key figure, select Key Figure with Reference . In the InfoObject maintenance you have an additional tab page, Elimination . Enter one or
more characteristic pairs here regarding the key figure to be eliminated. In doing so, always choose a sending characteristic and a receiving characteristic.
A typical example for such a pair of characteristics is Sending Cost Center and Receiving Cost Center . The characteristics of such a pair must have the
same reference characteristic. You can also enter the names of the navigation attributes here.
You can display permitted characteristics for an elimination characteristic by using the input help.
If have specified several characteristic pairs, you still have to specify one of the following by using the selection buttons:
all characteristic pairs need to be eliminated - then the key figure value is only eliminated if the elimination condition is fulfilled for all characteristic pairs
(AND relationship)
each individual characteristic pair needs to be eliminated - then the key figure value is already eliminated as soon as the elimination condition for one of the
characteristic pairs is fulfilled (OR relationship)
Example
The profit center Production Accessories (UK) has $50.00 of internal revenue from profit center Internal Service (DE). This amount needs to be eliminated.
In the following example, different options are shown for different cases, including using these example hierarchies to display a profit center hierarchy and a
country hierarchy.
Query example 1:
You create a referenced key figure, Profit Center Sales . For your characteristic pair, you choose Profit Center (0PROFIT_CTR) and Partner Profit Center
(0PART_PRCTR). In the query you use the profit center hierarchy. The (internal business volume) amount of $50, which Production Accessories received
internally, is eliminated for this profit center for the next highest level.
Query example 2:
You create a referenced key figure, Country Sales . As your characteristic pair, you choose Country (0COUNTRY) and Partner Country (0PCOUNTRY). In
the query, you use the country hierarchy. The (internal business volume) amount for Europe and the country is eliminated, because the amount of $50 was
counted from Germany to the UK.

Query example 3 (elimination with regard to all characteristic pairs):
You create a referenced key figure, Sales After Elimination , that includes the characteristic pairs
Country (0COUNTRY) and Partner Country (0PCOUNTRY)
Profit Center (0PROFIT_CTR) and Partner Profit Center (0PART_PRCTR)
. Choose the option Elimination with Regard to All Characteristic Pairs . In the query, use the hierarchies displayed above for country and profit center. The
sales are then eliminated for the nodes for which both elimination conditions are fulfilled. In this example, the sales are eliminated on the node level, Europe .
This is because the profit center, as well as both countries DE and UK, are appended underneath, between which the sales are eliminated.
Query example 4 (elimination with regard to each individual characteristic pair):

You create a referenced key figure, Sales After Elimination , that includes the characteristic pairs
Country (0COUNTRY) and Partner Country (0PCOUNTRY)
Profit Center (0PROFIT_CTR) and Partner Profit Center (0PART_PRCTR)
. Choose the option Elimination with Regard to Each Individual Characteristic Pair . In the query, use the hierarchies displayed above for country and profit
center. Then all sales are eliminated that were sent either between Country and Partner Country or between Profit Center and Partner Profit Center . In this
example, the sales are already eliminated from the node level, because the condition already applies for the profit center. The country was not considered for
this node.
Currency Translation
Use
You can use currency translation to translate the key figures with currency fields that exist in the source system in different currencies into a standard
currency in the BI system (for example, the local currency or company currency). Another application serves as the currency difference report, where you can
compare the actual exchange rates with the exchange rates that were valid on the posting date, thus determining the effect of changes to exchange rates. See
also, Scenarios for Currency Translation.
Features
This function enables the translation of posted data records from the source currency into a target currency, or into different target currencies, if translation is
repeated. It is based on the standard SAP function for currency translation.
Currency translation is based on currency translation types. The business transaction rules of the translation are established in the currency translation type.
A combination of various parameters (source and target currency, exchange rate type, time reference for conversion) determine how exchange rate
determination is performed for the translation. See also Currency Translation Types.
Integration
The currency translation type is stored for future use and is available for currency translations in the transformation rules for InfoCubes and in the Business
Explorer:
In the transformation rules for InfoCubes you can specify, for each key figure or data field, whether currency translation is performed during the update. In
special cases you can also run currency translation in user-defined routines in the transformation rules.
See also 1.3.1.4 Currency Translation in the Update.
In the Business Explorer you can:
1. Specify a currency translation in the query definition.
2. Translate currencies at query runtime. Translation is more limited here than in the query definition.
See also Currency Translation in the Business Explorer.

Scenarios for Currency Translation
The following application scenarios are conceivable for currency translation:
Translation into group- or local currency:
Store all values in the document currency in your InfoCube. You want to translate all values in your queries into the group currency. You can use a specific
translation type for this purpose.
You will get values in various currencies from your source system. You would like to store all values in the document currency and in your group currency
(for example, EUR) in the InfoCube.
Store all the values in one currency in your InfoCube. Subsidiaries want to translate these values into their local currency ad hoc in BEx using the
exchange rate for the current day.
Currency difference report:
You want to compare values with both current exchange rates and historical exchange rates. This way you can analyze the effect of exchange rates.
You want to compare the actual exchange rates with those valid on the posting date. This way you can analyze the effect of changes in the exchange
rates between the posting data and the current date.
You want to analyze the effect of exchange rate changes on your plan and actual data.
For this purpose you have created an InfoCube for plan and actual data. The plan data was loaded into the InfoCube with the exchange rate that was valid
when the planning was done. The actual data is translated using the current exchange rate. You then have four key figures in your InfoCube: Plan original
currency, plan group currency, actual original currency, and actual group currency. Now compare plan/actual, each on the level of the original currency and
the group currency. In this way you can analyze the currency translation effects.
1.3.1.4.2 Currency Translation Type
Definition
A translation type is a combination of different parameters that establish how the exchange rate for the translation is determined.
Structure
The parameters that determine the exchange rate are the source and target currencies, exchange rate type and the time reference for the translation.
To define a translation type you have to define the exchange rate type, the time reference, and how and when the inverse exchange rate is used. Entering the

target currency is optional.
Exchange rate type: The exchange rate type distinguishes between exchange rates that are valid in the same time frame, for example, the bid rate, ask
rate or middle rate. The exchange rate types are stored in a central table (TCURV) and can by maintained in Customizing using BI Customizing
Implementation Guide General Settings Currencies Check Currency Types . Alternatively you can specify any variable that exists for
InfoObject 0RTYPE.
Inverse exchange rate: You can choose whether the inverse exchange rate is to be used for the translation type. If you choose translation with the
inverse exchange rate, then the reverse exchange rate is used in the relevant translation from one currency to another. Translation using the inverse
exchange rate is useful, for example, when values from the original documents have been translated before being saved in the data targets and you want
to restore the original values.
You have maintained the following exchange rates:

EUR USD 0.940
USD EUR 1.070
When translating from USD to EUR using the inverse exchange rate, a rate of 1/0.940 = 1.064 is used and not a rate of 1.070.
Source currency: The source currency is the currency that is to be translated. You have the following options:
The source currency is determined dynamically using the data record. This is always the case when you perform currency translation in the Business
Explorer.
The source currency is determined dynamically using a specified InfoObject (characteristic). During the data load process, the source currency can
be determined either using the data record or a specified characteristic bearing master data (see example: Defining Target Currencies Using
InfoObjects. Determining the source currency using an InfoObject is performed in the same way).
You can use a fixed source currency in planning functions. Data records with the same currency key as the source currency are translated.
You can specify any variable that exists for InfoObject 0CURRENCY. You can also use these options in planning functions.
Target currency:
To determine the target currency, you have the following options:
You can establish that the target currency be determined upon translation. In the Query Designer under the properties for the relevant key figure, you
specify either a fixed target currency or a variable to determine the target currency.
You can enter a fixed target currency (for example, EUR).
You can specify any variable that exists for InfoObject 0CURRENCY.
In the currency translation type, you can specify an InfoObject which is used to determine the target currency upon translation. In characteristic
maintenance on the Tab Page: Business Explorer, you have to determine a currency attribute. For more information, see the example under
Defining Target Currencies Using InfoObjects. If the Only Use in Transformation indicator is set, you can also enter InfoObjects that do not have a
currency attribute set in InfoObject maintenance. InfoObjects that are entered here have to be available in the source and contain a currency as an
attribute.
You can specify an InfoSet: This is only necessary if you are determining the target currency using an InfoObject that exists in the InfoSet more than
once. You enter the field alias so that the InfoObject can be specified uniquely.
Time reference: The time reference for the currency translation can be either fixed or variable.
If the time reference is fixed, the time at which the exchange rate is determined is independent of the data. You have the following options:
You can establish that the time reference be determined upon translation.
You can select the current date.
You can specify a fixed date as the key date.
You can specify any variable that exists for InfoObject 0DATE.
You can establish that the query key date be used. This is determined in the query settings.
If the time reference is variable, the time at which the exchange rate is determined is decided by a time characteristic value.
A variable time reference can, for example, be determined using the end or start of a fiscal year or calendar year, a period and a month or even to
the exact day. The following standard time characteristics are available: 0FISCYEAR, 0FISCPER, 0CALYEAR, 0CALQUARTER, 0CALMONTH,
0CALWEEK and 0CALDAY.
The time reference can also be determined using a customer-specific InfoObject of type date (for example, trading day). Note that this InfoObject has
to have the same properties as the standard InfoObject selected in the variable time reference or must reference it.
You can specify an InfoSet: This is only necessary if you are determining the target currency using an InfoObject that exists in the InfoSet more than
once. You enter the field alias so that the InfoObject can be specified uniquely.
In the Business Explorer, you can only set time variable currency translations in query definition, and not for an executed query. See also
Setting Variable Target Currency in the Query Designer.
In the Time Adjustment field of type INT4, you can specify whole numbers with a +/- sign.
In the Time Adjustment from Variable field, you can specify formula variables (1FORMULA). As these values of the variables may have to be whole
numbers, they are rounded to whole numbers (integers) where necessary.
The time adjustment (regardless of whether it is fixed or variable) is always related to the InfoObject specified under Variable Time Reference .
Example of a time adjustment of -3:

The variable time reference is To the exact day and the InfoObject under Variable Time Reference is 0CALDAY. Instead of 07.11.2006, after
the time adjustment, 04.11.2006 is used for the translation.
The variable time reference is End of Week and the InfoObject under Variable Time Reference is 0CALWEEK. Instead of 52.2004, the week
49.2004 is calculated and the end date is calculated from this.
See also:
Creating Currency Translation Types
Currency Translation in the Update
Defining Target Currencies Using InfoObjects

If you want to determine the target currency for currency translation using an InfoObject, proceed as follows:
1. You need a characteristic that can be defined as an attribute for this InfoObject. This characteristic, for example 0CURRENCY, must contain valid
currency units and the corresponding exchange rates have to be maintained.

2. In characteristic maintenance, set the currency attribute for the InfoObject which you are using to determine the target currency.
3. Define a currency translation type in which the target currency will be determined using this InfoObject.
4. In the transformation rules for your InfoCube, specify that the values for the corresponding key figures are to be translated in the transformation and enter
the previously defined translation type.
or
Use the currency translation type for currency translation in BEx.
Example
You want to load data from a CSV file and update it into an InfoCube. The InfoCube has two key figures (kyf1 and kyf2) of type Amount with different unit
InfoObjects.
CSV file extract:
Z_COUNTRY kyf1 kyf_unit1
D 1 USD
CH 2 USD
In the update rules, specify that kyf1 be updated to the InfoCube without changes. kyf2 is filled from the source key figure kyf1 and currency translation is
performed with currency translation type WUA01. In WUA01 you have specified that the source currency be determined from the data record and that
InfoObject Z_COUNTRY be used to determine the target currency.
In InfoObject maintenance on the Business Explorer tab page you have determined a currency attribute for InfoObject Z_COUNTRY 0CURRENCY, for
example. See also Tab Page: Business Explorer
For the kyf2 key figure of the InfoCube to be updated with a currency translation, Z_COUNTRY has to contain the attributes D and CH. Furthermore,
0CURRENCY has to contain valid currency units and corresponding exchange rates have to have been maintained.
Result:
Characteristic bearing master data, Z_COUNTRY:
Characteristic: Z_COUNTRY Currency Attribute: 0CURRENCY
D EUR ...
CH CHF ...
... ... ...
In the transformation rules, 1 USD was translated into EUR and 2 USD into CHF.
Creating Variables for Currency Translation Types
Use
When you create a currency translation type you can use a variable for the exchange rate, target currency or time reference.
Procedure
1. Open the Query Designer.
2. Create a new (dummy) query for an InfoProvider that contains the InfoObjects Exchange Rate Type (0RTYPE), Currency Key (0CURRENCY) or Date
(0DATE), depending on which variable you require. You need this query to be able to create a variable in the Query Designer. For more information, see
Defining New Queriess.
3. Using the symbol next to the relevant InfoObject (0RTYPE, 0CURRENCY or 0DATE) choose the New Variable entry. The variables editor appears.
See also Defining Variabless.
4. Enter a description for the variable.
5. If necessary, change the automatically generated suggestion for the technical name of the variable.
6. Choose the required processing type in the Processing by field . If you choose User Entry/Default Value , the system requests that you enter the
currency in a dialog box in the query.
7. On the Currencies and Units tab page, select an appropriate dimension.
8. Choose OK . The variable is saved with the settings you made and the variables editor closes.
9. Leave the Query Designer.
Result
The variable can be used in the currency translation type.

Creating Currency Translation Types
Prerequisites
If you want to use variables in the currency translation type, you have to create them beforehand. See Creating Variables for Currency Translation Types.
Procedure
1. On the SAP Easy Access screen for SAP NetWeaver Business Intelligence, choose SAP Menu Modeling Object Maintenance
Currency Translation Types .
2. Enter a technical name for the translation type. The name must be between three and ten characters long and begin with a letter. Choose Create. The
Edit Currency Translation Type screen appears.
3. Enter a description.
Exchange Rate Tab Page :

4. Choose Exchange Rate Typ e or Ex. Rate Type from Var. to determine the exchange rate dynamically. With Ex. Rate Type from Var. you can select
any variable that has been created for 0RTYPE using input help.
5. Choose Dynamic Exchange Rate Determination or enter an InfoObject (key figure) to be used to determine the exchange rate. The latter is only
supported with updates.
6. Determine whether you want to perform the currency translation with the inverse exchange rate. In this case, the required translation from one currency to
another is performed using the reverse exchange rate. This can be useful, for example, when values have already been translated and you need to restore
the original values.
Currency Tab Page

7. Under Source Currency , choose whether the source currency is:
Determined using the data record
Based on a fixed source currency
Determined using an InfoObject. Specify the InfoObject you want to use to determine the source currency. For more information, see the example
under Defining Target Currency from InfoObjectss.
Determined using a variable
8. Under Target Currency, choose whether you want to determine the target currency when translation is performed or in the translation type.
If you are determining the target currency upon translation, you can either specify a fixed target currency in the Query Designer (as a property of a key
figure of type Amount ) or specify a variable to be used to determine the target currency. See Setting Variable Target Currencies in the Query Designer.
If the target currency is to be determined in the translation type, choose either
A fixed target currency
A target currency from a variable; you can use input help to select any variable that has been created for 0CURRENCY
Alternatively, an InfoObject from which the target currency is to be determined
Note that with InfoSets, the InfoObject can occur several times within the InfoSet and therefore may not be unique. In this case, you have to
specify the unique field alias name of the InfoObject in the InfoSet. The field alias name consists of: <InfoSet name><three
underscores><field alias>. You can display the field alias in the InfoSet Builder using Switch Technical Name On/Off .
Example: In the InfoSet ISTEST, characteristic 0CURR occurs twice. The field alias names are ISTEST___F00009 and ISTEST___F00023.
Time Reference Tab Page

9. Select a fixed or a variable time base for the currency translation.
With a fixed time reference, you can choose between:
Selection upon translation
Current date
Fixed key date
Time reference using a variable (variable for 0DATE)
Query key date . In this case, the time reference is the key date that is set in the query properties in the Query Designer.
With a variable time reference, you can choose:
Standard InfoObject (standard time characteristic: 0FISCYEAR, 0FISCPER, 0CALYEAR, 0CALQUARTER, 0CALMONTH, 0CALWEEK or
0CALDAY), which is used to determine the time of the translation
Special InfoObject. This special InfoObject has to have the same properties as the standard InfoObject or it has to reference the standard
InfoObject. The aforementioned notes on using InfoSets also apply here.
In the Time Adjustment field, whole numbers with +/- sign
In the Time Adjustment from Variable field, you can specify formula variables (1FORMULA)
The time adjustment (regardless of whether it is fixed or variable) is always related to the InfoObject specified under Variable Time Reference .
10. Save your entries.
Result
The currency translation type is available for translating currencies when you perform a transformation for InfoCubes and when you analyze data in the
Business Explorer.
See also:
Currency Translation Type

Transferring Exchange Rates for Currencies from SAP Systems
Use
You use this function to upload exchange rates for currencies from other SAP systems into the TCURR table in your BI system.
Procedure
1. In the Data Warehousing Workbench under Modeling, choose the source system tree .
2. In the context menu of your SAP Source System , choose Transfer Exchange Rates . The Transfer Exchange Rates: Selection screen appears.
3. Choose the exchange rate type that you want to load and the date from which changes should be transferred.
4. Under Mode you can select whether you want to simulate upload or update or copy the exchange rates. With the Update exchange rates option,
existing records are updated. With the Recopy exchange rates option, table TCURR is deleted before new records are loaded.
5. Choose Execute .
See also:
Exchange Rates for Currencies from Flat Files
Transferring Global Table Entries for Currencies from SAP Systems
Use
You use this function to transfer all the tables relevant to the currency translation from the other SAP systems connected to the BI system. Specifically, this
includes the following tables:
TCURC (Currency codes)
TCURF (Translation ratios)
TCURN (Notations)
TCURS (Exchange rate spreads)
TCURT (Description of currency codes)
TCURV (Exchange rate types for currency translation)
TCURW (Usage of exchange rate types)
TCURX (Decimal places for currencies)
Procedure
1. In the Data Warehousing Workbench under Modeling , choose the source system tree.
2. In the context menu of your SAP Source System , choose Transfer Global Settings . The Transfer Global Settings: Selection screen appears.
3. Under Transfer Global Table Contents, select the Currencies field.
5. Choose Execute .
See also:
Transferring Global Settings
Exchange Rates for Currencies in Flat Files
Use
You use this function to upload exchange rates for currencies into table TCURR in your BI system from a flat file. This is necessary if your BI system is not
connected to an SAP system and the table cannot receive input from an SAP system.
If your BI system is connected to an SAP system, proceed as described in:
Transferring Exchange Rates for Currencies from SAP Systems
Prerequisites
Your flat file should have the following format (corresponds to table TCURR without CLIENT field):
Field Data Type Length Decimal Places Meaning

KURST CHAR 4 0 Exchange rate type
FCURR CUKY 5 0 From currency
TCURR CUKY 5 0 To currency
GDATU CHAR 8 0 Date when the rate will be valid
UKURS DEC 9 5 Exchange rate
FFACT DEC 9 0 Factor for the units of the

from currency
TFACT DEC 9 0 Factor for the units of the to

currency
The date (field: GDATU) must be in internal format (YYYYMMDD).

The decimal character in the UKURS field has to correspond to the settings selected in Customizing ( SAP Customizing Implementation Guide SAP
NetWeaver Business Information Warehouse Connections to Other Systems Connection Between Flat File and BI Setting Options for
Uploading Flat Files ).
Example for a table with periods as decimal points:
KURST FCURR TCURR GDATU UKURS FFACT TFACT
M EUR USD 20020101 1.00010 0 0
B EUR USD 20020112 0.98300 0 0
Example for structure of a CSV file with ';' as separator:
M;EUR;USD;20020101;1.00010;0;0
B;EUR;USD;20020112;0.98300;0;0
See also:
Uploading Exchange Rates from Flat Files
Uploading Exchange Rates from Flat Files
Procedure
1. In the Data Warehousing Workbench under Modeling , choose the source system tree .
2. In the context menu of your source system (for example PC_FILE), choose Transfer Exchange Rates . The Transfer Exchange Rates: Selection screen
appears.
3. Select where you want to load your file from. You differentiate between files that are on the application server and files that are on client workstations.
Select your file and specify the separator that is being used. Only CSV files are allowed as the file type.
After the data has been uploaded from the CSV file, the OLAP caches are invalidated so that the system uses the new exchange rates during translation.
5. Choose Execute .
If the CSV file contains exchange rate types that do not exist in the BI system (table TCURV), this will be noted in the log. Entries are
displayed as follows: exchange rate type &cv1 not in TCURV table. The data from the CSV file is then written to the TCURR table. The
missing entries for TCURV can be maintained manually in the IMG ( SAP Customizing Implementation Guide SAP NetWeaver SAP
Business Information Warehouse General Settings Currencies Check Exchange Rate Types ).
Currency Translation During Transformation
Use
Currency translation during the transformation enables you to convert data records from the source currency into a currency of the target of the transformation.
Currency translation in the transformation is generally performed using previously defined translation types. For more information, see Currency Translation
Types.
Where required, you can perform currency translation with user-defined subprograms (formulas and routines). It is not currently possible to execute currency
translation for DataStore objects using predefined translation types. You have to use routines instead.
Depending on the type of currency, there are two different types of key figures:
1. Key figures with a fixed currency (for example, DEM, USD)
With a fixed currency, the currency is fixed for the amount. The key figure refers specifically to the currency (for example DM, US$), so the currency does
not have to be entered again in the data record.
2. Key figures with a variable currency (for example, foreign currency).

With a variable currency, the currency is determined by an InfoObject, (ODOC_CURRCY) for example.
For more information, see Creating InfoObjects: Key Figures.
Features
Transformations can be performed for key figures in two ways:
1. Every key figure in an InfoCube (target key figure) has a corresponding key figure in the source (source key figure). No currency translation takes place.
2. There is no corresponding source key figure in the InfoSource for the target key figure in the InfoCube.
a. You can assign a source key figure of the same type to the target key figure (sales revenue instead of sales quantity revenue, for example).
If the currencies of both of the key figures are the same, no currency translation can take place.
If the currencies are different, a translation can take place either using a currency translation type or by simply assigning a currency.
The following table provides an overview of possible combinations where the currency is not the same in the source and target key figures:
Source key figure currency Target key figure currency Currency translation (CT)
fixed variable No CT
fixed fixed CT
variable fixed CT
variable variable CT or assignment possible
b. If there is no corresponding source key figure of the same type, you have to fill the key figure of the target using a routine.
If the currency of the target key figure is fixed, currency translation is not performed. This means that if translation is required, you have to
execute it in a routine.
If the currency of the target key figure is variable, you also have to assign a variable source currency to the routine. You can use input help to
select a currency from the variable currencies that exist for the target. You have two options:
You can select a variable currency and assign it.
You can select a currency translation type and a currency into which you wish to translate (to currency).
By default, the to currency is the target currency if it is included in the target.
Creating a routine for currency translation:

If you want to translate currencies during the transformation but currency translation is not available for one of the reasons stated above, you can create a
routine. In transformation rule definition, choose Routine with Unit . You get an additional return parameter UNIT in the routine editor and the target currency is
determined using the value of this parameter.
For more information, see Routines in Transformations.
Currency Translation in the Business Explorer
Prerequisites
You previously created one or more currency translation types.
More information: Creating Currency Translation Types
Features
When you want to translate a currency from key figures in the query, you can specify the translation type in two places:
1. In the query definition for individual key figures or structure elements
2. In the executed query, using the context menu for all elements of key figure type Amount
Currency Translation According to Query Definition

A more complex currency translation is available in the query definition. You can specify how the individual elements (key figures of type Amount ) of the
query are to be translated. One currency translation type can be specified for each element. Note that this can lead to overlays of two different translation
types in one cell. The translation type that you most recently set is always used. See also the example Multiple Currency Translation Types in One Query.
Depending on the definition of the target currency determination in the currency translation type, either a fixed target currency or a variable for the
determination of the target currency can also be specified.
See the section Currency Translation in Selection/Formula Properties.
If a variable is used, the system requests the variable when you execute the query. Information about the procedure: Setting Variable Currency Translation in
the Query Designer
The values of a query can, on the one hand, exist in different currencies, depending on the respective elements and the selected translation. On the other
hand, various modalities for translation are to be taken into consideration (for example, a translation of plan data is carried out using year-dependent exchange
rates and a translation of actual data is performed using month-dependent exchange rates).
Currency Translation in the Executed Query

In the BEx Analyzer, you can choose Query Properties in the context menu for the key figure to convert the displayed currency in various ways.
Convert to Currency as Defined in Query Definition: Complex currency translations can be configured using the BEx Query Designer. If such a translation

has been configured in your query, this function is available and you can use it in your query results.
Convert to Currency: Select this option to translate results into a specific currency. In the dropdown box, select the currency into which the results are to
be translated.
Use Currency Translation : after you have selected the target currency for the results, select the type of translation to be used for the conversion
from this dropdown box.
Consider Translation from Query Definition : select this checkbox to first convert into the currency defined in the query, and then into the currency as
customized in these settings.
Show Original Currency: Select this option to disable currency conversions.
More information: Query Properties
In BEx Web applications, a simple currency translation is also available in the context menu. However, in the input help for the target currency, only the
currencies for which exchange rates are maintained in the system are displayed, whereas all currencies are displayed in the BEx Analyzer.
More information: Making Currency Translations
Restrictions:
The following currency translation types are not available at the runtime of the query.
Inactive translation types
Translation types for which a variable is stored (variable time reference, source currency from variable, target currency from variable, and so on)
Translation types in which an InfoObject is used for determining the source currency or target currency
Currency Translation Is Possible

Generally only when selection elements are used (formulas are applied to values that have already been translated)
When formula variables with the dimensions Amount and Price are used
When formula variables with replacement paths are used
With key figure attributes if the key figure is of type Amount
Setting Variable Target Currency in the Query Designer
Prerequisites
You have created a currency translation type. You have selected the Selection of Target Currency with Translation option on the Target Currency tab page
in this translation type.
Procedure
1. You are in the Query Designer. In the properties for your key figure of type amount, choose the Translations tab page.
2. Select your translation type under Currency Translation .
3. Select the Variables Entry field and choose New Variable. The variables editor appears. See Defining Variables.
6. In the Processing by field, choose the processing type User Entry/Default Value. The Currency characteristic (0CURRENCY) is the default.
7. Under Details , choose between the following input options:
optional
mandatory
mandatory, initial values not permitted
This field is ready for input by default.
8. Assign a default value for the variable.
9. Choose OK . The variable is saved with the settings you have made and the variables editor closes.
Result
When you execute the query, the system requests the variable for the target currency.
Multiple Currency Translation Types in One Query

In the following a query with two structures will be considered. The structure element of the column is the key figure Net Sales. The structure elements of the
lines are comprised of specifications from the Country characteristic. If currency translation types are defined for both structures, there can be overlays form
two different translation types in one cell. Then it depends on the order in which you defined the translation conversion types. The translation type that you last
set always takes precedence, even within a structure.
Prioritization will be clarified using the following examples. The numbers show in which sequence the individual elements were defined in the Query Designer of
a currency translation type. The following examples refer to this sequence. If the structure element in the Net Sales column has a translation type, it always
has USD as the target currency. The structure elements from the lines are always translated into the respective country currency (England GBP, Canada
CAD, Switzerland CHF, Germany EUR) as long as they have a translation type.
Structure elements of the lines:

Structure element of the column:
Example 1:
None of the elements have a defined currency translation type, that is, all currencies will be displayed in the currency DB:
Example 2:
A currency translation type with a target currency of USD is defined for the net sales key figure:
Example 3:
Only one currency translation is defined in the structure element of the line. The translation should be performed into each countrys currency.
Example 4:
First a currency translation type is defined for the structure element of the line for Canada. The translation is made into CAD. Then a currency translation type
is defined for the structure element of the line for Switzerland the translation should be made into CHF. Then a currency translation type is defined for the
key figure net sales, which stipulates that the translation should be into USD (see mapping of the structures above: 1, 2, 3):

Example 5:
The example is structured exactly as in 4), with the only difference being that a translation type for Germany and England is defined afterwards for the
structure elements of the line. Both are translated into the countrys currency (see mapping of the structures above: 1, 2, 3, 4, 5):
Example 6:
The example is structured exactly as in 5), with the only difference being that a translation type for Canada and Switzerland is defined afterwards for the
structure elements of the line. Both are translated into the country currency (see mapping of structures above: 1, 2, 3, 4, 5, 6, 7):
Currency and Unit Display in Business Explorer
Use
There are various settings for displaying currencies in Business Explorer.
Features
Displaying currencies and units in the results area of a query

Values in different currencies can be fundamentally aggregated and attached by calculation to the querys results area. Linked values from different currencies
are displayed differently to values that have a common currency however. This means that there are two different cases for displaying values and currencies
when analyzing data in Business Explorer.
If all the values that go into the cell of the results area for the query have the same currency, the value belonging to it is displayed in this currency.
In certain situations, it is impossible to clearly specify number values and texts for currencies or units. In these cases, predefined texts are displayed
instead of number values and currencies or units.
If there is a division by zero in the calculation of a number value, 0/0 is displayed.
If a number value cannot be found, NOP is displayed (does not exist).
If a number value cannot be calculated due to a numeric overflow or another undefined mathematic function (for example ), the output becomes
X.
If the values that go into a cell have different currencies, then the value is displayed in a numerical, aggregated form there will be a placeholder for the
currency. The symbol * is displayed instead of a currency identifier.
The following rules are valid for aggregation behavior in the OLAP processor example:
3 USD + 5 EUR = 8 *
3 USD + 0 EUR = 3 USD
0 USD + 0 EUR = 0 USD or 0 EUR, depending on the sequence
3 USD - 3 USD + 5 EUR = 5 EUR
3 USD + 5 EUR - 3 USD = 5 *
3 USD + 5 = 8 *, since it is an initial currency = currency ERROR
To drilldown further by currency, you must define the characteristic Currency/Unit as a free characteristic in the query definition. The amounts you

specified for the different currencies can now be entered into the query cells by drilling down on Currency/Unit (1 CUDIM).
As an alternative, you can also display the various currencies in the query monitor ( SAP Easy Access Business Explorer BEx Monitor
Query Monitor ). Execute the query and choose Key Figure Definition from the results list. Currencies and units are always broken down for
display never aggregated.
Results area with different currencies
Country Actual Revenue Currency Key Plan Revenue Currency Key
USA 734 USD 700 USD
Germany 82 EUR 50 USD
Switzerland 70 * 50 USD
Result 886 * 800 USD
Drilldown by currency/unit
Country Currency/Unit Actual Revenue Currency Key Plan Revenue Currency Key
USA USD US Dollar 734 USD 700 USD
Germany EUR Euro 82 EUR 50 USD
Switzerland EUR Euro 40 EUR
CHF Swiss Franks 30 CHF
USD US Dollar 50 USD
Result 886 * 800 USD
If a user is not authorized to display a certain number value of a cell in the active query, the text can be displayed in the cell instead.
If a calculated number value is made up of different currencies or units, the use can choose whether or not to display the number value. Choose mixed
values to display the number value. If the mixed values setting is not active, the text that you entered under mixed currencies is displayed.
You can change these predefined texts in Customizing. To do this, choose SAP Customizing Implementation Guide SAP NetWeaver SAP
Business Information Warehouse Reporting-Relevant Settings General Reporting Settings in Business Explorer Display of Numerical
Values in Business Explorer .
Displaying the currency key

The currency key can be displayed only in the column heading under the following conditions instead of before or after the currency value:
The currency for a query was translated into a common target currency.
The data source only provides one currency so that a translation into a common target currency is not necessary.
To display the currency key in the column header, select Properties on the column in question using the context menu. Under Display , select Scaling
Factors for Displaying Key Figures and choose OK. The currency key is taken from the column fields and displayed in the column header.
Also note the Priority Rule for Formatting Settings for this kind of formatting settings.
Setting up the currency display

In Customizing, you can make settings for how you want to display the currencies. You can decide which key you want each currency to be displayed with,
and whether the key comes before or after the value.
Currency (ISO norm) Alt. Text Before or After Value
EUR EUR After value
USD $ Before value
GBP Before value
The values above are displayed for each default setting as shown in the example. You can change these settings in Customizing if required.
To make the settings in Customizing, from the SAP Customizing Implementation Guide , choose SAP NetWeaver SAP Business Information
Warehouse Reporting-relevant Settings Set Alternative Display for Currencies .
1.3.1.5 Quantity Conversion
Use
Quantity conversion allows you to convert key figures with units that have different units of measure in the source system into a uniform unit of measure in the
BI system.

Features
This function enables the conversion of updated data records from the source unit of measure into a target unit of measure, or into different target units of
measure, if the conversion is repeated. In terms of functionality, quantity conversion is structured similarly to currency translation.
In part it is based on the quantity conversion functionality in SAP NetWeaver Application Server. Simple conversions can be performed between units of
measure that belong to the same dimension (such as meters to kilometers, kilograms to grams). You can also perform InfoObject-specific conversions (for
example, two palettes (PAL) of material 4711 were ordered and this order quantity has to be converted to the stock quantity Carton (CAR)).
Quantity conversion is based on quantity conversion types. The business transaction rules of the conversion are established in the quantity conversion type.
The conversion type is a combination of different parameters (conversion factors, source and target units of measure) that determine how the conversion is
performed. For more information, see Quantity Conversion Types.
Integration
The quantity conversion type is stored for future use and is available for quantity conversions in the transformation rules for InfoCubes and in the Business
Explorer:
In the transformation rules for InfoCubes you can specify, for each key figure or data field, whether quantity conversion is performed during the update. In
certain cases you can also run quantity conversion in user-defined routines in the transformation rules.
For more information, see Quantity Conversion in Transformations.
In the Business Explorer you can:
Establish a quantity conversion in the query definition.
Translate quantities at query runtime. Translation is more limited here than in the query definition.
General Information About Quantity Conversion

The conversion of units of measure is required to convert business measurements into other units. Business measurements encompass physical
measurements which are either assigned to a dimension or are nondimensional. Nondimensional measurements are understood as countable measurements
(palette, unit..).
You differentiate between conversions for which you only need to enter a source and target unit in order to perform conversion and conversions for which
specifying these values alone is not sufficient. For the latter, you have to enter a conversion factor which is derived from a characteristic or a characteristic
combination (compound characteristic) and the corresponding properties.
1. Measurements of length
Conversions within the same dimension ID (T006-DIMID) for example, length:
1 m = 100 cm (linear correlation)
Meter and Centimeter both belong to dimension ID LENGTH.
2. Measurements of number associated with measurements of weight
Conversions involving different dimension IDs for example, number and weight.
1 unit = 25 g (linear correlation)
Unit has dimension ID AAAADL and Gram has dimension ID MASS.
Example
Number Unit Number Unit
1 Chocolate bar = 25 g
1 Small carton = 12 Chocolate bar
1 Large carton = 20 Small carton
1 Europallet = 40 Large carton
Question: How many chocolate bars fit on one europallet (PAL)?

Prerequisites for InfoObject-Specific Quantity Conversion
Use
In principle, every characteristic that contains at least one unit as an attribute can be used for quantity conversion.
Prerequisites
You have made the following settings in characteristic maintenance on the Business Explorer tab page.
Specify a Basic Unit of Measure

The conversion of units always takes place based on the base unit of measure (as with material management conversion, table MARM R/3).
Create a Unit of Measure for the Characteristic

When creating a unit of measure for the characteristic, the system creates a DataStore object for units of measure.
You can specify the name of the quantity DataStore object, the description, and the InfoArea into which you want to add the object. The system proposes the
name: UOM<Name of InfoObject to which the quantity DataStore Object is being added>.
With objects of this type, the system generates an SID column in the database table for each characteristic and stores the characteristic attributes in the form
of SIDs.
The SID columns are automatically filled in the transformation and may not be changed in the end routine.
Assignments of quantity DataStore objects to characteristics are 1:1. This means that only one characteristic can be assigned to a quantity DataStore object
and one quantity DataStore object can be assigned to a characteristic.
You cannot enhance or change a quantity DataStore object in DataStore object maintenance because the object is generated by the system.
You can only display it.
You can fill the quantity DataStore object with data only by using a data transfer process with transformation; update rules are not supported in
this case.
If a characteristic that has a quantity DataStore object assigned to it is changed at a later time or date, (for example, changes to compounding or to the base
unit of measure), you have to delete the quantity DataStore object and regenerate it. In practice, this does not occur after the data model has been finalized.
Structure or quantity DataStore objects:
Key <Characteristic>
Key <Compounding for characteristic, where applicable>
Key <Unit of measure that you can convert into>
<Base unit of measure>
<Conversion factor: Counter>
<Conversion factor: Denominator>
<SID_Characteristic>
<SID_Compounding for characteristic, where applicable>
<SID_Unit of measure that you can convert into>
<SID_Base unit of measure>
1.3.1.5.3 Quantity Conversion Types
Definition
A quantity conversion type is a combination of different parameters that establish how the conversion is performed.
Structure
The parameters that determine the conversion factors are the source and target unit of measure and the option you choose for determining the conversion
factors.

The decisive factor in defining a conversion type is the way in which you want conversion factors to be determined. Entering source and target quantities is
optional.
Conversion Factors
The following options are available:
Using a reference InfoObject
The system tries to determine the conversion factors from the reference InfoObject you have chosen or from the associated quantity DataStore object.
If you want to convert 1000 grams into kilograms but the conversion factors are not defined in the quantity DataStore object, the system cannot perform
the conversion, even though this is a very simple conversion.
Using central units of measure (T006)
Conversion can only take place if the source unit of measure and target unit of measure belong to the same dimension (for example, meters to kilometers,
kilograms to grams, and so on).
Using reference InfoObject if available, central units of measure (T006) if not
The system tries to determine the conversion factors using the quantity DataStore object you have defined. If the system finds conversion factors, it uses
these to perform the calculation. If the system cannot determine conversion factors from the quantity DataStore object it tries again using the central units
of measure.
Using central units of measure (T006) if available, reference InfoObject if not
The system tries to find the conversion factors in the central units of measure table. If the system finds conversion factors it uses these to perform the
conversion. If the system cannot determine conversion factors from the central units of measure it tries to find conversion factors that match the
attributes of the data record by looking in the quantity DataStore object.
The settings that you can make in this regard affect performance and the decision must be strictly based on the data set.
If you only want to perform conversions within the same dimension, option 2 is most suitable.
If you are performing InfoObject-specific conversions (for example, material-specific conversions) between units that do not belong to the same dimension,
option 1 is most suitable.
In both cases, the system only accesses one database table. That table contains the conversion factors.
With option 3 and option 4, the system tries to determine conversion factors at each stage. If conversion factors are not found in the basic table (T006), the
system searches again in the quantity DataStore object, or in reverse.
The option you choose should depend on how you want to spread the conversion. If the source unit of measure and target unit of measure belong to the same
dimension for 80% of the data records that you want to convert, first try to determine factors using the central units of measure (option 4), and accept that the
system will have to search in the second table also for the remaining 20%.
The Conversion Factor from InfoObject option (as with Exchange Rate from InfoObject in currency translation types) is only available when you load data.
The key figure you enter here has to exist in the InfoProvider and the attribute this key figure has in the data record is taken as the conversion factor.
Source Unit of Measure

The source unit of measure is the unit of measure that you want to convert. The source unit of measure is determined dynamically from the data record or
from a specified InfoObject (characteristic). In addition, you can specify a fixed source unit of measure or determine the source unit of measure using a
variable.
When converting quantities in the Business Explorer, the source unit of measure is always determined from the data record.
During the data load process the source unit of measure can be determined either from the data record or using a specified characteristic that bears master
data.
You can use a fixed source unit of measure in planning functions. Data records are converted that have the same unit key as the source unit of measure.
The values in input help correspond to the values in table T006 (units of measure).
You reach the maintenance for the unit of measure in SAP Customizing Implementation Guide SAP NetWeaver General Settings Check Units
of Measure .
In reporting, you can use a source unit of measure from a variable. The variables that have been defined for InfoObject 0UNIT are used.
Target Unit of Measure

You have the following options for determining the target unit of measure:
You can enter a fixed target unit of measure in the quantity conversion type (for example, UNIT).
You can specify an InfoObject in the quantity conversion type that is used to determine the target unit of measure during the conversion. This is not the
same as defining currency attributes where you determine a currency attribute on the Business Explorer tab page in characteristic maintenance. With
quantity conversion types you determine the InfoObject in the quantity conversion type itself. Under InfoObject for Determining Unit of Measure , all
InfoObjects are listed that have at least one attribute of type Unit . You have to select one of these attributes as the corresponding quantity attribute.
Alternatively, you can determine that the target unit of measure be determined during the conversion. In the Query Designer under the properties for the

relevant key figure, you specify either a fixed target unit of measure or a variable to determine the target unit of measure.
Target quantity using InfoSet
This setting covers the same functionality as InfoObject for Determining Target Quantity . If the InfoObject that you want to use to determine the target
quantity is unique in the InfoSet (it only occurs once in the whole InfoSet), you can enter the InfoObject under InfoObject for Determining Target
Quantity .
You only have to enter the InfoObject in Target Quantity Using InfoSet if you want to determine the target quantity using an InfoObject but that occurs
more than once in the InfoSet.
The InfoSet contains InfoProviders A and B and both A and B contain InfoObject X with a quantity attribute. In this case you have to specify
exactly whether you want to use X from A or X from B to determine the target quantity. Field aliases are used in an InfoSet to ensure
uniqueness.
All the active InfoSets in the system can be displayed using input help. As long as you have selected an InfoSet, you can select an
InfoObject. All the InfoObjects with quantity attributes contained in the InfoSet can be displayed using input help.
Defining Target Units of Measure Using InfoObjects

If you want to determine the target unit of measure for quantity conversion using an InfoObject, proceed as follows:
1. You require a characteristic that has at least one unit as an attribute. This characteristic, for example 0PO_UNIT, has to contain valid units of measure
and the corresponding conversion rates have to be maintained (either specific to an InfoObject or in the central units of measure).
2. Define a quantity conversion type in which the target unit of measure will be determined using this InfoObject.
3. In Associated Quantity Attribute , set the quantity attribute for the InfoObject which you are using to determine the target quantity.
4. In the transformation rules for your InfoCube, specify that the values for the corresponding key figures are to be translated in the transformation and enter
the previously defined translation type. The InfoObject specified in the quantity conversion type must exist in both the source and the target system and
be filled using a rule.
Example
You want to load data from a CSV file and update it into an InfoCube. The InfoCube has two key figures (kyf1 and kyf2) of type Unit with different unit
InfoObjects.
CSV file extract:
Z_COUNTRY kyf1 kyf_unit1
D 1 PAL
CH 2 BX
In the transformation rules, specify that kyf1 be updated to the InfoCube without changes. kyf2 is filled from the source key figure kyf1 and the unit of measure
conversion is performed using quantity conversion type WUA01. In WUA01 you have specified that the source unit of measure be determined from the data
record and that InfoObject Z_COUNTRY be used to determine the target unit of measure.
You have already chosen the associated quantity attribute 0PO_UNIT for InfoObject Z_COUNTRY.
In order that key figure kyf2 of the InfoCube is updated with the quantity conversion, Z_COUNTRY must contain the attributes D and CH. Furthermore,
0PO_UNIT has to contain valid units of measure and corresponding conversion rates have to have been maintained.
Result:
Characteristic bearing master data, Z_COUNTRY:
Characteristic: Z_COUNTRY Quantity Attribute: 0PO_UNIT
D CAR
CH UNIT
In the transformation rules, 1 PAL was converted into CAR and 2 BX into UNIT.
Creating Variables for Quantity Conversion Types
Use
When you create a quantity conversion type you can use a variable for the source and target unit of measure.
Procedure
1. Open the Query Designer.

2. Create a new (dummy) query for an InfoProvider that contains the Unit InfoObject (0UNIT). You need this query to be able to create a variable in the
Query Designer. For more information, see Defining New Queriess.
3. Using the symbol next to the InfoObject 0UNIT choose the entry New Variable . The variables editor appears. See also Defining Variabless.
6. Choose the required processing type in the Processing by field . If you choose User Entry/Default Value , the system requests that you enter the unit
of measure in a dialog box in the query.
7. On the Currencies and Units tab page, select Quantity as the dimension.
8. Choose OK . The variable is saved with the settings you made and the variables editor closes.
9. Leave the Query Designer.
Result
The variable can be used in the quantity conversion type.
1.3.1.5.3.3 Creating Quantity Conversion Types
Prerequisites
If you want to use variables in the quantity conversion type, you have to create them beforehand. See Creating Variables for Quantity Conversion Types.
Procedure
1. On the SAP Easy Access screen for SAP NetWeaver Business Intelligence, choose SAP Menu Modeling Object Maintenance Unit
Conversion Types .
2. Enter a technical name for the conversion type. The name must be between three and ten characters long and begin with a letter. Choose Create.
The Edit Quantity Conversion Type screen appears.
3. Enter a description.
Tab page Conversion Factors

4. Choose Dynamic Determination of Conversion Factor or Conversion Factor from InfoObject .
5. If you choose Dynamic Determination of Conversion Factor you have to enter further information in the dropdown box. For more information, see the
conversion factors section in Quantity Conversion Types.
Tab Page Unit of Measure

6. Under Source Unit of Measure , choose whether the source unit of measure
is determined using the data record
has a fixed unit of measure
is determined using an InfoObject. Specify the InfoObject you want to use to determine the source unit of measure.
is determined using a variable.
7. Under Target Unit of Measure , choose whether the target unit of measure
is selected during the conversion
has a fixed unit of measure
is determined using a variable
is determined using an InfoObject. Specify the InfoObject you want to use to determine the target unit of measure.
Note that with InfoSets, the InfoObject can occur several times within the InfoSet and therefore may not be unique. In this case you have to
specify the unique field alias name of the InfoObject in the InfoSet. The field alias name consists of: <InfoSet name><three
underscores><field alias>. You can display the field alias in the InfoSet Builder using Switch Technical Name On/Off .
Result
The quantity conversion type is available for converting quantities in the update of InfoCubes and with data analysis in the Business Explorer.
Transferring Global Table Entries for Units of Measure from SAP

Systems
Use
You use this function to transfer all the tables relevant for unit conversion from other SAP systems connected to the BI system. Specifically, this includes the

following tables:
T006
T006A
T006B
T006C
T006D
T006I
T006J
T006T
Procedure
1. In the Data Warehousing Workbench under Modeling , choose the source system tree .
2. In the context menu of your SAP Source System , choose Transfer Global Settings . The Transfer Global Settings: Selection screen appears.
3. Under Transfer Global Table Contents, select the Units of Measure field.
4. Under Mode you can select whether you want to simulate upload or update or copy the tables again. With the Update Tables option, existing records
are updated. With the Rebuild Tables option, the corresponding tables are deleted before the new records are loaded.
5. Choose Execute .
Quantity Conversion During the Transformation
Use
Quantity conversion during the transformation enables you to convert data records from the source unit of measure into a unit of measure of the target of the
transformation.
Quantity conversion in the transformation is generally performed using previously defined conversion types. For more information, see Quantity Conversion
Types.
Where required, you can perform quantity conversion with user-defined subprograms (formulas and routines). It is not currently possible to execute quantity
conversion for DataStore objects using predefined conversion types. You have to use routines instead.
Depending on the type of unit of measure, there are two different types of key figures:
1. Key figures with fixed unit of measure
With a fixed unit of measure, the unit is fixed for the key figure. The key figure refers specifically to the unit of measure so the unit does not have to be
entered again in the data record.
2. Key figures with variable unit of measure
A variable unit of measure references an InfoObject.
For more information, see Creating InfoObjects: Key Figures.
Features
Transformations can be performed for key figures in two ways:
1. Every key figure in an InfoCube (target key figure) has a corresponding key figure in the source (source key figure). Quantity conversion is not performed.
2. There is no corresponding source key figure in the InfoSource for the target key figure in the InfoCube.
a. You can assign a source key figure of the same type to the target key figure.
If the units of measure of both key figures are the same, no quantity conversion can take place.
If the units of measure are different, a conversion can take place either using a quantity conversion type or by simply assigning a unit of
measure.
b. If there is no corresponding source key figure of the same type, you have to fill the key figure of the target using a routine.
If the unit of measure of the target key figure is fixed, quantity conversion is not performed. This means that if conversion is required, you have
to execute it in a routine.
If the unit of measure of the target key figure is variable, you also have to assign a variable source unit of measure to the routine. You can use
input help to select a unit of measure from the variable units of measure that exist for the target. You have two options:
You select a variable unit of measure and assign it.
You select a quantity conversion type and a unit of measure into which you wish to convert.
Conversion Using a Quantity Conversion Type

If you have chosen an InfoObject for determining the target unit of measure in the quantity conversion type, you must heed the following when maintaining the
transformation rules:
The InfoObject for determining the target unit of measure must be contained in both the source and target systems and must be filled using a rule.
For more information, see Defining Target Units of Measure Using InfoObjects.
Routines for Quantity Conversions

If you want to convert units of measure during the transformation but quantity conversion is not available for one of the reasons stated above, you can create a
routine. In transformation rule definition, choose Routine with Unit . In the routine editor you get an additional return parameter UNIT and the target unit of

measure is determined using the value of this parameter.
For more information, see Routines in Transformations.
Quantity Conversion in the Business Explorer
Prerequisites
You have created one or more quantity conversion types.
See also Creating Quantity Conversions Types.
Features
If you want to convert the units of measure of the key figures in the query, you can determine the conversion type for the individual key figures or structure
elements in query definition. You can determine how the individual elements (key figures of type: amount) of the query are to be converted. You can specify
one quantity conversion type for each element.
Depending on how the target quantity determination is defined in the quantity conversion type, you can either specify a fixed target quantity or a variable that
the system uses to determine the target quantity.
See the unit conversion section in Properties of the Selection/Formula.
If a variable is used, the system will request the variable when you execute the query. For information on the procedure, see Setting Variable Target Units of
Measure in the Query Designer.
Setting Variable Target Units of Measure in the Query Designer
Prerequisites
You have created a quantity conversion type. You have selected the Selection of Unit of Measure During Conversion option on the Unit of Measure tab
page in this conversion type.
Procedure
1. You are in the Query Designer. In the properties for your amount key figure, choose the Translations tab page.
2. Under Unit Conversion, select your conversion type.
3. Select the Variables Entry field and choose New Variable. The variables editor appears. See also Defining Variables.
6. In the Processing by field, choose the processing type User Entry/Default Value. The unit of measure characteristic (0UNIT) is the default.
7. Under Details , specify whether the entry is to be:
Optional
Mandatory
Mandatory, initial values not permitted
8. Allocate a default value for the variable.
9. Choose OK . The variable is saved with the settings you made and the variable editor closes.
Result
When you execute the query the system requests the variable for the target unit of measure.
1.3.1.5.6 Quantity Conversion Scenarios

The following scenario represents one case in which quantity conversion is used.
You get values from your source system in various order units. You want to store all the values in the InfoCube in a uniform quantity (for example, UNIT).
You can use the example data to visualize how quantity conversion is performed using the different options available. You can choose from two sets of
example data, depending on how your data is staged. Examples are provided for both sets of example data:
Example Data Without Compounding
Example Data With Compounding

Example Data Without Compounding
1a) Master Data: Characteristic CMAT07
#CMAT07 0base_uom 0apo_storgu

Base Unit of Measure Stock Level
4711 UNIT PAL
4712 KG PAL
4713 UNIT PAL
The unit 0base_uom is entered as the base unit of measure in master data maintenance on the Business Explorer tab page.
The DataStore Object UOM07 is also created and activated in master data maintenance ( tab page: Business Explorer Units of Measure for Char. ).
The structure of a DataStore Object always complies with the following rule:
<characteristic> <compounding for characteristic, where applicable>
<target unit of measure> <base unit of measure> <conversion factor: counter>
<conversion factor: denominator> <SID columns for all characteristics>
1b) Quantity DataStore Object: UOM07 (SID columns are not listed in the following table)
#Cmat07 #0unit 0base_uom 0uomz1d 0uomn1d
4711 G UNIT 1 25
4711 CAR UNIT 240 1
4711 BX UNIT 24 1
4711 PAL UNIT 9600 1
4712 G KG 1 1000
4712 UNIT KG 1 5
4713 CAR UNIT 1 0
4713 BX UNIT 0 2
The table is read as follows:

1 UNIT @ 25 G
240 UNIT @ 1 CAR
24 UNIT @ 1 BX
9600 UNIT @ 1 PAL
For material 4711: InfoObject-specific conversions are possible between:
UNIT, G, CAR, BX, PAL
The conversion is always performed using the base unit of measure and therefore is performed in a maximum of two steps. If, for example, you convert from
PAL to BX, the system first converts from PAL to UNIT and thereupon from UNIT to BX.
G, UNIT, KG
CAR, UNIT, BX
Theoretically you could try to load the quantity DataStore object as follows (aim: convert CAR directly to BX and BX to CAR):
Quantity DataStore object: UOM07
#Crxmatkl #0unit 0base_uom 0uomz1d 0uomn1d
4711 G UNIT 1 25
4711 CAR UNIT 240 1
4711 BX UNIT 24 1
4711 PAL UNIT 9600 1
4711 CAR BX 10 1
The direct reference between CAR and BX is specified in the last row. This entry is incorrect on one hand because the primary key is violated if data record 2
already exists in the object. If record 2 does not already exist, the entry is still incorrect because the column 0base_uom does not contain the base unit of
measure from the master data (UNIT).
2) Master Data cruom1 (can be used to calculate the unit of measure from the unit of measure attribute)
#cruom1 Crf1 0sales_unit 0unit
M1 C1 KG G
M2 C2 CAR BX

M3 C3 PAL UNIT
3) Master Data cruom1KL (can be used to calculate the unit of measure from the measure attribute)
#cruom1 #0bp_contper Crf1 0sales_unit 0unit
M1 Akino C1 KG G
M2 Bertolini C2 CAR BX
M3 Smith C3 PAL UNIT
Examples
The examples listed below are based on the example data given above. These examples illustrate the results produced by the different options available with
unit conversion:
Examples of Conversion with Fixed Target Unit of Measure
Examples of Conversion Using Factor from InfoObject
Examples of Conversion with Target Unit of Measure Using Attribute in InfoObject
Examples of Conversion with Fixed Target Unit of Measure and Dynamic Determination Without Options
Conversion with Fixed Target Quantity
Example 1: One-Step Conversion with Fixed Target Quantity
Source
C2REQnr Cmat07 C2faCtor C2faCtorf C2kyf1 C2kyf2
1 4711 1,5 1,7 12 CAR ?
Conversion type: <xyz>

Conversion factors: Determined dynamically using reference InfoObject CMAT07
Source unit of measure: Unit of measure from data record
Target unit of measure: Fixed unit of measure: UNIT
Target
1 4711 1,5 1,7 12 CAR 2880 UNIT
Example 2: Two-Step Conversion with Fixed Target Quantity
Source
1 4711 1,5 1,7 12 CAR ?

Target unit of measure: Fixed unit of measure: BX
Target
1 4711 1,5 1,7 12 CAR 120 BX
Example 3: Two-Step Conversion with Fixed Target Quantity
Source

1 4711 1,5 1,7 12 CAR ?

Target unit of measure: Fixed unit of measure: PAL
Target
1 4711 1,5 1,7 12 CAR 0,3 PAL
Conversion Using Factors from InfoObjects

Example 1: Conversion Using Factors from InfoObject
Source
1 4711 0,025 1,7 12 CAR ?

Conversion factors: From InfoObject C2FACTOR
Target
1 4711 0,025 1,7 12 CAR 0,3 PAL
Source
1 4711 0,025 1,7 12 CAR ?

Conversion factors: From InfoObject C2FACTORF
Target
1 4711 0,025 1,7 12 CAR 20.4 PAL
Conversion with Target Unit of Measure Using Attribute in

InfoObject
Example 1: Conversion with Target Unit of Measure Using Attribute in InfoObject CRUOM1
Source
C2REQnr Cmat07 C2faCtor C2faCtorf C2kyf1 C2kyf2 CRUOM1
1 4711 0,025 1,7 12 CAR ? M3

Target unit of measure: InfoObject for determining unit of measure: CRUOM1; related quantity attribute: 0SALES_UNIT
Target
1 4711 0,025 1,7 12 CAR 0,3 PAL M3
Source
1 4711 0,025 1,7 12 CAR ? M1

Target unit of measure: InfoObject for determining unit of measure: CRUOM1, related quantity attribute: 0UNIT
Target
1 4711 0,025 1,7 12 CAR 72000 G M1
Source
1 4711 0,025 1,7 12 CAR ? M2

Target
1 4711 0,025 1,7 12 CAR 120 BX M2
Source
1 4711 0,025 1,7 12 CAR ? M3

Target
1 4711 0,025 1,7 12 CAR 2880 UNIT M3

Conversion with Fixed Target Unit of Measure and Dynamic
Determination Without Options
Example 1: Conversion Factors Determined Dynamically Using Reference InfoObject Only
Source
1 4711 0,025 1,7 18 PAL ?

Conversion factors: Determined dynamically using reference InfoObject CMAT07, factors are searched for in the reference InfoObject only
Target
1 4711 0,025 1,7 18 PAL 172800 UNIT
Example 2: Conversion Factors Determined Dynamically Using Central Units of Measure Only (T006)
Source
1 4711 0,025 1,7 18 PAL ?

Conversion factors: Determined dynamically using central units of measure (T006), factors are searched for in the central units of measure (T006) only
Target unit of measure: Fixed unit of measure: G
Target
1 4711 0,025 1,7 18 PAL No conversion possible
Conversion is not possible because PAL and G do not belong to the same dimension.
Example Data With Compounding

1a) Master Data: Compound Characteristic crxmatKl
#C2PLANT #C2COUNTRY #Crxmatkl 0base_uom 0apo_storgu

Base Unit of Measure Stock Level
P001 DE 4711 UNIT PAL
P001 DE 4712 ROL PAL
P002 GB 4712 KG PAL
P025 SE 4713 UNIT PAL
The unit 0base_uom is entered as the base unit of measure in the master data on the Business Explorer tab page.
The DataStore Object uomcrxkl is also created and activated from the master data ( tab page: Business Explorer Units of Measure for Char. ).
The structure of a DataStore Object always complies with the following rule:
<characteristic> <compounding for characteristic, where applicable>
<target unit of measure> <base unit of measure> <conversion factor: counter>
<conversion factor: denominator> <SID columns for all characteristics not listed in following tablet>
#Crxmatkl #C2PLANT #C2COUNTRY #0UNIT 0base_uom 0uomz1d 0uomn1d
4711 P001 DE G UNIT 1 25

4711 P001 DE CAR UNIT 240 1
4711 P001 DE BX UNIT 24 1
4711 P001 DE PAL UNIT 9600 1
4712 P002 GB G KG 1 1000
4712 P002 GB UNIT KG 1 5
4712 P001 DE TO ROL 2 1
4712 P001 DE UNIT ROL 1 450
4713 P025 SE CAR UNIT 1 0
4713 P025 SE BX UNIT 0 2
The table is read as follows:

1 UNIT 25 G
240 UNIT 1 CAR
24 UNIT 1 BX
9600 UNIT 1 PAL
Material 4711: InfoObject-specific conversions are possible between:
UNIT, G, CAR, BX, PAL
The conversion is always performed using the base unit of measure and therefore is performed in a maximum of two steps. If, for example, you convert from
PAL to BX, the system first converts from PAL to UNIT and thereupon from UNIT to BX.
Material 4712: Plant P002: InfoObject-specific conversions are possible between:
G, UNIT, KG
Material 4712: Plant P001: InfoObject-specific conversions are possible between:
TO, ROL, UNIT
Material 4713: InfoObject-specific conversions are possible between:
CAR, UNIT, BX
Theoretically you could try to load the quantity DataStore object as follows (aim: convert CAR directly to BX and BX to CAR):
Quantity DataStore object: UOMCRXKL
#Crxmatkl #C2PLANT #C2COUNTRY #0UNIT 0base_uom 0uomz1d 0uomn1d
4711 P001 DE G UNIT 1 25
4711 P001 DE CAR UNIT 240 1
4711 P001 DE BX UNIT 24 1
4711 P001 DE PAL UNIT 9600 1
4711 P001 DE CAR BX 10 1
The direct reference between CAR and BX is specified in the last row. This entry is incorrect on one hand because the primary key is violated if data record 2
already exists in the object. If record 2 does not already exist, the entry is still incorrect because 0base_uomdoes not contain the base unit of measure from
the master data (UNIT).
2) Master Data cruom1 (can be used to calculate the unit of measure from the unit of measure attribute)
#CrUOM1 #CRF1 0SALES_UNIT 0UNIT
M1 C1 KG G
M2 C2 CAR BX
M3 C3 PAL UNIT
3) Master Data cruom1KL (can be used to calculate the unit of measure from the measure attribute)
#CrUOM1 #0bp_contper #CRF1 0SALES_UNIT 0UNIT
M1 Akino C1 KG G
M2 Bertolini C2 CAR BX
M3 Smith C3 PAL UNIT
Examples
The examples listed below are based on the example data given above. These examples illustrate the results produced by the different options available with
unit conversion:
Examples of Conversion with Fixed Target Unit of Measure
Examples of Conversion Using Factor from InfoObject
Examples of Conversion with Target Unit of Measure Using Attribute in InfoObject

Examples of Conversion with Fixed Target Unit of Measure and Dynamic Determination Without Options
Conversion with Fixed Target Unit of Measure

Source
C2REQnr Crxmatkl C2PLANT C2COUNTRY C2faCtor C2faCtorf C2kyf1 C2kyf2
1 4711 P001 DE 1,5 1,7 12 CAR ?

Conversion factors: Determined dynamically using reference InfoObject: CRXMATKL
Target
1 4711 P001 DE 1,5 1,7 12 CAR 2880 UNIT
Source
1 4711 P001 DE 1,5 1,7 12 CAR ?

Target unit of measure: Fixed unit of measure: BX
Target
1 4711 P001 DE 1,5 1,7 12 CAR 120 BX
Source
1 4711 P001 DE 1,5 1,7 12 CAR ?

Target
1 4711 P001 DE 1,5 1,7 12 CAR 0,3 PAL
Conversion Using Factors from InfoObjects

Source
1 4711 P001 DE 0,025 1,7 12 CAR ?

Conversion factors: From InfoObject C2FACTOR
Target
1 4711 P001 DE 0,025 1,7 12 CAR 0,3 PAL
Source
1 4711 P001 DE 0,025 1,7 12 CAR ?

Conversion factors: From InfoObject C2FACTORF
Target
1 4711 P001 DE 0,025 1,7 12 CAR 20.4 PAL
Conversion with Target Unit of Measure Using Attribute in

InfoObject
Example 1: Conversion Using Attribute in InfoObject CRUOM1
Source
C2REQnr Crxmatkl C2PLANT C2COUNTRY C2faCtor C2faCtorf C2kyf1 C2kyf2 CRUOM1
1 4711 P001 DE 0,025 1,7 12 CAR ? M3

Conversion factors: Determined dynamically using reference InfoObject CRXMATKL
Target unit of measure: InfoObject for determining unit of measure: CRUOM1; related quantity attribute: 0SALES_UNIT
Target
1 4711 P001 DE 0,025 1,7 12 CAR 0,3 PAL M3
Source
1 4711 P001 DE 0,025 1,7 12 CAR ? M1

Target unit of measure: InfoObject for determining unit of measure: CRUOM1; related quantity attribute: 0UNIT
Target
1 4711 P001 DE 0,025 1,7 12 CAR 72000 G M1
Source
1 4711 P001 DE 0,025 1,7 12 CAR ? M2

Target
1 4711 P001 DE 0,025 1,7 12 CAR 120 BX M2
Source
1 4711 P001 DE 0,025 1,7 12 CAR ? M3

Target
1 4711 P001 DE 0,025 1,7 12 CAR 2880 UNIT M3
Conversion with Fixed Target Unit of Measure and Dynamic

Determination Without Options
Source
1 4711 P001 DE 0,025 1,7 18 PAL ?

Conversion factors: Determined dynamically using reference InfoObject CRXMATKL, factors are searched for in the reference InfoObject only
Target

1 4711 P001 DE 0,025 1,7 12 CAR 4320000 G
Source
1 4711 P001 DE 0,025 1,7 18 PAL ?

Conversion factors: Determined dynamically using reference InfoObject CRXMATKL, factors are searched for in the reference InfoObject only
Target
1 4711 P001 DE 0,025 1,7 12 CAR 172800 UNIT
Example 3: Conversion Factors Determined Dynamically Using Central Units of Measure Only (T006)
Source
1 4711 P001 DE 0,025 1,7 18 PAL ?

Conversion factors: Determined dynamically using central units of measure, factors are searched for in the central units of measure (T006) only
Target
1 4711 P001 DE 0,025 1,7 12 CAR No conversion

possible
Conversion is not possible because PAL and G do not belong to the same dimension.
1.3.1.6 Local Calculations
Use
You can recalculate single values and results of a report based on certain criteria. For example, you can create ranked lists or you can calculate the total for a
Top 10 product list locally.
Integration
The function for making local calculations is available for structural components in the Query Designer in the Selection/Formula Properties dialog, in the BEx
Analyzer in the Key Figure Properties dialog, and in the Context Menu of Web applications.
Features
Local calculations include only those numbers in the calculation that appear in the current view of the report. In this way, you override the standard analytic
engine calculations.
Note that these local calculations only change the display of the values. With subsequent calculations, such as formulas, the system does not use the values
changed for the display, but rather the original values specified by the analytic engine.
For more information, see:

Calculate Results As
Calculate Single Values As
1.3.1.7 Constant Selection
Use
In the Query Designer, you use selections to determine the data you want to display at the report runtime. You can alter the selections at runtime using
navigation and filters. This allows you to further restrict the selections.
The Constant Selection function allows you to mark a selection in the Query Designer as constant. This means that navigation and filtering have no effect on
the selection at runtime. This allows you to easily select reference sizes that do not change at runtime.
Integration
You can use this function with selections in structural components, cells, and restricted key figures.
Features
You can define entire selections as constant for structural components and cells. During navigation, a constant selection is independent of all filters.
In addition, you can define components of selections, that is, individual characteristics and their filter values, as constant. During navigation, only the selection
relating to this characteristic remains unaffected by filters.
You cannot select an entire restricted key figure as a constant, only its characteristics.
Activities
You can activate the Constant Selection setting for an entire selection in the Selection/Formula Properties dialog box.
You can select a characteristic of a selection as constant in the following way:
1. In the context menu of a selection, choose Edit . The Change Selection dialog box appears.
2. In the Selection Details area, in the context menu of the characteristic that you are using in the selection, choose Constant Selection .
Proceed in the same way to select the characteristics that you are using in a restricted key figure or in a selection of a cell as constant.
Examples
Market Index
In a product list ( Product is in the drilldown), you want to display the sales revenue normalized for (based on) a specific product group rather than the total
sales revenue. Using the Constant Selection function, you can select the sales revenue of a specific product group as constant for the drilldown. You can
now relate the sales revenue of the individual products in the product group to the sales revenue of the product group. This allows you to determine the
revenue from each individual product as a proportion of the sales revenue for the product group.
For more information, see Example: Market Index.
Plan/Actual
In the InfoCube, actual values exist for each period. Plan values only exist for the entire year. These are posted in period 12. To compare the PLAN and
ACTUAL values, you have to define a PLAN and an ACTUAL column in the query, restrict PLAN to period 12, and mark this selection as a constant selection.
This means that you always see the plan values, whichever period you are navigating in.
MultiProvider Problems
Furthermore, you can use the constant selection to solve MultiProvider problems.
The MultiProvider has two InfoCubes with data about the price and quantity of various products and the corresponding plants. InfoCube 2 also contains
characteristic Customer. In a drilldown according to Customer, all data from InfoCube 1 is displayed under initial value # (not assigned).
You can now define a constant selection on Customer and exclude initial value # (not assigned) in the filter. This filters out the rows with initial value #
(not assigned), but the data about key figure Price is retained.
For more information, see Example: Using Constant Selection with MultiProviders.
The MultiProvider has an InfoCube with the actual values and an InfoCube with the plan values. If the Calendar Month characteristic is in the plan
InfoCube but not in the actual InfoCube, in a drilldown according to Calendar Month , all data is displayed under value # (not assigned).
You can now define a constant selection for Calendar Month = # (not assigned). In doing so, you select the yearly plan value as constant independently
of the filter and it is displayed in each row, therefore for every month. You can now divide the yearly plan value by 12. Then you can make plan/actual
comparisons on a monthly basis, although there are only yearly values in the plan InfoCube.

1.3.1.7.1 Example: Market Index
In a product list ( Product is in the drilldown), you want to display the sales revenue normalized for (based on) a specific product group rather than the total
sales revenue. Using the Constant Selection function, you can select the sales revenue of a specific product group as the constant for the drilldown. You can
now relate the sales revenue of the individual products in the product group to the sales revenue of the product group. This allows you to determine the
revenue from each individual product as a proportion of the sales revenue for the product group.
The following example tables show how the table changes when the characteristic value Envelopes from the characteristic Product is removed from the
filter. The second table shows how a change to the navigation or filter of the characteristic Product has no effect on the column containing the constant
selection.
The key figures are defined as follows:
Absolute Sales is the key figure Sales.
Constant Sales (Selection) is a selection with the key figure Sales and characteristic Product . Constant selection is activated for characteristic
Product .
Normalized Sales (Formula) is a formula with 'Absolute Sales %A Constant Sales (Selection) . %A is the percentage deviation. For more information,
see Percentage Functions.
Constant Sales (Formula with SUMCT) is a formula with the data function Result (SUMCT) on the key figure Sales . For more information, see Data
Functions.
Normalized Sales (Formula with SUMCT) is a formula with 'Absolute Sales %A Constant Sales (Formula with SUMCT) . %A is the percentage
deviation.
To help understand the concept of constant selection, we recommend that you first compare the Absolute Sales and Constant Sales
(Selection) columns in the two tables. You can then compare the differences between the Constant Sales (Selection) and Constant Sales
(Formula with SUMCT) columns. The two Normalized Sales columns represent typical situations.
Example Table for Market Index
Product Group Product Absolute Sales Constant Sales Normalized Sales Constant Sales Normalized Sales
(Selection) (Formula) (Formula with (Formula with
SUMCT) SUMCT)
Office supplies Paper 30 120 25% 120 25%
Envelopes 30 120 25% 120 25%
Ballpoint pens 60 120 50% 120 50%
Result for office 120 120 100% 240 50%

supplies
Furniture Chair 60 120 50% 120 50%
Table 60 120 50% 120 50%
Results for furniture 120 120 100% 240 50%
Overall Result 240 240 100% 240 100%
Example Table for Market Index with Different Filter Values
Product Group Product Absolute Sales Constant Sales Normalized Sales Constant Sales Normalized Sales
(Selection) (Formula) (Formula with (Formula with
SUMCT) SUMCT)
Office supplies Paper 30 120 25% 90 33.3%
Ballpoint pens 60 120 50% 90 66.6%
Result for office 90 120 75% 210 42.85%

supplies
Furniture Chair 60 120 50% 120 50%
Table 60 120 50% 120 50%
Results for furniture 120 120 100% 210 57.15%
Overall Result 210 240 87.5% 210 100%
By removing Envelopes from the drilldown, the result for Office Supplies and the overall result for Absolute Sales is reduced by 30. This is a reduction of
25% with respect to the product group Office Supplies and 12.5% with respect to the overall result.
Example: Using Constant Selection with MultiProviders
Use
You can use the constant selection to solve MultiProvider problems.
For example, you have a MultiProvider that contains data from the following InfoCubes:

InfoCube 1
Plant Product Price
101 Candy Tin 0,12
101 Coffee Mug 0,14
102 Candy Tin 0,11
103 Mouse Pad 0,23
104 Post-It Set 0,15
InfoCube 2
Plant Product Customer Quantity
101 Candy Tin Dawson Agency Inc 100
101 Coffee Mug Acadia Transfer Inc 110
102 Candy Tin Evans Hotel Inc 105
103 Mouse Pad Thompson Inc 115
104 Post-It Set Bear Express Co Inc 110
Since characteristic Customer is contained in InfoCube 2 but not in InfoCube 1, in a drilldown according to Customer, all data from InfoCube 1 is displayed
under initial value # (not assigned). The query would look as follows on the MultiProvider:
Query Based on This MultiProvider
Plant Product Customer Price Quantity
101 Candy Tin # (not assigned) 0,12 0
101 Candy Tin Dawson Agency Inc 0 100
101 Coffee Mug # (not assigned) 0,14 0
101 Coffee Mug Acadia Transfer Inc 0 110
102 Candy Tin # (not assigned) 0,11 0
102 Candy Tin Evans Hotel Inc 0 105
103 Mouse Pad # (not assigned) 0,23 0
103 Mouse Pad Thompson Inc 0 115
104 Post-It Set # (not assigned) 0,15 0
104 Post-It Set Bear Express Co Inc 0 110
You can now define a constant selection on Customer and exclude initial value # (not assigned) in the filter. This filters out the rows with initial value # (not
assigned). The data about key figure Price is retained, however.
Procedure
1. In the Query Designer, define a selection that contains key figure Price and characteristic Customer.
2. Restrict characteristic Customer to initial value # (not assigned).
3. Set the constant selection on characteristic Customer.
4. In the default values of the filter on characteristic Customer, exclude initial value #.
Instead of using the constant selection, you can also solve this MultiProvider problem using InfoSets.
InfoSets are defined in the data model, however, and are very dynamic. Using the constant selection that you set in the Query Designer, you
can set the join of the data records very flexibly to any InfoObject that is part of a selection for each query based on a MultiProvider.
Result
In the drilldown, the rows with initial value # (not assigned) on characteristic Customer are grayed out, but the data about key figure Price is retained. The
query looks like this:
Query Based on the MultiProvider with Constant Selection on Customer
Plant Product Customer Price Quantity
101 Candy Tin Dawson Agency Inc 0,12 100
101 Coffee Mug Acadia Transfer Inc 0,14 110
102 Candy Tin Evans Hotel Inc 0,11 105
103 Mouse Pad Thompson Inc 0,23 115
104 Post-It Set Bear Express Co Inc 0,15 110

1.3.1.8 Analysis Authorizations
Use
Analysis authorizations are required of all users that want to display data from authorization-relevant characteristics or navigation attributes in a query. This
type of authorization is not based on the standard authorization concept of SAP. Instead, they use their own concept that takes the features of reporting and
analysis in BI into consideration. More and more users are gaining access to query data with the distribution of queries using the BEx Broadcaster and
publication of queries to the portal. With the special authorization concept of BI for the display of query data, you can protect especially critical data in a much
better way.
Only when the user has been assigned the appropriate authorizations can he/she define and execute a query or navigate in a existing query. Analysis
authorizations are checked in the dialog for opening a query. When a query is opened, the authorizations for the individual objects are also checked.
See also the detailed documentation in Analysis Authorizations.
1.3.1.9 Report-Report Interface
Use
The report-report interface allows you the flexibility to call a jump target (receiver) online from a BEx query (sender) within or outside of the BI system. Jump
targets that have been assigned to a BEx query can be selected in BEx Web applications and in the BEx Analyzer. You access them from the context menu
under the Goto function.
Prerequisites
To use the RRI in a BEx Query or Web application, you first have to make the necessary settings with sender/receiver assignment.
See Editing Sender/Receiver Assignments to the RRI in the BI System.
If you want to jump from a Web application to a transaction or ABAP/4 report using the RRI, first you need to install an Internet Transaction Server (ITS) for
the target system. The transaction or ABAP report is than displayed in the SAP GUI for HTML, which is part of the ITS. The ITS is also used for jump targets
within the BI server. However, this does not have to be installed separately because it is automatically included in a BI system. The URL for starting a
transaction in the SAP GUI for HTML is generated by the BI server.
Features
Queries, transactions, reports, and Web addresses can be jump targets. The parameterization of the target action is taken from the context of the cell from
which you have jumped. You can set parameters for calling a BEx query or a BEx Web application using input variables that are filled from the selection
conditions and the element definitions of the selected cells in the sender query.
More information about the exact process: Process when Calling the RRI
Example
For your cost center report ( Sender ), you want to request master data from an SAP system ( Receiver ).

For a BEx Query with the up-to-date sales figures for your customer ( Sender ), you want to request up-to-date stock market data on your customer listed on
the stock exchange from the Internet.
1.3.1.9.1 Process when Calling the RRI

When it is called, the report-report interface (RRI) first collects the following information from the cell of the sender query before passing it to the receiver as
selections:
Global filter: the lines and columns of the query definition;
More information about the global filter: Defining New Queries
Dynamic filter: the values in the navigation block of the query (filter that can be changed by navigation), including the hierarchies;
More information about the navigation pane: Navigation Pane
Filters from the selected, restricted key figure;
More information about the restricted key figure: Defining Restricted Key Figures
In formulas, only the selections that are identical in all operands are passed
Filters from the selected drilldown characteristics;
More information about the drilldown characteristics: Navigating in Analysis Mode
This process uses the following additional functions to map the contents in an appropriate manner.
If the receiver query has variables, the system tries to fill these variables; if there are no suitable variables, the values are passed as dynamic filters.
If there is a specific relationship between the sending and receiving InfoObjects, the system tries to use this relationship:
If there is compounding, a restriction to a compounded characteristic is also applied to the parent of the compounding if it is the receiving query in the
navigation block.
Other possible relationships that can be mapped:
Attribute restrictions are mapped to the master characteristic.
Restrictions to navigation attributes are also mapped to characteristics that bear master data, and restrictions to characteristics are also applied to
navigation attributes if these are present in the receiver.
The sender contains the characteristic City in the drilldown, and the receiver contains the corresponding navigation attribute Zip Code . The
restriction of City on the zip code is applied and passed to the navigation attribute Zip Code in the receiver.
Referencing characteristics are mapped to the basic characteristic.
When jumping to another system, note that the mapping rules are created in the target system. Make sure that all the InfoObjects with implicit mapping
rules from the sending query also exist in the target system. Otherwise the jump will not work.
There are some special features when handling the different receivers.
More information: Receivers
Editing Sender-Receiver Assignments to the RRI in the BI System
Use
You use the sender-receiver assignment to make the necessary settings for connecting a query to the report-report interface (RRI) in BEx. You can assign
receiver reports to a sender report, that is, a BEx query, both within the BI system and to another SAP system.
Creating Sender/Receiver Assignments

1. In the SAP Easy Access Menu of the BI system, choose SAP Menu Business Explorer Query Targets. The Maintain Sender-Receiver
Assignment screen appears.
2. Select one of the two tab pages and enter the required data.
Tab Page Description
Query Enter the technical name of the sender query or select a query using input help.
InfoCube If you want to assign the same jump target to all queries for an InfoProvider, enter
the technical name of the required InfoProvider or select it using input help.
3. Choose Create. The Maintain Sender/Receiver Assignment dialog box appears.

4. Under Report Type , choose a receiver. You have the following options:
Report Type Description
BEx Query Jump to a query that was created using the BEx Query Designer
More information: BEx Query As a Receiver
BEx Web Application (SAP NetWeaver BI 7.0) Jump to a BEx Web application that is an executed Web template that was created
using the BEx Web Application Designer. This requires the Java-based runtime of
SAP NetWeaver BI.
BEx Web Application (SAP BW 3.x) Jump to an ABAP-based BEx Web application (SAP BW 3.x) that was created using
the BEx Web Application Designer (version SAP BW 3.x).
Crystal Report Jump to a formatted report in Crystal Enterprise. You can also use a BEx report for

formatted reporting.
InfoSet query Jump to an InfoSet query (queries on classic InfoSets) InfoSet queries are usually
queries on master data.
Transaction Jump to a transaction in an SAP system. The transaction must be classified for
using SAP GUI for HTML.
More information: Creating a Transaction As a Receiver
ABAP Report Jump to an ABAP/4 report in an SAP system.
Web Address Jump to any Web address and pass the parameters in the URL.
More information: Creating a Web Address As a Receiver
Own Report Type Jump to any target in the Web or SAP GUI for HTML. The call and the parameters
can be modified using customer-specific coding.
More information: Creating Your Own Report Type As a Receiver
For more information about the features of the various types, see Receivers.
5. Choose a Target System. You have the following options:
a. Local: The jump target is within the BI system.
b. Source System: The jump target is outside of the BI system.
One source system as a target system:
Specify the name of the source system. You can also choose the source system using input help.
All source systems as target systems:
Choose All Source Systems . Specify the source system in which you want to choose the required report initially.
Log on to this source system.
6. In the Report field, enter a description for the receiver report. Once you have saved your entry, this description is displayed as the Report Title.
7. Choose Transfer. The Maintain Sender-Receiver Assignment screen appears.
9. For special cases, you can still maintain the assignment details. More information: Maintaining Assignment Detailss.
Changing Sender-Receiver Assignments

Once you have created a receiver, you can make the following changes in the table to the fields that are ready for input.
Group Description Information
Report title Specify a name.
Source system Choose the required source system using input help. You can assign all source
systems by entering *.
InfoSource If an InfoProvider is filled from several InfoSources, you can specify from which
InfoSource you want to extract data. In the InfoSource column, choose the
InfoSource you want to use using input help.
If you also want to change the Report Type, Target System or Report settings, choose Change . The Maintain Sender-Receiver Assignment screen
appears. Make the required changes and choose Transfer .
Deleting Sender-Receiver Assignments

1. If you want to delete an assignment, select the corresponding row entry in the Receiver table.
2. Choose Delete . The system deletes the selected assignment.
Transporting Sender-Receiver Assignments

You get to the transport connection using the Transport Wizard . You can use it to transport sender-receiver assignments that you created. All jump
targets are then transported together. Queries as sender are collected by the object collector as necessary objects, and receivers as optional objects.
Result
Jump targets that have been assigned to a BEx query can be selected in Web applications and in the BEx Analyzer. You access them from the context menu
under the Goto function.
More Information:
BEx Analyzer: Goto
Web Applications: Goto
1.3.1.9.3 Receivers

Features
In the following, we will explain how to deal with the peculiarities of the various receivers.
BEx Query
When you call the RRI, the selections are passed as described: Process when Calling the RRI
More information: BEx Query As a Receiver.
Web Application
For Web applications, the same applies as for BEx Queries. If a Web application contains multiple queries, the RRI is called for each query separately.
Crystal Report
When calling the RRI with a Crystal Report as the receiver, only the variables are filled. There is no transfer of filters as with BEx Queries.
Transaction and ABAP/4 Report

Calling the RRI with a transaction or an ABAP/4 Report as the receiver is done with the RRI from the SAP NetWeaver Application Server. This is possible in
an ERP system, a CRM system or within the BI system. The selections are prepared by the BI system that does not recognize the transaction or the report.
The assignment is transferred from the RRI of the SAP NetWeaver Application Server using inverse transformation rules. There must also be a complete chain
from the DataSource of the source system to the InfoSource, through transformations up to the InfoProvider. This does not mean that data absolutely has to
be loaded using this chain. If this chain does not exist, the RRI cannot transfer the selections to the source system.
You can only call the RRI for fields with dictionary reference. This means that the parameter has to be
PARAMETERS param LIKE <table_field>
for ABAP reports. For transactions, this means that the screen has to have a dictionary reference. Not every transaction can be called with the RRI of the
SAP Application Server. For some transactions (such as SV03), you need to program a utility program if you still want to call it using the RRI.
See also Creating a Transaction As a Receiver.
InfoSet query
The same applies to InfoSet queries as does for transactions and ABAP/4 reports.
Web Address
When calling the RRI with a Web address as receiver, the assignment details have to be maintained. You have to specify the name of the input field in the
field name column. URL variables cannot be used.
See also Creating a Web Address As a Receiver.
1.3.1.9.3.1 BEx Query as Recipient
Use
You can assign a BEx Query in BI as recipient to another BEx Query as sender.
Features
In order to be able to call a query as a recipient with the RRI you need to be aware of a few guidelines during query definition.
General
Characteristics that are to be filled from the sender query must be defined as free characteristics. A hierarchy node restriction can also be transferred to
free characteristics as a property, for example.
Changeable variables for the recipient query are not filled by the RRI.
Selections for various InfoObjects are transferred when the InfoObjects have the same reference characteristic.
See also the section BEx Query under Receivers.
Using Hierarchies
When using hierarchies in the query, you should be aware of the following cases:
Sender and receiver queries use the same hierarchy or hierarchies that are based on the same basic characteristic.
Jumping from one node in the hierarchy of the sender query to the same node of the hierarchy in the receiver query works as usual. The hierarchy settings are
transferred with the RRI.
Sender and receiver queries use different hierarchies:
The hierarchy setting for the receiver query remains unchanged and the selections for the RRI are deleted. The system filters by leaves in the node.
A few InfoObjects are different from one another, but they are treated as assignable by the system. This is a special development for Business
Content. For example, values are transferred from account number (0ACCOUNT) to cost element (0COSTELMNT) or to general ledger account
(0GL_ACCOUNT). For more information, see the Example for a BEx Query As a Receiver.

The receiver query uses a hierarchy, but the sender query does not:
If the selections of the RRI only consist of single values, the hierarchy setting for the receiver query remains unchanged; otherwise the hierarchy is
deactivated.
The sender query uses a hierarchy, but the receiver query does not:
The hierarchy is set to inactive.
Hierarchies and Compounded Characteristics

With hierarchies for compounded characteristics, you have to create a variable for the basic characteristic of the hierarchy for the receiver query so that the
values can be transferred correctly.
If you were to define the query without these variables, the dynamic filter would be used and the hierarchy would be deactivated due to the compounding of the
InfoObject. When you use this non-changeable variable, the RRI can transfer the value to this variable and the hierarchy remains active.
Example
As a special case with different hierarchies and compounded characteristic, see the example Example for BEx Query as Receiver.
Example of a BEx Query as a Receiver

The following example contains two peculiarities: The queries linked using the RRI use different hierarchies, and the basic characteristic of the hierarchy in the
receiver query is a compounded characteristic.
From a query on a cost element, you want to display the corresponding account. The queries are based on two different InfoCubes.
The sender query uses a hierarchy that is based on the basic characteristic cost element (0COSTELMNT). The receiver query uses a hierarchy that is based
on the characteristic account number (0ACCOUNT).
Hierarchies that are based on different characteristics cannot normally be transferred. However this a special case: The characteristics cost
element (0COSTELMNT) and account number (0ACCOUNT) have the same key and are recognized by the system as similar characteristics
whose values can be transferred to one another. The same link exists between account number (0ACCOUNT) and general ledger account
(0GL_ACCOUNT). If this was not the case, the hierarchy in this example could not be transferred with the RRI.
Defining your receiver query:

As the hierarchy basic characteristic is a compounded characteristic (account number is compounded to chart of accounts), you have to create a variable for
characteristic account number so that the values can be transferred correctly.
If you define the query without this variable, the dynamic filter will be used and the hierarchy will be deactivated because the InfoObject is
compounded.
By using this variable, which cannot be changed, the RRI can transfer the value to this variable and the display hierarchy remains active.
Create a variable with the following properties for characteristic account number:
Variable type Characteristic value variable
Processing type Manual entry / Default value
Variable represents Selection option
Variable value is Optional
Ready for input Switched on
Changeable with query navigation Switched off
Creating sender/receiver Assignments

Create a sender/receiver assignment for both of your queries. You do not need to maintain the assignment details.
Executing the jump

When the hierarchies for both queries are structured in the same way, the jump from the sender query to the receiver query appears as follows:

When the hierarchies for both queries are structured in the same way, the jump from the sender query to the receiver query appears as follows:
Creating a Transaction As a Receiver
Use
You can assign a transaction as a receiver to a sender query in the BI system.
Prerequisites
If you want to jump from a Web application to a transaction or ABAP/4 report using the RRI, an ITS for the target system has to be assigned beforehand.
The value of the input field to be supplied must be known when the jump is made (for example, by entering a single value on the selection screen of the
sender or by the cursor position at the time of the jump).
Sender and receiver fields that correspond to one another generally must link to the same data element or at least to the same domain, otherwise the
values cannot be assigned to one another.
The assignment of sender and receiver fields must always be a 1:1 assignment. For example, the transactions called from the start screen cannot have
two input fields of the same data type. Then it is not clear which of the fields is to be supplied, which means neither of them is supplied.
There has to be a complete chain from the DataSource of the source system to the InfoSource, through update rules up to the target. See also the section
Transaction and ABAP/4 Report in Receivers.
Procedure
Simple Cases:
1. Specify a query or an InfoProvider as sender and choose Create .
2. Choose Transaction as the report type for the receiver.
3. Choose a target system, either local for a transaction within the BI system or Source System for a transaction in another SAP system.
4. Specify the required transaction as the receiver report.
5. Choose Apply. You return to the Maintain Sender-Receiver Assignments screen.
Complex Cases:
For some transactions, it is necessary to make a detailed assignment. One reason for this can be that the transaction uses a hidden initial screen and does
not fill the parameter using the memory ID of the data element.
Proceed as follows after you have created the sender-receiver assignment as described above.
1. Select your sender-receiver assignment and choose Assignment Details. See also Maintain Assignment Details.
2. As the type, choose Table Field . The columns Field Name, Data Element, Domain and SET/GET Parameter become input ready.

3. Specify the field name, data element, domain and parameter ID for the receiver transaction. You need to know this information because no input help is
available. You can usually find the parameter ID in the ABAP dictionary entry for the data element.
If the RRI Jump Still Does Not Work:

Many transactions and programs are not prepared for a call with parameters from the RRI, for example, because programs with additional screens are called in
transactions and the sender and target fields are not compatible.
In this case a custom program that has all the necessary parameters and tables as selections fields and that then calls the actual transaction with the ABAP
command CALL TRANSACTION or calls the desired program with SUBMIT can help.
Also refer to the documentation about the ABAP commands and SAP Notes 363203 and 694244 (as an example for a jump to transaction KSB5) and SAP
Note 383077 (RRI: Transaction call fails).
Individual fields must be declared as PARAMETERS, and tables must be declared as TABLES. You can only jump to tab pages from within such custom
developments.
If you jump from a node of a BEx query, the hierarchy is expanded before being passed to the target program or the target transaction in the leaves of the
parent node. In this scenario, a list of values is always passed. It is not possible to pass the node name itself to a transaction or program.
Creating a Web Address As a Receiver
Use
You can assign a Web address as a receiver to a sender query in the BI system.
Prerequisites
It may be necessary to insert an InfoObject that contains the value to be transferred into your sender query. See also the Examples for Jumping to Web
Pages.
Procedure
1. You are on the Maintain Sender-Receiver Assignments screen. Specify a query or an InfoProvider as sender and choose Create .
2. Choose Web Address as the report type for the receiver.
3. Enter the required Web address for the receiver report using input hlep. This Web address has to link directly to the input field. Examples for Jumping to
Web Pages explains how to determine this.
If this Web page changes, you need to change your sender-receiver assignment accordingly.
4. Choose Install. You return to the Maintain Sender-Receiver Assignments screen.
5. Select your sender-receiver assignment and choose Assignment Details.
Now the system sets URL Parameter as the processing method (type) and it sets selection type to Parameter .
6. Enter the name of the input field in the Field Name column. Examples for Jumping to Web Pages explains how to determine this.
7. Choose Close. You return to the Maintain Sender-Receiver Assignments screen.
8. You can change the title of the report. This title is then displayed in the query as the jump target via the context menu. Save your entries.
Result
You can call the Web address from your query or Web application with the associated search term using Jump . The search parameter is then filled with the
key for the associated InfoObject and the search results are displayed on the Web page.
Example
See Examples for Jumping to Web Pages.
Examples for Web Addresses as Receiver
Jump to CNN Money

You want to display the share price of the customer in a query. To do so, jump to the customer on the CNN Money Web page using the context menu.

Query Definition:
Add the characteristic Stock Search Term to your query. It is a navigation attribute for Customer . This characteristic must appear in the drilldown in the
query. It is passed as a parameter when the RRI is called. From the properties of the characteristic, define that the characteristic should not be displayed.
The characteristic Stock Search Term must be defined so that the key of the characteristic passes the precise search term.
Only the key, and no text, can be passed.

In this case, the three-place acronym of the company is passed:
The length of the characteristic must be defined with a length of three places; otherwise the other preceding places will be filled with zeroes.
Determining the Web Address and the Field Name:

To jump to the search term on the Web page, you need the Web address of the page to which the input field for the stock search term refers as well as the
name of the input field.
You have two options:
1. You look at the HTML code of the Web page:
This is the corresponding part of the source code of the Web page CNN Money; the relevant parameters are highlighted in red. The tag form is followed
by the URL that sends the data; the tag input is followed by the attribute name , which gives the name of the expected parameter:
<form action="http://quote.money.cnn.com/quote/quote" method="get">
<td width="60" valign="bottom">
<img src="http://i.cnn.net/money/images/searchbar/enter_symbol.gif" alt="" width="49" height="16" hspace="3" vspace="0" border="0"></td>
<td width="55" valign="bottom">
<input type="text" name="symbols" value="" size="5" maxlength="38" style="font-size: 11px"></td>
...
2. Execute the action on the Web page with a stock search term. On the Web page, enter for example SAP in the search field and confirm it. Copy the URL
of the new window.
http://quote.money.cnn.com/quote/quote?symbols=SAP
The query string appears after the question mark. All the parameters name=value are listed here; individual parameters are separated with &.
Sender/Receiver Assignments:
Proceed as in Creating a Web Address as a Receiver. Specify the Web address you determined beforehand http://quote.money.cnn.com/quote/quote.
In the assignment details for the InfoObject Stock Search Term, enter the field name SYMBOLS that you determined beforehand. You can set the indicator
Required Entry so that the Web page is only called if this stock search term is found on the Web page .
Give the report the title CNN Money.
Jump to Google
You want to search for information about a customer in a query in the Internet. To do so, jump to the customer on the Web page of the search engine Google
using the context menu.
Query Definition:
Define your query as described above with a characteristic that has the search term as key.
Sender/Receiver Assignments:
Proceed as in Creating a Web Address as a Receiver. Determine the Web address that refers to the input field for the search as described above. In this case
it is: http://www.google.de/search?. Give the report the title Google.
In the assignment details, enter q as field name. This is the name of the input field that you determined beforehand as described above. When the RRI is
called, the key of the corresponding InfoObject is passed to the Web page.

1.3.1.9.3.4 iView As Receiver
You can use the RRI within the portal. In sender/receiver assignment, you select Web Address as the receiver. The iView accessed can contain a BEx Web
Application as well as a transaction.
However, when creating sender/receiver assignment, there are a few things you need to be aware of so that when jumping you remain within the portal.
For more information, see Jumping Using the Report-Report Interface in the Portal.
Creating Your Own Report Type as Receiver
Use
The report-report interface provides a number of report types as jump target (receiver). In certain situations it could be necessary to perform specific operations
that are not performed by the generic standard interface between the sender and receiver. If the standard interface does not satisfy your requirements, you can
implement a specific enhancement. These enhancements can call the receiver with individual parameters. There can be more or fewer parameters than in the
standard interface. Sender-receiver assignments can be ignored or enhanced with additional navigation commands.
Procedure
To implement a specific enhancement:
1. Create an ABAP class with the interface IF_RS_BBS_BADI_HANDLER.
More information: Creating ABAP Classes with Interface IF_RS_BBS_BADI_HANDLER
2. Create an implementation to the classic BAdI RS_BBS_BADI.
More information: Creating an Implementation to the BAdI RS_BBS_BADI
3. Create the sender-receiver assignment.
More information: Creating Sender-Receiver Assignments
Result
You can use the new jump target in the executed query.
Example
The procedures are based on the following example:
A query has the characteristic Product in its rows and the two key figures Revenue und Quantity in its columns. A further characteristic Customer is one
of the free characteristics. Upon jumping, the new report type should cause the free characteristic Customer to be drilled down in the rows. At the same time,
a key figure is filtered.
This is shown in the first part of the example.
For more information about URL parameters used, see Using Parameters to Call Web Applications.
The UID of the key figure is visible in the BEx Query Designer in the properties of the key figure on the tab page Enhanced .
The second part of the example shows how a key value can be passed to the Google search. You can also pass a key value to Google without this
implementation, but with the enhancement it is possible to also pass the text. The text, however, must first be determined from the master data.
For more information about the solution without an implementation, refer to Examples for Web Addresses as Receiver.
1.3.1.9.4 Maintaining Assignment Details
Use
The maintenance of assignment details is an expert function. Before BW 3.0A, a BAdI or user exit was available for this type of assignment. This is now
obsolete and only exists for reasons of compatibility.
In general, you should be able to use the RRI to create the sender-receiver assignment, without having to specify any other assignment
details.
In certain cases, however, it may be necessary to maintain these assignment details, such as
If you do not want to transfer certain selections, for example differing date information

If an assignment is not clear, for example, if the vendor needs to be assigned to the purchaser.
The system does not check the assignment details you maintained to make sure they make sense.
Prerequisites
You have created a sender-receiver assignment.
Procedure
1. Select your sender-receiver assignment in the Receiver table.
2. Choose Assignment Details. The Field Assignments dialog box appears.
3. If you want to make changes to the individual fields, choose the required settings using input help. You can assign the processing method ( type ) of
selections for characteristics and the permitted Selection Type , as well as designate the field as Required Entry Field .
You can choose between the following input options:
Processing Method ( Type ) Effects
Generic (default) Selections are automatically transferred from the Report-Report Interface to the
jump target. We recommend that you first execute the jump with this setting and that
you only make other settings when the jump does not display the required result.
Only then is the full functionality of the RRI available.
V Variable Selections are transferred directly to the specified variables. In the Field Name
column, you have to enter the technical name of the variables. The Data Element ,
Domain and Parameter ID columns are automatically filled from the properties of
the variables.
This processing method is only applicable for BEx Queries. This is recommended if
you want to fill a variable in the receiver query and that variable has no technical
connection to the InfoObject of the sender query.
I InfoObject Selections are transferred directly to the specified characteristic. In the Field Name
column, you have to enter the technical name of the characteristic. The Data
Element , Domain and Parameter ID columns are automatically filled from the
properties of the characteristic.
This processing method is only applicable for BEx Queries. It is useful when an
assignment is not unique and a specific characteristic is to be transferred explicitly.
The characteristics assigned to one another have to have the same (non-
compounded) key. For example, the characteristics 0MATERIAL and 0MATPLANT
can be assigned to one another.
3 Table field Selections are transferred directly to the specified field. This setting is only useful for
non-BI jump targets. The Field Name, Data Element and Domain columns have
to be filled correctly. It also makes sense to fill the column Parameter ID with the
correct parameter ID. You can usually find the parameter ID in the ABAP dictionary
entry for the data element.
See also Creating a Transaction As a Receiver.
P URL parameters This setting is only useful for the Web Address jump target. Specification of a field
name is then mandatory.
See also Creating a Web Address As a Receiver.
Delete X All selections for this characteristic are deleted and not transferred to the jump
target.
This setting is useful when you do not want to transfer certain selections. For
example, you may not want selections for a characteristic to be transferred to a
characteristic that has the same reference characteristic.
When using these explicit rules, make sure that the assignment is already made in the sender system. If you jump to another system, note
that the sending and receiving InfoObjects of the assignment must exist in the sender system. Otherwise the jump will not work.
Choosing a selection type is worthwhile when the jump target is a longer-running query or transaction. When you choose a selection type with the
Required Entry indicator, during the jump you can prevent a report that was called from starting if it does not fulfill certain conditions. In this way, you
avoid putting unnecessary load on the system. Before the jump, the system checks whether the selection that is marked as a required entry is present in
the jump target; otherwise the jump is not executed.
For example, for a jump to an ERP system in the transaction MM03, you can mark the InfoObject Characteristic with selection type P
Parameter as a required entry field. The jump is only executed when the InfoObject Material is found in the ERP system.
Permitted Selection Type Effects
* (default) No restriction of the selection type. Single values, intervals, free selection options
and hierarchy nodes can be transferred.
P Parameters In the report-report interface, only one single value is permitted.
E Individual values In the report-report interface, a list of values is permitted.
I Interval In the report-report interface, only one single interval is permitted.
S Selection option You can choose single values, intervals and free selection options (such as >, <, <>,
). Hierarchy nodes are expanded in lists of single values.

H Hierarchy nodes Only hierarchy nodes are permitted.
When the system calls up the recipient, the settings made in the Field Assignments dialog box are set. The system proposes all other field assignments
generically.
4. Choose Close. The assignment details you defined are saved and are taken into account when the jump target is called.
1.3.1.10 SAP DemoContent for Features
Use
SAP DemoContent for Features provides complete example scenarios on selected OLAP functions. These example scenarios aim to give you a
comprehensive view of complex OLAP functions so that you can use them effectively and lucratively. The scenarios already contain all objects (InfoProviders
with master data and transaction data and queries) that you need to execute the functions in question for example purposes.
Prerequisites
You are authorized to use transaction RSFC .
Features
SAP DemoContent for Features is delivered with the technical content. You use transaction RSFC to call SAP DemoContent for Features.
Each example scenario in SAP DemoContent for Features contains predefined InfoProviders and queries. You have to activate the scenario in question to be
able to execute queries on the InfoProviders.
The activation causes the system to carry out the following steps:
The delivery version (D version) of the object is transferred into the active version (A version)
Master data delivered with the scenario (attributes, texts, and hierarchies) and transaction data are loaded to the InfoProviders
For each example scenario, you can use the Info function to call documentation containing further information on the business background for the scenario,
the OLAP function, and the objects to use.
There are example scenarios for the following OLAP functions:
Constant Selection
Slow-Moving Item Report
Tempory Hierarchy Join
Exception Aggregation
Conditions
Elimination of Internal Business Volume
Local Aggregation
Variables
Virtual Time Hierarchy
The namespace of objects always begins with the character string 0D_FC.
1.3.2 Performance Optimization
Purpose
Various functions support you in improving the performance of your BI system. You can differentiate between database, query and load performance.
As well as the functions listed here, other functions in InfoProvider modeling also affect performance.
Features
In the following sections, special BI functions for performance optimization are described in detail:
Performance Optimization with SAP NetWeaver BI Accelerator
Performance Optimization with Aggregates
Non-Cumulatives
BEx Monitor
Performance Optimization with SAP NetWeaver BI Accelerator

Purpose
SAP NetWeaver BI Accelerator allows you to improve the performance of BI queries reading data from InfoCubes. The system makes the data of a BI
InfoCube available as a BI accelerator index in a compressed but not aggregated form.
BI accelerator is particularly useful in cases where relational aggregates (see Performance Optimization with Aggregates) or other BI-specific methods of
improving performance (such as database indexes) are not sufficient, are too complex, or have other disadvantages.
For example, if you have to maintain a large number of aggregates for one particular InfoCube, you can use the BI accelerator to avoid this
high maintenance effort. Unlike performance optimization with aggregates, there is only one BI accelerator index for each InfoCube. As with
performance optimization with aggregates, you do not have to make any decisions regarding modeling for the BI accelerator index.
Implementation Considerations
The BI accelerator is based on TREX technology. To use the BI accelerator, you need an installation based on 64-bit architecture. Hardware partners deliver
this variant in preconfigured form as the BI accelerator box . Note that you cannot use a TREX installation configured for searching in metadata and
documents with the BI accelerator since TREX installations are based on 32-bit architecture. Equally, you cannot use a BI accelerator box for searching in
metadata and documents. If you want to use the search function as well as the BI accelerator, you require two separate installations.
For more information, see the following SAP Notes:

883726 TREX 7.0: Central Note SAP NetWeaver BI accelerator
902533 TREX 7.0: HowTo Guide Connecting/Operating BI Accelerator Box
Integration
Accessing the OLAP Processor

You can use relational aggregates and a BI accelerator index for the same InfoCube. A BI query always tries to use performance-optimized sources by
checking the sources from which it can draw the requested data. It checks the sources in the following order:
1. OLAP cache
2. BI Accelerator index
3. Relational aggregates from the database
4. InfoCubes from the database
If an active BI accelerator index exists, the OLAP processor always accesses this BI accelerator
index and not the relational aggregates. Therefore, with regard to modeling, we recommend that
you create either relational aggregates or a BI accelerator index for an InfoCube.
Query Execution
When the query is executed, it is clear to the user whether data is being read from an aggregate, a BI accelerator index, or an InfoCube.
In the maintenance transaction, you can deactivate a BI accelerator index on a temporary basis to test it for performance purposes or to analyze data
consistency.
You can also execute the relevant query in the query monitor (transaction RSRT) using a corresponding debug option: Choose Execute + Debug . In the
Debug Options dialog box, choose Do Not Use BI Accelerator Index to execute the query with aggregates or an InfoCube.
1.3.2.1.1 SAP NetWeaver BI Accelerator Index
Definition
A SAP NetWeaver BI accelerator index is a redundant data store of a BI InfoCube on the BI accelerator server.
Use
BI accelerator enables quick access to any data in the InfoCube with low administration effort and is especially useful for sophisticated scenarios with
unpredictable query types, high volumes of data and a high frequency of queries.
Structure
BI Accelerator index
A BI accelerator index contains all the data of a BI InfoCube in a compressed but not aggregated form. The BI accelerator index stores the data at the same
level of granularity as the InfoCube.

It consists of several, possibly split indexes that correspond to the tables of the enhanced star schema and a logical index which, depending on the definition
of the star schema, contains the metadata of the BI accelerator index.
BI Accelerator Server
The BI accelerator server is a TREX system as an installation of a BI accelerator engine. The data of the BI InfoCube is kept and processed entirely in the
main memory of the BI accelerator server.
The BI accelerator engine is the part of the analytics engine that manages the BI accelerator index. This software allows the system to read
data from the BI accelerator index, add data to the BI accelerator index, or change data. The BI accelerator optimizer is the part of the BI
accelerator engine that ensures the best possible read access to a BI accelerator index. More information: Technical Information About the
SAP NetWeaver BI Accelerator Engine.
Integration
Maintenance Processes for BI Accelerator Indexes

With the BIA index maintenance wizard you can create, activate, fill and delete BI accelerator indexes.
Like relational aggregates, a BI accelerator index is a redundant downstream data source that is used to improve query performance. For this reason, hierarchy
and change run processes and processes for rolling up data are derived from aggregate maintenance. More information: Rolling Up Data in SAP NetWeaver BI
Accelerator Indexes and System Response Upon Changes to Data: SAP NetWeaver BI Accelerator Index.
BI Accelerator Index as InfoProvider for Reporting

At query runtime, analytical engine functions such as aggregation, filtering, selection and some cell-based sorts are performed on the BI accelerator server.
Technical Information About the SAP NetWeaver BI Accelerator

Engine
Processing Data
After creating a BI accelerator index, the data is available on the file server of the SAP NetWeaver BI accelerator server. The data is loaded to the main
memory when you execute a query for the first time or start a special load program. The data remains in the main memory until it is replaced or is removed
from the main memory when a special delete program is started. It may be necessary to execute a special delete program if, for example, there is not enough
memory on the BI accelerator server for all BI accelerator indexes and you need to load data from particular InfoCubes but data from other InfoCubes is not
needed (at this time).
Table data is stored in the main memory in columns. Vertically segmenting data tables in this way is more efficient than saving row-based data in conventional
relational database systems. In a conventional database, the system has to search all the data in the table if a predefined aggregate is not available for a
query. The BI accelerator engine specifically accesses only those data columns that are relevant. It sorts the columns individually and puts the required entry
at the beginning. This improves performance considerably because the data flows are smaller. It also significantly reduces the input and output load and the
main memory consumption.
Compressing Data
Data is available on the BI accelerator server in a read-optimized format. The BI accelerator engine uses dictionary-based compression. Integers are used to
represent text or values in table cells. Using integers allows efficient numeric coding and intelligent caching strategies.
For example, if a column has a thousand rows and some of the cells contain long texts, efficiency is significantly increased by using a ten-bit
binary number to identify the texts during processing and a dictionary to call them again afterwards. The datasets that have to be transferred
and temporarily stored during the different processing steps are reduced on average by a factor of ten.
This means that you can perform the entire query processing in the main memory and reduce network traffic between separate landscapes.
Divided (Split) Indexes

The BI accelerator engine can process huge datasets, without exceeding the limits of the installed memory architecture. You can split large tables (fact tables
and large X and Y tables) horizontally, save them on different servers and process them quickly in parallel. The maximum table size before the system splits
the index depends on the existing hardware of the BI accelerator server. Data is distributed to the subindexes in a round-robin procedure. Write, optimize and
read accesses are parallelized on the BI accelerator server.
This scalability allows users to make use of sophisticated adaptive computing infrastructures such as blade servers and grid computing.
Index Types
The following index types are available:
Normal: In standard cases, the system creates BI accelerator indexes on the BI accelerator server for all the tables in the InfoCube star schema.
Flat: An exception arises if the InfoCube star schema has been deconstructed because, for example, one (or more) dimension tables have got very large
(> 20% of the InfoCube). In this case, the system does not create dimension tables but de-normalizes the appropriate part of the InfoCube star schema
(fact and dimension tables).

Using the BIA Index Maintenance Wizard
Purpose
You can create only one SAP NetWeaver BI accelerator index for each InfoCube. This BI accelerator index contains all the data from the InfoCube. In contrast
to the procedure with aggregates, it is not necessary to make specific selections and restrictions for the definition of the BI accelerator index.
Overview of Steps
Using the BIA index maintenance wizard, you can create and activate a BI accelerator index in a step and fill it or delete it as necessary. The following figure
outlines the possible steps:
Structure of the BIA Index Maintenance Wizard

In the upper area of the screen, the system displays a text field with information about each step. Corresponding pushbuttons are available:
Function Key Meaning
Exit Maintenance You exit the BIA index maintenance wizard.
Continue You navigate to the next step.
In the center area of the screen, you find the following tab pages:
On the Information tab page, you find additional information about the step.
On the Messages tab page, the system displays information about the current status.
On the Index Information tab page, the system displays the tables or indexes of the BI accelerator index and its properties (see SAP NetWeaver BI
Accelerator Index Designsap).
In this area of the screen, you find the following function keys:
Function Key Meaning
Application Logs The Log Selection dialog box appears. You choose the processes for which you
want to display the log. You can choose from the following processes:
Initial Filling
Roll Up
Compress InfoCube
Delete Request
Change Run
Check
Choose . The Analyze Application Log screen appears.
BIA Monitor The BI Accelerator Monitor screen appears (see Using the SAP NetWeaver BI
Accelerator Monitor).
BIA Index Properties If a BI accelerator index is available, the Maintain BIA Index Properties dialog box
opens .
You can specify the following settings:
Always store BIA index data completely in the main memory. This setting
is advisable if enough main memory is available, you constantly require
optimum response times, and the index is used frequently (see also
Checking SAP NetWeaver BI Accelerator Indexes (Transaction RSRV),
test Load BIA Index Data into Main Memory ).
Change the status of the BIA index: Active or I nactive (see scenario
2).
Further information about the index is also provided: Last Changed By , Date and
Time of last change, Index Type (see Technical Information About SAP
NetWeaver BI Accelerator Engine).

Prerequisites
Communication between the BI system and the BI accelerator server takes place using RFC modules. To connect a BI accelerator server to the BI system,
you must make the following settings:
Set up the RFC destination for the BI accelerator server (transaction SM59). For more information, see Customizing under SAP Customizing
Implementation Guide SAP NetWeaver Business Intelligence Connectivity of TREX Creation of RFC Destination in BI System .
Specify the RFC destination for the BI accelerator server (transaction RSADMIN). The RFC BI Accelerator parameter has to correspond to the above
RFC destination.
Note on System Landscape

Only one BI accelerator server can be used for each BI system. This is because the master data tables stored in the BI accelerator server can
be used by multiple BI accelerator indexes. However, this does not work if the data is distributed across various BI accelerator servers.
If you want to run BI accelerators with productive and test systems in a system landscape, we recommend using a separate BI accelerator
server for each BI system.
The InfoCube for which you want to create a BI accelerator is active and filled with data.
Process Flow
Access from Data Warehousing Workbench
1. You are in the Data Warehousing Workbench in the Modeling functional area. In the navigation window, choose InfoProvider . In the InfoProvider tree,
navigate to the InfoCube with the queries you want to optimize using the BI accelerator index.
2. In the context menu of the InfoCube , choose Maintain BI Accelerator Index . The first dialog box for the BIA index maintenance wizard appears.
Access from Transaction RSDDV
1. On the Aggregate/BI Accelerator Index: Select InfoCube screen (transaction RSDDV), select the required InfoCube.
2. Choose BIA Index . The first dialog box for the BIA index maintenance wizard appears.
Scenario 1
You call the BIA index wizard for an InfoCube that does not yet have a BI accelerator index.
Step 1: Creating a BI accelerator index
When you execute this step, the system creates the indexes for the tables of the InfoCube star schema on the BI accelerator server, as long as they have not
already been created by other BI accelerator indexes. These tables consist of the fact and dimension tables of the InfoCube as well as the master data tables
that contain the required SIDs, the S, X, and Y tables of the InfoObjects. A "logical index" is also created. This contains the metadata of the BI accelerator.
Finally, the system activates the BI accelerator index.
If the aggregate was filled successfully, the status in the Object Version column on the Index Info tab page switches to .
This step may take a few minutes if the individual tables are very large and have split indexes on the BI accelerator server. The more parts
into which the index is being split, the longer the duration of the activation step. For more information about split indexes, see Technical
Information About the SAP NetWeaver BI Accelerator Engine.
To use the BI accelerator index in reporting, you have to fill it with data. To schedule a background job to fill the BI accelerator index, choose Continue .
Step 2: Filling a BI accelerator index
The dialog box for specifying the Start Time appears. Specify when you want the fill job (RSDDTREX_AGGREGATES_FILL) to run in background processing
and choose .
When you execute this step, the system starts a process in the background that reads the data in the tables of the InfoCube star schema from the database
and writes them to the corresponding indexes on the BI accelerator server. If the index of a master data table (S/X/Y tables) has already been created and
filled by another BI accelerator index, only those records that have been subsequently added have to be indexed (read mode/fill mode "D" during indexing).
If the aggregate was filled successfully, the status in the Object Status column on the Index Info tab page switches to .
Reading the data from the database and writing the data to the BI accelerator server can be performed in parallel in the BI system in different
ways. To do this, maintain the system parameters in the BI accelerator monitor.
For more information about the steps for creating and filling a BI accelerator index, see Activating and Filling SAP NetWeaver BI Accelerator Indexes.
Step 3: Completing BI accelerator index maintenance
After the BI accelerator has been filled, you can choose Cancel to return to the source transaction or Continue to continue to the first part of BI
accelerator index maintenance. The BI accelerator index is available and can be used for queries.
Scenario 2
You call the BIA index wizard for an InfoCube that has a BI accelerator index that is already filled with data.
Step 1: Deleting a BI accelerator index
Since an active and filled BI accelerator index that can be used for reporting is already available, you can either temporarily deactivate it or delete it at this
point. This can be useful if you want to ensure, for performance purposes or analysis of data consistency, that the system is not using a BI accelerator index.
To delete the BI accelerator index, choose Continue .
The system deletes the definition and the settings of the BI accelerator index in the BI system and the logical index (metadata) and all indexes
for the tables of the enhanced star schema of the InfoCube on the BI accelerator server. The only exceptions are the indexes for the master
data tables that are still being used by other BI accelerator indexes.
To deactivate the BI accelerator index temporarily, choose BIA Index Properties . The BI Accelerator Index Properties dialog box appears. Choose
Inactive as the status of the BI accelerator index and choose .

A BI accelerator that is switched off is not used when a query is executed. Since BI accelerator indexes that are switched off must also be
consistent, you do not have to activate the BI accelerator index again or fill it when you switch it back on.
Scenario 3
You call the BIA index wizard for an InfoCube that already has an active BI accelerator index, but has not yet been filled or completely filled with data. The full
process is either terminated or not even started.
Step 1: Deleting or continuing to fill a BI accelerator index
Since an active BI accelerator index that can be used for reporting is already available, you can either continue to fill it with data or delete it at this point. You
can see the status of the individual indexes in the Messages from Previous Step area of the screen.
To fill the BI accelerator index, choose Continue Filling .
To delete the BI accelerator index, choose Delete .
Use
The following sections explain how you activate SAP NetWeaver BI accelerator indexes and fill them with data.
If you have created a BI accelerator index, you have to activate it and fill it with initial data before you can use it when you execute a query. See Using the
BIA Index Maintenance Wizard. For more information about the technical details, see Activating and Filling SAP NetWeaver BI Accelerator Indexes.
If you have loaded new data packages (requests) into the InfoCube, you have to roll up these data packages into the BI accelerator index before the data
is available in reporting. See Rolling Up Data in SAP NetWeaver BI Accelerator Indexes.
Activating and Filling SAP NetWeaver BI Accelerator Indexes
Purpose
If you want to use a SAP NetWeaver BI accelerator index with an InfoCube when you execute a query, you first have to create and activate a BI accelerator
index and fill it with initial data. You use the BIA index maintenance wizard for this purpose (see Using the BIA Index Maintenance Wizard).
For more information about the global indexing parameters, see Global Parameters for Indexing.
Additional technical information about these processes is provided in the following documentation.
Process Flow
Indexing Process by Table/Index on the BI Accelerator Server

The system performs the following steps in order to create an index on the BI accelerator server and make the data visible.
The name of the index is generated from the System ID and Table Name : <<system ID>>_<<table name>>. The system deletes the first
forward slash from the table name and replaces the second with a colon.
Create: For a table, the system creates the index on the BI accelerator server in accordance with the table properties. The system also determines how
many parts the index is to be split into, depending on the present size of the table.
Index: The data is transferred and written to a temporary file on the BI accelerator server.
Prepare optimize: The data in the temporary file is formatted (compressed, coded and so on) as required for search and aggregation. Depending on how
the index is distributed, this step can take longer than the indexing step.
Commit optimize: The previously optimized data is made visible. If you perform rollback for an index, the system rolls back the data to the last commit
optimize.
Example: Log messages for individual steps
Index 'BR8_BI0:XCOORDER' created for BI accelerator index
Index 'BR8_BI0:XCOORDER' filled for BI accelerator index (records written )
Prepare optimize for BI accelerator subindex 'BR8_BI0:XCOORDER'
Commit optimize for BI accelerator subindex 'BR8_BI0:XCOORDER'
The logs for the initial fill/indexing of a BI accelerator index are in the application log under object RSDDTREX, subobject TAGGRFILL.
Competing Processes During Indexing

You can activate and fill BI accelerator indexes for different InfoCubes simultaneously.
However, overlaps may occur if several indexing jobs try to index the same master data tables simultaneously. In this case, the first job locks the table and
performs indexing. The other jobs see the lock and schedule the indexing run to take place later. If no new data is loaded in the meantime, the system simply
checks that indexing was performed successfully by the competing job. This step is necessary to avoid the system setting a BI accelerator index to active
when the index is not actually available on the BI accelerator server because the job was terminated.
The subsequent jobs try a total of five times to start the indexing process or determine the status of the index. If this is not possible due to a long-running
process or termination, the system terminates the entire indexing process for the BI accelerator index and notes the InfoCube affected by the lock process.
You have to wait until the current program has finished or the error has been fixed before restarting the indexing process.
Example: Log for initial indexing with competing processes
Load to index for table '/BI0/SVC_PAYM2' locked by competing job
InfoCube of competing process: 'ZBWVC_003'
Lock for table '/BI0/SVC_PAYM2'. Job will be restarted later
...
No new data for index of table '/BI0/SVC_PAYM2'
BI accelerator index for InfoCube '0BWVC_003' filled successfully
Ability to Restart Processes

If a process is terminated by the user or the system during the initial data fill, you can restart the process by choosing the Continue Filling option in the
corresponding dialog box of the BIA index maintenance wizard (see Using the BIA Index Maintenance Wizard, scenario 3).
If indexing is terminated when the Commit Optimize is called, this is more problematic. After the Commit Optimize has been called, the data is visible and
you can no longer perform rollback. This process is normally very quick and has an extremely low error rate. However, if indexing is terminated at the point at
which the Commit Optimize is called, the status of the index is unknown to the system since the system does not know whether data is already visible. The
system does not know whether the termination occurred after or just before the commit optimize ran on the BI accelerator server. To clarify the status of the
index, you have to analyze the termination message and the status of the index carefully; you cannot automate this analysis. Therefore, when restarting the
process, the system normally re-indexes indexes that have status unknown and notes records them in the log. The fact index is the exception: Since this is
usually the largest BI accelerator index and re-indexing it takes a long time, the system does not automatically re-index the fact index. Instead the system
terminates the process and gives the index status unknown. In cases like this, it may be useful to analyze the log message and repair the index manually.
Rolling Up Data in SAP NetWeaver BI Accelerator Indexes
Use
As with relational aggregates, the data consistency of the InfoCube and SAP NetWeaver BI accelerator index is based on request handling in the BI system.
When you load new data packages (requests) into the InfoCube, these are not immediately available for use in a BI accelerator index for reporting purposes.
As with aggregates, the process that writes new data to the BI accelerator index is rollup.
Integration
If you replace the relational aggregates in an InfoCube with a BI accelerator index, you do not have to make further changes in the process chains or other
settings. The process and the associated programs are identical.
The compression of data packages after rollup, as performed with aggregates to improve efficiency (see Efficiently Loading Data to Aggregates in section
Setting Automatic Compression ), does not apply to BI accelerator indexes because the data on the BI accelerator server already exists in a read-
optimized format. However, it is useful to rebuild the BI accelerator index if the InfoCube is compressed heavily after rollup (see System Response Upon
Changes to Data: SAP NetWeaver BI Accelerator Index in section Compression ).
You can use delta indexes to speed up the rollup process. For information about optimizing the performance of BI accelerator indexes that are used
particularly frequently, see Improving Efficiency Using BI accelerator Delta Indexes.
Prerequisites
New data packages (requests) have been loaded into an InfoCube.
BI accelerator indexes for this InfoCube have been activated and filled with data.
Features
When you rollup data for an InfoCube, the system first loads the new data into any aggregates that exist in the InfoCube, and then determines the delta of the
missing records for all the tables that have an index in the BI accelerator index of the InfoCube and indexes it. If new SIDs are generated when transaction
data is loaded, the system also writes new records to the indexes of the S, X and Y tables. When the system has indexed all the indexes successfully, the
data of the most recent request is released for reporting.
Activities
As with relational aggregates, you only have to exit data rollup after loading transaction data.

For more information about the different execution modes for this activity, in particular the recommended execution types Including Rollup of
Data Packages As a Process in a Process Chain and Starting Rollup of Data Packages Manually , see Rolling Up Data in Aggregates
In InfoCube administration, where you can see whether a rollup is missing, running or successful, the system does not differentiate between whether the
InfoCube has aggregates or a BI accelerator index.
System Response Upon Changes to Data
Use
The following sections outline the points that you have to take into consideration if the data of the underlying InfoCube changes.
For information about hierarchy/attribute change runs with SAP NetWeaver BI accelerator indexes, as well as special cases where it is useful to
restructure a BI accelerator index, see System Response Upon Changes to Data: SAP NetWeaver BI Accelerator Index.
For information about further optimizing the performance of particularly frequently used BI accelerator indexes, see Improving Efficiency Using SAP
NetWeaver BI Accelerator Delta Indexes.
System Response Upon Changes to Data: SAP NetWeaver BI

Accelerator Index
Use
Since, like aggregates, SAP NetWeaver BI accelerator indexes are affected by changes to master data, they are also affected by hierarchy/attribute change
runs.
If an InfoCube that forms the basis of a BI accelerator index is later compressed or data is deleted from it, we recommend that you rebuild the BI accelerator
index.
Features
Hierarchy/Attribute Change Run

Since the data in master data tables (X and Y tables) is stored in indexes on the BI accelerator server, BI accelerator indexes, like aggregates, are affected
by changes to master data. However, in contrast to aggregates, the fact tables do not contain the current data for the master data. Therefore, you do not have
to run the potentially time-consuming delta calculations that you have to run for aggregates. Instead, you only transfer the changed records from the master
data tables and change them in the indexes on the BI accelerator server. In most cases, this is considerably quicker than modifying aggregates.
Since the hierarchy tables are not in the BI accelerator index either, there is no pre aggregation on specific hierarchy levels, as is the case with aggregates.
Again, calculation and modification is unnecessary. However, as with the BI hierarchy buffer, some views of hierarchies that occur in queries are stored on the
BI accelerator server as temporary indexes so that they can be reused. If the hierarchy is changed, these temporary indexes have to be deleted.
The system changes both the master data and the temporary hierarchy indexes during the hierarchy/attribute change run. In this process, the aggregates and
BI accelerator indexes for the relevant objects are determined for the previously changed InfoObjects that are selected. As before, the system first modifies
the aggregates in accordance with the changes (see System Response Upon Changes to Master Data and Hierarchies) and then runs the two quick processes
described for the relevant BI accelerator indexes:
The X and Y indexes are filled with the changed records.
The hierarchy buffer is deleted from the BI accelerator index.
Finally, the system activates the master data and displays the changed aggregates and BI accelerator indexes with the new data for reporting.
Compression
With BI accelerator indexes you do not have to compress after rolling up data packages. The data on the BI accelerator server already exists in a read-
optimized format.
However, in the following cases it may be useful to rebuild the BI accelerator index, although this is not strictly necessary.
A BI accelerator index is created for an InfoCube that is not aggregated, or a large number of data packages are later loaded to this InfoCube. If you compress
this InfoCube, more data is contained in the BI accelerator index than in the InfoCube itself and the data in the BI accelerator index is more granular. If
compression results in a large aggregation factor (>1.5), it may be useful to rebuild the BI accelerator index. This ensures that the dataset is reduced in the BI
accelerator index too.
Non-cumulative InfoCubes, that is InfoCubes with at least one non-cumulative key figure, should still be reconstructed in large intervals after compression. We
recommend this especially if the time to calculate the markers at query runtime is large.
Deleting Data
If you delete data from the InfoCube selectively, the BI accelerator index has to be rebuilt. When you execute selective deletion, the system automatically
deletes the affected BI accelerator index.
When you delete a data package (that is not aggregated) from an InfoCube, the index for the package dimension table is deleted and rebuilt. The facts in the

fact index remain but are hidden because they are no longer referenced by an entry in the package dimension table. Therefore, more entries exist in the index
than in the table of the InfoCube. If you regularly delete data packages, the number of unused records increases, increasing memory consumption. This can
have a negative affect on performance. In this case you should consider rebuilding the BI accelerator index regularly.
Improving Efficiency Using SAP NetWeaver BI Accelerator Delta

Indexes
Use
You can create a delta index for a SAP NetWeaver BI accelerator index. If a delta index exists, the system does not write to the main index during each delta
indexing or each indexing activity (except the initial filling/indexing) and the main index is not optimized. Instead, the system writes data to a second index
which has the same structure as the main index but is usually smaller. The smaller the delta index, the faster the subsequent optimize procedure and
therefore, the whole process of rolling up data or making modifications after a hierarchy or attribute change run.
As read performance deteriorates the larger the delta index gets, we recommend that you only switch on the delta index for essential indexes
such as fact indexes and X/Y indexes. This improves performance when you modify data after a hierarchy or attribute change run.
Integration
We recommend that you regularly merge the delta indexes with your main index so that read performance is not negatively affected. You can do this in several
ways:
On the Analysis and Repair of BI Objects screen (transaction RSRV), area BI Accelerator BI Accelerator Performance , you can select the Size
of Delta Index elementary test. You can choose Correct Error to access repair mode and then execute a MERGE for the indexes. For more
information about analyzing BI accelerator indexes in the analysis and repair environment, see Checking SAP NetWeaver BI Accelerator Indexes
(Transaction RSRV).
You can schedule program RSDDTREX_DELTAINDEX_MERGE.
Activities
To set the delta index for a BI accelerator index, on the BI Accelerator Monitor screen (see Using the SAP NetWeaver BI Accelerator Monitor), choose BI
Accelerator Index Information Set Delta Index. The Delta Index Properties dialog box appears.
Switching On the Delta Index

In the Delta Index column, set the corresponding indicator if you want the table to use a delta index.
The new setting takes effect with the next delta indexing operation.
Switching Off the Delta Index

You reset the setting for the delta index in the same way.
Before the next indexing operation, the system merges the delta index and the main index. If the delta index is already very large, the next process may take
longer.
1.3.2.1.5 Status Display and Check Tools
Use
The following sections outline how you get information about the structure and status of SAP NetWeaver BI accelerator indexes and list the checks that you
can perform.
If you want an overview of the technical status of the BI accelerator and access to actions to restore the status, see Using the SAP NetWeaver BI
Accelerator Monitor for the relevant information.
For more information about checking that the data records of a BI accelerator index are correct, checking the performance of BI accelerator indexes, or
specifically rebuilding one or all BI accelerator indexes, see Checking SAP NetWeaver BI Accelerator Indexes (Transaction RSRV).
For an overview of the runtimes of specific subprocesses in SAP NetWeaver BI accelerator index maintenance, see Statistics for Maintenance Processes
of SAP NetWeaver BI Accelerator Indexes.
You have various options for recording traces. For more information, see Traces for SAP NetWeaver BI Accelerator.
If due to a communication problem you do not want the BI accelerator server to be available, you can switch on a fallback solution. To do this, you have
to enter at least one e-mail address in table RSDDTREXEMAIL. The BI system saves the time of the error in table RSDDTREXHPAFAIL and sends the
relevant information to the e-mail address entered in table RSDDTREXEMAIL.
The recipient of the e-mail should trigger measures to remove the cause of the problem and delete the entry in table RSDDTREXHPAFAIL. When the
entry has been deleted, queries automatically read from the BI accelerator server again and not from the database.
For 30 minutes after the BI accelerator server goes down, or until the entry in table RSDDTREXHPAFAIL has been deleted, the system directs all query

requests for an InfoCube with a BI accelerator index to the database. The system tries to use aggregates for this InfoCube, if they are available.
After 30 minutes, if the problem is not resolved or if the time stamp entry is not deleted or changed, the system directs query requests to the BI
accelerator server again. If the problem still exists, the system writes a new time stamp and redirects queries to the database again for the next 30
minutes.
As soon as the BI accelerator is available, the system automatically sends all queries to the BI accelerator index of the affected InfoCube.
1.3.2.1.5.1 Using the SAP NetWeaver BI Accelerator Monitor
Use
The SAP NetWeaver BI accelerator monitor is used for the technical administration and maintenance of the SAP NetWeaver BI Accelerator. It provides an
overview of the current status of the BI accelerator.
The BI accelerator monitor displays the results of the consistency checks. These checks run periodically on the BI accelerator. If problems occur, the system
automatically proposes appropriate actions. These actions involve BI accelerator repair functions which can be used to fix problems.
The BI Accelerator monitor offers a detailed, technical overview of the hardware, BI accelerator services, any trace files that exist and the BI accelerator
indexes.
In the BI accelerator monitor, it is not possible to maintain the indexes on the logical level of the BI accelerator InfoProvider. Use BI
accelerator index maintenance instead (see Using the BIA Index Maintenance Wizard).
Queries work with the accelerator component of the BI accelerator, and the BI accelerator monitor works with the alert server. The accelerator
components and the alert server are independent services within the BI accelerator. For this reason, queries can run without errors while at the
same time, the BI accelerator monitor displays an error in the alert server.
Integration
You are in the Administration functional area of the Data Warehousing Workbench. In the navigation pane, choose Monitors BI Accelerator Monitor .
The BI accelerator monitor is displayed.
You have called the BIA index maintenance wizard for the InfoCube. In the dialog box for the BIA index maintenance wizard, choose BIA Monitor . The BI
accelerator monitor is displayed.
Integration in the CCMS Monitoring Architecture

If you do not only want to monitor your BI accelerator locally using the BI accelerator monitor, but want to monitor your BI system centrally with the BI
accelerator alongside other systems, you can use the central alert monitor (CCMS monitoring, transaction RZ20).
The information and the results that you can find in the BIA Check Results screen area of the BI accelerator monitor in the Check Results area on the
Summary and Current Results tab pages are displayed.
You can find more information about the connection of the BI accelerator monitor to the CCMS monitoring framework in SAP Note 970771.
More information about the CCMS monitoring framework: Alert Monitor
Prerequisites
The BI accelerator is based on TREX technology. For more information, see Performance Optimization with SAP NetWeaver BI Accelerator.
Features
BIA Results of Check Screen Area

Test Results area
Here the system displays the results of the BI accelerator consistency checks.
Tab Page Description
Summary The start view shows a summary of the current results of the check.
The system tries to summarize the current results of the check in such a way that the
status of the BI accelerator can be repaired in as few actions as possible.
The status display shows:
if the status is ok
if there are messages or warnings
if there are errors for the status
With status and , the system usually displays an action that can fix the

problem. If the proposed action can be started from the BI system, you initiate this
action by choosing in the Execute column.
For each action, the user can display an explanatory long text by choosing
( Display Long Text ).
If details are available for a check, you can call them by choosing ( Details
Available ) in the Details column. The system displays the details in the Check
Details screen area.
Current Results This view displays the current results of the consistency checks that were
performed.
The status of the checks are indicated by the colors , or .
The system displays general information about each check: the length of the check
(in seconds), the date and time at which the check was started, and the check set
within which the check was started.
For each check, the user can display an explanatory long text in the Long Text
column by choosing ( Display Long Text ).
If a check determines that an action is required to solve the problem, the system
displays the action in the table. You start the action by choosing in the Execute
column. Choose to display an explanatory long text.
If details are available for a check, you can call them by choosing ( Details
Available ) in the Details column. The system displays the details in the Check
Details screen area.
History This view returns the results of previous runs for the BI accelerator consistency
checks so that you can track developments or changes in the results.
The system displays general information about each check: the length of the check
(in seconds), the date and time at which the check was started, and the check set
within which the check was started.
For each check, the user can display an explanatory long text in the Long Text
column by choosing ( Display Long Text ).
Since this information is not current, the system does not propose actions.
You can find out about the state of the BI accelerator at a scheduled moment in time by e-mail. More information: section Menu BIA Checks .
Check Details area
If more details are available for the results of the check, the user can display them here.
If problems are listed with BI accelerator servers, you can display the affected servers in the details area.
BIA Actions Screen Area

Execute Actions area
In the Execute Actions screen area, the user can directly execute the most important actions to resolve BI accelerator problems. The BI accelerator
differentiates between actions that the user can start from the BI system and those that the user must carry out in the BI accelerator.
Example of an action that the user must carry out in the BI accelerator: Actions for the trace files of the BI accelerator.
On the Current Results tab page in the Check Results screen area, the BI accelerator proposes actions for check results that have status or . If these
are actions that can be executed from the BI system, you can execute them directly by choosing .
In the Execute Actions screen area, the BI accelerator monitor collects all the proposed actions. It sets the indicator if the action can be started from the BI
system. A Proposal field is displayed alongside the proposed actions.
Here the system supports the direct execution of the following actions:
Action Description
Restart host This action restarts the BI accelerator hardware.
Restart BIA server This action restarts all the BI accelerator servers and services. This includes the
name server and index server.
Restart BIA index server This action only restarts the index server. (The name servers are not restarted.)
Rebuild BIA indexes If a check discovers inconsistencies in the indexes, you can use this action to delete
and rebuild all the BI accelerator indexes.
Reorganize BIA landscape If the BI accelerator server landscape is unevenly distributed, this action
redistributes the loaded indexes on the BI accelerator servers.
The actions Restart Host, Restart BIA Server, and Restart BIA Index Server are hierarchically related: If the host is restarted, the server is automatically
restarted so that this action no longer has to be started explicitly. For example, the Restart BIA Server action includes a restart of the BIA index server.
Therefore, as soon as a higher-level option is selected, the system automatically sets the indicator for the lower-level selection boxes and deactivates them
for the selection.
BIA Action Messages area
The log display in the BIA Action Messages screen area shows information about the processes in the BI accelerator monitor.
If the system reads status information (gets check results), it writes this to the log, for example: Status Information Read from BIA.
Each message has a status ( , , ). Where appropriate, you can also display the explanatory long text by choosing .
The Detail Level is usually rule 1, unless the messages are structured hierarchically.

You use ( Refresh Messages ) to refresh the log display.
You use ( Delete Messages ) to delete the messages in the log.
Toolbar Functions
The following functions are available in the toolbar:
Function Description
(Refresh BIA Log and Actions ) Refreshes the monitor.

The system displays the current results of the BI accelerator checks again and
makes new proposals for actions.
BIA Availability Uses an RFC availability test to check the availability of the connection to the BI
accelerator. If no connection to the BI accelerator is available, necessary measures
are initiated.
Switch On BIA Load Monitor or Switch Off BIA-Load Monitor Calls the BI accelerator load monitor in a separate window that refreshes itself
independently.
In this window, you can see the following BI accelerator key figures:
Host:Port : Host and port of the BI Accelerator
Memory Process : Memory usage of TREX server process
Total Memory : Memory usage of all processes
Memory Available : Available memory
CPU of All Processes : CPU usage of all processes
CPU Process : CPU usage of TREX server processes
Response Time : Average response time of the last queries
Queries : Queries per second
Requests : Number of external requests
Requests Including Internal : Number of external and internal requests
Requests Active : Number of active requests
Hanging Requests : Number of hanging requests
You can only start one load monitor.
Since the load monitor is started in a new window, it uses a new mode. Make sure
that a mode is available before you activate the load monitor.
For technical reasons, the load monitor window is kept open. If it is hidden by other
windows, you can access it using the key combination ALT+TAB . You can continue
to work in this window or close it.
You can only end the load monitor from the BI accelerator monitor: As soon as you
start the load monitor, the pushbutton function changes to Switch Off BIA Load
Monitor. After you have stopped the load monitor, the system resets the mode to
the start view.
Menu BIA Checks

You can broadcast the results of the consistency checks of the BI accelerator (an overview of the summary and the current results) by e-mail from the entry
Schedule E-Mail Notification .
In the Start Time dialog box, you can schedule the respective job for the required point in time.
The e-mail is then created and broadcast to all addresses in the RSDDTREXEMAIL table.
Menu Goto
You can choose the following options from the Goto menu:
Menu Option Meaning
Analysis of BI Objects The Analysis and Repair of BI Objects screen appears. More information:
Checking SAP NetWeaver BI Accelerator Indexes (Transaction RSRV)
BIA Index Maintenance The Maintaining Aggregates/BIA Index: Select InfoCube screen appears
(transaction RSDDV). More information: Using the BIA Index Maintenance Wizard.
TREX Administration Tool The TREX Administration Tool screen appears.
Consistency Checks On this screen, you can check the data on the BI accelerator server, schedule these
checks, and view the logs of checks that have already run. You can group certain
checks to form check sets.
Menu BI Accelerator
You can choose the following options from the BI Accelerator menu:
Menu Option Meaning
Execute Action You start required actions directly from the BI system (see BIA Actions screen area
above).
Switch On BIA Load Monitor or Switch Off BIA Load Monitor You can call the load monitor of the BI accelerator in a separate window (see
Toolbar Functions above).
Index Checks With the Execute/Display Index Checks menu option, the system executes the
following checks once a day (always at 0:00:01) and then displays the results:
Check size of delta indexes for BIA indexes
Compare size of InfoCube fact table with fact index
Find indexes with status unknown

Check: Table index relation
These checks are quick to run and provide important information about
performance and consistency. They can be found in the analysis and repair
environment (see Checking SAP NetWeaver BI Accelerator Indexes (Transaction
RSRV)).
If you do not want to run these checks regularly, you can choose the Schedule
Index Checks option from the menu and specify that the system should not
schedule the checks.
Index Information You can call the following functions from this menu option:
Change Global Parameters : See Global Parameters for Indexings.
Display All BIA Indexes : See SAP NetWeaver BI Accelerator Index
Designs.
Set Delta Index : See Improving Efficiency Using SAP NetWeaver BI
Accelerator Delta Indexess.
Switch BIA Indexes for Queries On/Off
Activities
You get detailed information about the status of the SAP NetWeaver BI Accelerator and the check results.
The system proposes actions to correct errors in the BI accelerator, if applicable.
If these actions can be started in the BI system, you can trigger them there immediately.
1.3.2.1.5.1.1 Global Parameters for Indexing
Use
You use this dialog box to edit the default values for the global indexing parameters.
Integration
To navigate to this dialog box, on the SAP NetWeaver BI Accelerator Monitor screen (transaction RSDDBIAMON), choose BI Accelerator Index
Settings Change Global Parameters .
Features
Global Indexing Parameters
Name Description Value (Changeable)
BATCHPARA Number of Processes for Background Parallel 03

Processing of Initial Indexing
Number of parallel background processes for initial
indexing: F and E fact tables of the InfoCube are split
into a number of blocks. The BACTHPARA parameter
specifies the number of blocks. (The E table is split
using the partitioning characteristic or another time
characteristic; the F table is split using the request.)
These blocks are then read from the database and
written to the BI accelerator separately. (Note that a
number of dialog processes, as specified in the
NUMPROC parameter, are used for each background
process.)
This applies to initial indexing only and not roll up.
You can change the values for these parameters in
transaction RSBATCH (process type TREXINDEXP).
NUMPROC Number of Processes for Parallel Processing Using 5

aRFC Dialog Processes During Indexing
The data is read from the database table on a
package-by-package basis using Open Cursor and
Fetch. The system calculates the package size from
the width of the table and the default value for the
package size (in bytes) in the system.
If you set a degree of parallelization that is greater than
one, each of these packages is indexed in a new
asynchronous job in dialog mode. When the indexing
job for the package is started, the system reads a new
package immediately. Ideally, you should reduce the
indexing time to the time that is required to read the
data and pack it for the RFC module.

If the degree of parallelization is equal to one, the
system performs serial processing.
The optimization of the BI accelerator index cannot be
parallelized on the BI side. However, optimization
automatically runs in parallel on the BI accelerator
server if the index is split.
PKGSIZE Package Size in Bytes for Internal Tables During 10.000.000

Indexing Using aRFCs
SUBPKGSIZE Package Size (Rows) for Export to Buffer During 20.000

Indexing Using aRFCs
During dialog parallel processing with the NUMPROC
parameter, packages with size PKGSIZE are read and
indexed using aRFCs. To do this, the data packages
must be transferred using Export to Data Buffer . This
is done on a package-by-package basis since it
requires a large amount of CPU and memory
resources. The SUBPKGSIZE parameter specifies the
number of rows for the package. We recommend a
value between 10,000 and 20,000.
Activities
You use this dialog box to edit the values of the global indexing parameters.
1.3.2.1.5.1.2 SAP NetWeaver BI Accelerator Index Design
Use
The design of a SAP NetWeaver BI accelerator index provides information about the structure, properties and status of the SAP NetWeaver BI accelerator
index and its tables/indexes.
Tables that are part of the enhanced star schema of the selected InfoCube and are required in the corresponding BI accelerator index form part of the
description of the BI accelerator index.
All the dimension tables of the InfoCube are required for the star schema of the BI accelerator index. The E and F fact tables of the InfoCube
form one fact index. Of the master data tables, only the X and Y tables (which contain the SIDs) are required; the P and Q tables (which
contain the key values) are not required. The SID tables (S tables) are required if the InfoObject has a non-numeric key.
Integration
BIA index-specific information can be displayed in BIA index maintenance and in the BI accelerator monitor.
BIA Index Maintenance
As soon as a BI accelerator index has been created, the system displays information about its tables and indexes on the Index Info tab page (see Using
the BIA Index Maintenance Wizard).
BI Accelerator Monitor
If you choose BI Accelerator Index Information Display All BIA Indexes , the Information about BIA Indexes dialog box appears. The system
displays all the BI accelerator indexes that exist in the system.
Features
In the BI accelerator monitor, the system shows more information than in BIA index maintenance. The following table provides an overview of this information.
* indicates that the column is displayed in BIA index maintenance as well as in the BI accelerator monitor.
Description of a BI accelerator index
Column Description
InfoCubes Technical name of the InfoCubes for which BI accelerator indexes have been
created
Object Version Status display:

BI accelerator index is active.
BI accelerator index is not active.
See Activating and Filling SAP NetWeaver BI Accelerator Indexes
Object Status Status display:

BI accelerator index is filled.
BI accelerator index is not filled.
See Activating and Filling SAP NetWeaver BI Accelerator Indexes
Table Name * Technical name of the relevant index on the BI accelerator server.

Table Size * Specifies the approximate current size of the individual tables (number of data
records), as calculated from the database statistics.
Index Status * Status of index
with Delta Index * Indicates that a delta index is being used for the BI accelerator index (see Improving
Efficiency Using SAP NetWeaver BI Accelerator Delta Indexes).
Multiple Usage * With S, X and Y tables, this indicates that one of the tables is already being used by
another BI accelerator index and therefore already exists as an index.
Last Changed By * Name of user who made the last change.
Last Changed/Time Stamp * Date and time of last change.
Checking SAP Net Weaver BI Accelerator Indexes (Transaction

RSRV)
Use
On the Analysis and Repair of BI Objects screen (transaction RSRV), various checks are available for:
Testing for inconsistencies between the data in the InfoCube on the database and the data in the BI accelerator index (tests in the BI Accelerator
Consistency Checks area )
Testing whether a SAP NetWeaver BI accelerator index is running with the most optimal performance (tests in the BI Accelerator Performance Checks
area)
Completely or partially building or rebuilding all BI accelerator indexes or a specific BI accelerator index (tests in the BI Accelerator Repair Programs
area )
The exactness and duration of each of these checks vary.
For more information about building and using the analysis and repair environment, see Analysis and Repair Environment.
Integration
In the SAP NetWeaver BI Accelerator Monitor , you can specify that the system is to run a small number of tests on a daily basis. You do this by choosing
BI Accelerator Execute/Display Index Checks . For more information, see Using the SAP NetWeaver BI Accelerator Monitor.
Prerequisites
The SAP NetWeaver BI accelerator index you want to check has been activated and filled with data.
Some tests work with statistics data (see tests: Propose Delta Index for Indexes, Compare Size of Fact Tables with Fact Index ).
As a prerequisite, the statistics have to be switched on for the relevant InfoProvider. You make this setting in statistics properties maintenance screen (on
the Data Warehousing Workbench screen, choose Tools Settings for BI Statistics ). For more information, see Statistics for Maintenance
Processes of SAP NetWeaver BI Accelerator Indexes.
Features
The following tests are available under All Elementary Tests BI Accelerator :
BI Accelerator Consistency Checks

Master Data and Transaction Data
Compare Data in BI Tables and BIA Indexes ( Check Table Index Content )
The system compares the content of each individual table with the content of the corresponding index on a record-by-record basis. This check is only
suitable for tables or indexes that do not contain a large amount of data, such as dimension tables, certain SID tables (S) and attribute tables (X and Y).
This is not generally the case with fact tables. If a table contains 10,000 records or more, it is not checked.
In some situations, the content of the indexes of the BIA index may differ from the content of the corresponding database table. This may be the case if
requests have been deleted from the InfoCube or if an InfoCube has been compressed.
Check Sums of Key Figures of BIA Querie s ( Check Key Figure Sums Internally )
First the system executes a query on the BI accelerator index, which is aggregated using all key figures. Next, all the characteristics and navigation
attributes that exist in the InfoCube are included in the drilldown individually and the totals are calculated. The system compares the result with the result
of the first query. This test checks the completeness of the join path from the SID table, through the dimension table, to the fact tables.
Runtime: Depends on the number of characteristics and navigation attributes and on the number of records in the fact table.
If the test shows that the data is incorrect, you have to rebuild the BIA index and the indexes for the master data tables.
Check Sums of Key Figures of BIA Queries with Database ( Check Table Index of Key Figure Totals )
Similar to mode Internally Check Key Figure Totals , the system executes highly-aggregated queries and compares the results of the InfoCube in the
database with those of the BI accelerator index.
For large InfoCubes the runtime may already be considerable, since queries to the database take longer.
Check Existence of Indexes for Database Tables ( Table-Index Relation )

An index is created for almost every table of the BI InfoCube enhanced star schema: fact (F) tables, dimension (D) tables, SID (S) tables and attribute
tables (X and Y); the only exception is SID tables with numeric characteristic values.
This test checks whether the named indexes have been created on the BI accelerator server.
Runtime: Very fast
If the test reveals that an index is missing, rebuild the index for the table.
Check for Consistency Using Random Queries
The system creates random queries without persisting them. These random queries are only used for this test: The system reads the data once from the
database and once from the BI accelerator. It then compares the results. If the results differ, an error message is output.
Note that there can be different results if the data of the InfoCube is changed between execution of the query on the database and in the BI
accelerator (for example by a change run or by rolling up new requests).
You can verify the results by executing the program RSDRT_INFOPROV_RANDOM_QUERIES with the following parameters:
InfoProvider: Name of the InfoCube
Number of queries: 10
Starting value of random generator
Trace comparison: 'X'
You can leave all other values unchanged. The program can also be executed in the background and the results viewed in the spool list.
If you use the same starting value, the same random queries are generated; you can thus repeat the test.
Automatic repair is not available. If necessary, you must rebuild the BI accelerator index.
Verification of the Buffer Entries of the BIA Hierarchy Buffer
When queries in hierarchies are executed, the relevant hierarchy nodes are expanded to the relevant leaves. This leaf-node relation is saved in a
temporary index in the BI accelerator. The hierarchy buffer manages expanded hierarchies according to an LRU (least recently used) algorithm.
The check verifies whether all temporary indexes in the hierarchy buffer contain the correct data.
If the hierarchy buffer contains incorrect entries, write a customer message. This state is incorrect. If you urgently need to resolve the error, you can
delete the entire hierarchy buffer. In this case, however, SAP will not be able to find the error.
Metadata
Check Definition of Logical Index
The system compares the definitions of each of the indexes for a BIA index with the current versions of the database tables. It checks whether the
number, name, and type of the table fields in the database match the definition for the index on the BI accelerator server.
An index may have changed if, for example, the InfoCube was changed. If this is the case, the BI accelerator index has to be repaired (see test BIA
Index Adjustments After InfoCube Activation ).
Note that if you do not specify an InfoCube, the system executes the test for all InfoCubes that have a BI accelerator index.
If an index has been changed, the system deletes the old index, creates a new index with the correct definition, and fills it. All BI accelerator indexes that
use this index are set to "inactive"; they are not available for reporting purposes during this time.
Runtime: Depending on the size of the table, this process may take some time.
Compare Index Definition in BIA with Table on Database
The system checks the logical index of a BI accelerator index. The logical index contains the metadata of the BI accelerator index, such as the join
conditions and the names of the fields.
The logical index may change if, for example, the InfoCube has been changed. If this is the case, the BI accelerator index has to be repaired (see test
BIA Index Adjustments After InfoCube Activation ).
Note that if you do not specify an InfoCube, the system executes the test for all InfoCubes that have a BI accelerator index.
If the logical index has been changed, the system deletes the old index and creates a new index with the correct definition. The system temporarily sets
the BI accelerator index to "inactive"; it is not available for reporting purposes during this time.
Find indexes with status unknown
The system checks whether BI accelerator indexes contain indexes that have the status "unknown" (= U). This only occurs in exceptional cases when the
commit call (commit optimize) terminates during indexing. Since in this case it is not clear whether the data from the preceding indexing call is
available, the affected indexes are rebuilt in repair mode.
BI Accelerator Performance Checks

Size of Delta Index
If you have chosen delta mode for an index of a table, new data is not written to the main index but to the delta index. This can significantly improve
performance during indexing. However, if the delta index is large, this can have a negative impact on performance when you execute queries. When the
delta index reaches 10% of the main index, the system displays a warning.
The system performs a merge for the index in repair mode. The settings are retained.
Propose Delta Index for Indexes
It is useful to create a delta index for large indexes that are often updated with new data. New data is not written to the main index, but to the delta index.
This can significantly improve the performance of indexing, since the system only performs the optimize step on the smaller set of data from the delta
index. The data from the delta index is used at query runtime.
The system determines proposals from the statistics data: Proposals are those indexes that received new data more than 10 times during the last 10
days. A prerequisite for these proposals is that the statistics for the InfoCube are switched on.
Data in the main index and delta index should be merged at regular intervals (see test Size of Delta Index ).
In repair mode, the system sets the Has Delta Index property for the proposed indexes. The delta index is created when the data is next loaded for this
index.
Compare Size of Fact Tables with Fact Index
The system calculates the number of records in both fact tables (E and F tables) for the InfoCube and compares them with the number of records in the
fact index of the BI accelerator index. If the number of records in the BI accelerator index is significantly greater than the number in the InfoCube (more
than a 10% difference), you can improve query performance by rebuilding the BIA index.
The following circumstances can result in differences in the numbers of records:
The InfoCube was compressed after the BI accelerator index was built. Since the BI accelerator index is not compressed, it may contain more
records than the InfoCube.
Requests were deleted from the InfoCube after the BI accelerator index was built. The requests are deleted from the BIA index in the package

dimension only. The records in the fact index are therefore no longer referenced and no longer taken into account when the query is executed;
however, they are not deleted.
Note that the database statistics for calculating the size of the fact table must be up to date, since the test does not recount; it uses the
database statistics from the tables.
Load BIA Index Data into Main Memory
You use this test to load all the data for a BI accelerator from the file server into the main memory if the data is not already in the main memory.
This action is useful if you want to ensure that queries executed in the corresponding InfoCube achieve optimal performance the first time they are
executed and do not have to read data anew from the file server.
Data for an index is deleted from the main memory, for example, when new data is added to this index (during roll up or a change run). In BIA index
maintenance (choose BIA Index Properties , see Using the BIA Index Maintenance Wizard), you can also adjust the settings for the BI accelerator index
such that data is loaded automatically to the main memory every time changes are made.
Note that if you do not specify an InfoCube, the system executes the test for all BI accelerator indexes that are active and filled.
Delete BIA Index Data from Main Memory
You use this test to delete all data for a BI accelerator index from the main memory.
Master data indexes that are still required by other InfoCubes are not deleted from the main memory. The data on the file server is not deleted the BI
accelerator index is still active.
This action is useful if there is little space in the main memory on the BIA server and you have data in the main memory that can be deleted. This is
useful in the following cases:
There is data in the main memory that is no longer used or is rarely used.
There is data in the main memory that does place a high load on system performance when the query is executed initially (and when the file server is
read in the main memory).
If you do not specify an InfoCube, the system runs the test for all BI accelerator indexes that are active and filled.
Estimate Runtime of Fact Table Indexing
The system estimates the time required to fill the fact index. It uses the current parameter values for background and dialog parallel processing. The time
taken is calculated from the processes available and the estimated maximal throughput of data records in the database, the application server, and the
BIA server.
The calculated duration is an estimate; the load on the system, the distribution of data across block criteria and deviations during processing can all affect
the actual time taken.
Estimate Memory Consumption of Fact Table Index
The system estimates the size of the fact table index of a BI accelerator index. In doing so, the system analyzes the data in the fact table and provides a
projection.
Note that if data distribution is poor, the actual memory consumption can deviate from the projected value. A more exact analysis would
demand more time than that required to rebuild the index, since the number of different values in the fact table needs to be determined for each
column (count distinct).
BI Accelerator Repair Programs
Delete and Rebuild All BIA Indexes

All BI accelerator indexes in the system are deleted. If you selected the Execute option, the indexes are then recreated and filled. This is sometimes
required for a successful restart with consistent data if a critical error occurs.
BIA Index Adjustments After InfoCube Activation
If an InfoCube is changed as a result of the addition of a key figure, for example, the system does not automatically adjust the BI accelerator index, since
the relevant process may take a long time and can even require a partial reindexing.
When you execute this test, information about any changes identified are written to the log. The system makes the required changes in repair mode.
We recommend that you run this repair job as a background job, if required.
Rebuild All Master Data Indexes of a BIA Index
All indexes for master data tables in a BI accelerator index are rebuilt. This includes indexes for SID tables and attribute tables (X and Y tables). When an
entire BI accelerator index is rebuilt, these tables are not always rebuilt since they are also used by other BI accelerator indexes. If this results in data
consistency issues, it may be necessary to rebuild the indexes for the master data tables.
In repair mode, the system first deletes the relevant indexes and then recreates them. All BI accelerator indexes that use these indexes are set to
"inactive"; they are not available for reporting purposes during this time.
The following tests are available under All Combined Tests BI Accelerator :
Consistency Checks (Detailed)
Consistency Checks (Fast)
Performance Tests
Execution Modes
Execution Mode Description
Schedule The dialog box for specifying start dates appears. Specify the time(s) for the
execution. You can view the results of the check in the protocols in the application
log.
Correct Error In repair mode, the system performs certain repair tasks. (Repair tasks are not
available for all tests).

Evaluating Logs
1. In the Selection of Check Mode for BI Accelerator Index dialog box, choose Display Logs . The Analyze Application Log screen appears for object
RSDDTREX, subobject TAGGRCHECK.
2. Enter the required data to restrict the number of logs.
3. Choose Execute . The system displays the results of the check.
Activities
You select the test(s) and specify the mode of execution. You can view the results of the check in the protocols in the application log.
Checking SAP NetWeaver BI Accelerator Indexes (Check Center)
Use
From the SAP NetWeaver BI accelerator monitor , choose Goto Consistency Checks to display the BI Accelerator Data Consistency Check Center
screen. On this screen, you can check the data on the BI accelerator server, schedule these checks, and view the logs of checks that have already run. You
can group certain checks to form check sets.
Procedure
Creating a New Check Set

1. Give the check set a description.
2. Specify the InfoCubes of the BIA index for which the check set is to be executed. Input help is available. Multiple selections are possible.
3. Specify the maximum degree of parallelization if necessary. The degree of parallelization is only applicable for background processing. The system
starts one process (dialog) for each InfoCube; a maximum of n processes are executed simultaneously (n = parameter value).
4. If necessary, set the indicator If errors occur deactivate BIA index for queries . If you set this indicator, the BIA index is immediately set to 'inactive'
(cannot be used for queries) as soon as the check set displays incorrect data in the BIA index. This prevents incorrect data being used for reporting in the
BIA. Note, however, that a check can display incorrect data even though the data is correct, for example, because a load process (master data or
transaction data) has changed the data at the same time.
5. If you want an e-mail to be sent if an error occurs (if incorrect data is displayed), enter the address of the recipient in the relevant field.
6. If the check set is to be executed immediately after the rollup of new requests to an InfoCube, set the relevant indicator. The check set is then still part of
the process (this is relevant for integration into a process chain), but the lock on the process is no longer valid, so that other processes are not
interrupted. The check set is not executed for all InfoCubes, but only for the InfoCube for which the data was rolled up.
7. If the check set is to be executed immediately after the change run, set the relevant indicator. As before, the check set is still part of the process, but the
lock on the process is no longer valid. The check set is only executed for the InfoCubes whose BIA index was adjusted in the change run.
8. Each tab page contains a test. You can find the description of the test under Details of Check. Select the checks relevant for your check set by setting
the corresponding indicator for Execute Test . Select the check-specific options.
Overview of Consistency Checks
Tab Page Test Description
Data Compar. For more information, see Checking SAP NetWeaver BI Accelerator Indexes
(Transaction RSRV): BI Accelerator Consistency Checks Compare Data in BI
Tables and BIA Indexes (Check Table Index Content)
Totals in BIA For more information, see Checking SAP NetWeaver BI Accelerator Indexes
(Transaction RSRV): BI Accelerator Consistency Checks Check Sums of Key
Figures of BIA Queries (Check Key Figure Sums Internally)
BIA and DB Totals For more information, see Checking SAP NetWeaver BI Accelerator Indexes
(Transaction RSRV): BI Accelerator Consistency Checks Check Sums of Key
Figures of BIA Queries with Database (Check Table Index of Key Figure Totals)
Random Queries For more information, see Checking SAP NetWeaver BI Accelerator Indexes
(Transaction RSRV): BI Accelerator Consistency Checks Check for
Consistency Using Random Queries
Index Exist. For more information, see Checking SAP NetWeaver BI Accelerator Indexes
(Transaction RSRV): BI Accelerator Consistency Checks Check Existence of
Indexes for Database Tables (Table-Index Relation)
9. Save the check set. A check set ID is allocated and displayed.
Displaying and Changing an Existing Check Set

To display an existing check set, place the cursor in the Check Set ID field and select the required check set from the input help.
Change the parameter values of the selected check set and save it again. A new check set ID is not allocated.
Executing a Check Set

Select an existing check set or define a new one.
When you choose Execute , the checks for the check set are executed in the dialog (and not in parallel). The check set does not have to be saved
beforehand. When the check is complete, the system automatically displays the results in the application log.

Choose Schedule to open the Start Time dialog box. Here you can schedule the check set to run once or periodically in the background. The check set
must be saved beforehand. The name of the scheduled job is BW_TR_RSDDTREX_INDEX_CHECK.
You can also execute a check set by using program RSDDTREX_INDEX_CHECK. To do this, you need the check set ID, or you can select the check set
from the input help. You can also use this program to add a check set to process chains. To call the logs, choose Logs .
Deleting a Check Set

Select an existing check set, choose Delete , and answer Yes to the confirmation prompt.
Statistics for Maintenance Processes of SAP NetWeaver BI

Accelerator Indexes
Use
To get an overview of the runtimes of specific subprocesses in SAP NetWeaver BI accelerator index maintenance, you can display the RSDDSTATTREX
table.
For the following processes, the system writes the runtimes of specific subprocesses to this statistics table:
Initial indexing (see Using the BIA Index Maintenance Wizard)
Rollup (see Rolling Up Data in SAP NetWeaver BI Accelerator Indexes)
Modifications after change runs (see System Response Upon Changes to Data: SAP NetWeaver BI Accelerator Index)
Integration
Some BI accelerator tests in the analysis and repair environment work with statistics data (see Checking SAP NetWeaver BI Accelerator Indexes (Transaction
RSRV), tests: Propose Delta Index for Indexes, Compare Size of Fact Tables with Fact Index ).
Prerequisites
The statistics have to be switched on for the relevant InfoProviders. You make this setting in statistics properties maintenance screen (on the Data
Warehousing Workbench screen, choose Tools Settings for BI Statistics ). For more information, see Maintenance of Statistics Properties.
Features
The statistics table contains the following information for each table that is indexed:
RSDDSTATTREX
Column Description
STATUID Unique identification key
TABLNM Table name
CHANGEMODE Specifies whether the process is part of a BI accelerator rebuild ("N"), the rollup
("R") or a modification after a change run ("C").
FILLMODE Fill Mode: Full ("F"), delta ("D") or change run ("C")
TIMEACTIVATE Time of activation
TIMEREAD Time required to read data from the database
TIMEFILL Time required for packing and indexing
TIMEOPTIMIZE Time for Prepare Optimize
TIMECOMMIT Time for Commit Optimize
REC_INSERTED Number of indexed records
TSTPNM User
TIMESTMP Start time stamp
Traces for SAP NetWeaver BI Accelerator
Use
When errors occur it can be useful to record system responses in the form of traces. SAP support has tools to evaluate these traces.

This may be the case, for example, if you are obtaining different results for a BI query depending on whether you use the SAP NetWeaver BI
Accelerator.
Integration
To record traces for query execution, use the query monitor (see Query Monitor).
To record performance traces, use the BI accelerator monitor (see Using the SAP NetWeaver BI Accelerator Monitor).
Activities
Trace for Queries in the Query Monitor

Activation
In the query monitor you can execute and debug queries.
1. Select the query for which you want to record a trace.
2. Choose Execute and Debug . The Debug Options dialog box appears. The options are ordered in a hierarchy.
3. Choose BIA Server BIA Default Trace .
If you set the indicator for the BIA Default Trace , the system automatically activates all the traces listed under this option that log information about the
query that is currently being executed.
You can also choose a single trace type.
Overview of BIA Default Traces
Trace Type Description
BIA Python Trace The BI accelerator index server is traced. The system generates a Python program
that can be executed.
To find out the selections for a query, for example, support can reproduce a query
(without recording the ABAP read interface).
BIA Plan Trace The executor (a component of the BI accelerator) is traced. The system generates a
program that can be executed.
To analyze the steps that the BI accelerator executes (the execution plan), support
can reproduce a query (without recording the ABAP read interface).
BIA ABAP Trace The system records the parameterization of the read interface.
To analyze the problems with the RFC server, for example, support can reproduce a
query on the basis of the BI accelerator indexes (without the InfoCubes).
BIA Standard Trace The system records the trace with particular internal settings (trace levels). The
result is returned in the form of a text file, is linked to the query, and is only valid for
this query. This trace records error messages.
If, for example, a query throws an exception, you can replay the trace to receive
more precise error messages.
Display
If you have activated one of the three trace types, the system displays the trace after the query has been executed. You can edit the trace file and save it
locally.
Runtime problems may arise for large trace files. For this reason, you can also save the trace file without displaying it and editing it.
Performance Trace in the SAP NetWeaver BI Accelerator Monitor

Activation
You can activate a performance trace in the BI accelerator monitor. This logs system responses. SAP support has tools for evaluating these system
responses. The trace is written in save-optimized format (*.tpt).
To activate a trace, choose Performance Trace Start Trace Recording from the menu.
A dialog box appears in which you set:
whether you want to start the trace for a particular user
when you want to stop the trace
For performance reasons, we recommend that you do not choose a time that is too far in the future.
In the status bar, the system shows how long trace recording has left to run (for example,
BI Accelerator Monitor (Trace Recording Still Active 00:10:30) .
If a trace recording is already running, you cannot start a new one.

Stop Trace Recording
To stop a trace that is running, choose Performance Trace Stop Trace Recording from the menu. If you do not stop a trace in this way, the system stops
recording automatically at the time you defined.
You cannot select this menu option if no trace recording is running.
Save Trace File
To save a trace file locally, choose Performance Trace Save Trace File from the menu. When the trace file has been saved successfully, the SAP

system automatically deletes the trace file from the system.
Display Trace Information
To display important key figures for the trace, choose Performance Trace Display Trace Information from the menu. The system displays the following
key figures for the trace:
Start time
Stop time
Remaining time
Users
File size in kilobytes
Delete Trace File
When you save a trace file, it is automatically deleted from the SAP system.
However, if you want to delete a file without saving it, choose Performance Trace Delete Trace File from the menu . The SAP system deletes the trace
file from the system.
This is useful if the trace file has become too large.
Performance Optimization with Aggregates
Purpose
Relational aggregates allow you to improve the performance of BI queries when data is read from an InfoCube. The data of a BI InfoCube is saved in relational
aggregates in an aggregated form. Relational aggregates are useful if you want to improve the performance of one or more specific BI queries, or specifically
improve the performance of reporting on characteristic hierarchies.
In all other cases, if relational aggregates are not sufficient, are too complex, or have other disadvantages, we recommend that you use BI
Accelerator (see Performance Optimization with SAP NetWeaver BI Accelerator).
Integration
Accessing the OLAP Processor

You can use relational aggregates and a BI accelerator index for the same InfoCube. A BI query always tries to use performance-optimized sources by
checking the sources from which it can draw the requested data. It checks the sources in the following order:
1. OLAP cache
2. BI Accelerator index
3. Relational aggregates from the database
4. InfoCubes from the database
If an active BI accelerator index exists, the OLAP processor always accesses this BI accelerator index and not the relational aggregates. Therefore, with
regard to modeling, we recommend that you create either relational aggregates or a BI accelerator index for an InfoCube.
Query Execution
When the query is executed, it is clear to the user whether data is being read from an aggregate, a BI accelerator index, or an InfoCube.
In the maintenance transaction, you can deactivate one or more aggregates on a temporary basis to test them for performance purposes or to analyze data
consistency.
You can also execute the relevant query in the query monitor (transaction RSRT) using a corresponding debug option: Choose Execute + Debug . In the
Debug Options dialog box, choose Do Not Use Aggregates to execute the query with an InfoCube, as long as no BI accelerator index exists.
1.3.2.2.1 Aggregates
Definition
An aggregate is a materialized, aggregated view of the data in an InfoCube. In an aggregate, the dataset of an InfoCube is saved redundantly and persistently
in a consolidated form on the database.
Use
Aggregates allow quick access to InfoCube data during reporting. Similar to database indexes, they serve to improve performance.
Aggregates are particularly useful in the following cases:
Executing and navigating in query data leads to delays if you have a group of queries
You want to speed up the execution and navigation of a specific query
You often use attributes in queries

You want to speed up reporting with characteristic hierarchies by aggregating specific hierarchy levels
Structure
An aggregate is made up of the characteristics and navigation attributes that belong to an InfoCube. Characteristics that are not used in the aggregate are
compressed.
Each component of an aggregate has to be assigned to a selection type. A selection type indicates the degree of detail to which the data in the underlying
InfoCube is aggregated. You can choose one of the following selection types:
All characteristic values ("*"): The data is grouped by all values of the characteristic or navigation attributes (see Selection Type "All Characteristic
Values" (*)sap).
Hierarchy level (H): The data is grouped by the hierarchy level node. You can also store values on the hierarchy levels of an external hierarchy (see
Selection Type "Hierarchy Level" (H)sap).
Fixed value (F): The data is filtered by a single value (see Selection Type "Fixed Value" (F)sap).
You can use both time-dependent attributes and time-dependent hierarchies in aggregates.
Integration
Access to Aggregates During Reporting

If you have created an aggregate for an InfoCube, activated it and entered data for it, the OLAP processor can access these aggregates automatically. For
more information about the order in which the OLAP processor accesses the aggregates, see Performance Optimization with Aggregates. The different results
are consistent when you navigate in the BI query. The aggregate is transparent for the user.
System Response Upon Changes to Data

New data is loaded to an aggregate at a defined time using logical data packages (requests). After this operation (roll up), the new data is available in reporting
(see System Response Upon Changes to Master Data and Hierarchies)
See also:
Performance Tuning for Queries with BI Aggregatesin SAP Service Marketplace on the SAP NetWeaver Business Intelligence performance page.
Selection Type "All Characteristic Values" ('*')

The following examples are based on a simplified InfoCube (sales figures), containing the characteristics COUNTRY and CUSTOMER and the key figure
SALES.
Example InfoCube
COUNTRY CUSTOMER SALES
USA Buggy Soft 10
Germany Ocean Networks 15
USA Funny Duds 5
Austria Ocean Networks 10
Austria Thor Industries 10
Germany Funny Duds 20
USA Buggy Soft 25
Example 1: Aggregate Country '*'

Characteristic COUNTRY is used for grouping
Compressed using characteristic CUSTOMER
COUNTRY SALES
USA 40
Germany 35
Austria 20
The data for key figure SALES is listed for the sum of the sales for each country and not for individual customers.
The aggregate can be used
In a query that determines the sales for each country or the total sales
For evaluations based on a navigation attribute for characteristic COUNTRY or a hierarchy of the countries
You cannot use the aggregate if characteristic CUSTOMER is used for drilldown or is selected in a query because the aggregate does not contain any
information on the customer.

Example 2: Aggregate Industry '*'
In the second example for the selection type All Characteristic Values , INDUSTRY is required as the navigation attribute. We use the following master data
table for this purpose:
Master data table: customer
CUSTOMER INDUSTRY
Buggy Soft Technology
Ocean Networks Technology
Funny Duds Consumer products
Thor Industries Chemical industry
Grouped using navigation attribute INDUSTRY

Compressed using characteristic CUSTOMER
Industry aggregate
INDUSTRY SALES
Technology 60
Consumer products 25
Chemical industry 10
The aggregate can be used

In a query that is used to determine the sales for each industry or the total sales
For evaluations based on node values, if a hierarchy exists for the industries
With the exception of the industry which is assigned to each respective customer, you cannot retrieve detailed information for characteristic CUSTOMER.
Example 3: Aggregate Sales Person '*'

In the third example for the selection type 'All Characteristic Values', the time-dependent navigation attribute SALESPERSON is required. We use the
following table for this purpose:
Sales Person Table
COUNTRY FROM TO SALES PERSON
USA 01.01.2000 31.12.2000 Smith
USA 01.01.2000 31.12.2001 Miller
Germany 01.01.2000 31.03.2001 Meyer
Germany 01.04.2000 31.12.2001 Huber
Austria 01.01.2000 31.12.2001 Huber
Navigation attribute SALES PERSON is used for grouping

Characteristic COUNTRY is used for compressing
Key date: Sept. 01, 2001
SALES PERSON SALES
Miller 40
Huber 55
The aggregate can be used in a query that has the same key date as the aggregate.
Selection Type "Fixed Value" (F)

The following example is based on a simplified InfoCube (sales figures) containing characteristics COUNTRY and CUSTOMER as well as key figure SALES
(see Selection Type "All Characteristic Values" (*)),
Example: Aggregate Country 'F' = DE; Customer '*'

The aggregate only contains data for characteristic value 'Germany'.
Fixed Value: Germany
COUNTRY CUSTOMER SALES
Germany Ocean Networks 15
Germany Funny Duds 20

The aggregate can only be used in queries that have the same filter value.
The aggregate cannot be used if other countries are required in a query.
We recommend that you use filter values for aggregates if only one variant is needed for reporting, for example:
The plan/actual indicator
The current fiscal year
Specific versions
Selection Type "Hierarchy Level" ('H').

The following example is based on:
The simplified InfoCube (sales figures) containing characteristics COUNTRY and CUSTOMER as well as key figure SALES (see Selection Type "All
Characteristic Values" (*))
The following external hierarchy for the countries:
Example: Aggregate Country 'H' Level 2

Characteristic COUNTRY is used for compression on level 2 of the country hierarchy (Europe, America)
The characteristic CUSTOMER is not contained in the aggregate
Hierarchy level 2
COUNTRY SALES
America 40
Europe 55
This aggregate can be used in queries

That require sales for a node of the hierarchy on level 2 or higher, including queries that have the country hierarchy as presentation hierarchy in the
drilldown and are not expanded deeper than level 2
That determine the total sum of the sales if:
- The hierarchy does not have multiple leaves, in other words, each variant of a characteristic occurs only once in the hierarchy
- Node "non-assigned" is not suppressed
The aggregate cannot be used if the third level of the hierarchy (Austria, Germany, USA) is required in a query.
1.3.2.2.2 Create and Change
Use
The following sections explain how you create aggregates and edit them.
If you have not yet created aggregates for an InfoCube but you want to optimize query performance for it, see Creating the First Aggregate for an
InfoCubes.
For more information about manually creating and changing aggregates, see Editing Aggregates Manuallys.
On the Maintenance of Aggregates screen, you can find detailed information about the structure and status of the individual aggregates. See Design and
Components of Aggregatessa.
Tools are available as further editing functions for aggregates to temporarily deactivate or completely delete aggregates that you no longer want to use in
reporting.
If you want the system to propose aggregates, see Automatic Selection and Optimization of Aggregatessap.

Creating the First Aggregate for an InfoCube
Prerequisites
The InfoCube for which you want to create an aggregate has been saved and is active. There are not yet any aggregates for the selected InfoCube.
Note that the following prerequisites have to be filled if you want the system to propose aggregates:
You must have created at least one query for the selected InfoCube or a MultiCube that uses the InfoCube. The system can propose the required
aggregates when you start the queries and navigate in them.
Make sure that you have switched on BI statistics collection for the selected InfoCube in the OLAP area.
Procedure
1. In the context menu for the InfoCube , choose Maintain Aggregate . The Proposals for Aggregates dialog box appears.
2. Specify if you want the system to propose aggregates.
Create proposals The system proposes suitable aggregates.

The Specify Statistics Data Evaluation dialog box appears. Enter the required
data. Choose Continue.
The Maintain Aggregates screen appears . The system displays the proposed
aggregates in the right area of the Aggregates screen.
You can change these proposals by using Drag & Drop to add or remove
dimensions, characteristics or attributes.
Create yourself The Maintain Aggregates screen appears .

For more information see Editing Aggregates Manually.
3. To check the aggregate definition for inconsistencies, choose Check Definition .

4. Save the aggregates.
Result
You can activate the aggregates you have created and fill them with data.
1.3.2.2.2.2 Editing Aggregates Manually
Prerequisites
The InfoCube for which you want to create an aggregate has been saved and is active.
Procedure
How you manually create or change an aggregate for an InfoCube is described below.
1. You are in the Data Warehousing Workbench in the Modeling functional area. In the navigation window, choose InfoProvider and in the InfoProvider
tree, navigate to the InfoCube whose queries you want to optimize.
2. In the context menu of the InfoCube , choose Maintain Aggregates . The Maintain Aggregates screen appears . If an aggregate has already been
created for the selected InfoCube, you can also get to the maintenance screen by double-clicking on .
1. On the Aggregate/BI Accelerator Index: Select InfoCube screen (transaction RSDDV), select the required InfoCube.
2. Choose Aggregates. The Maintain Aggregates screen appears .
If you are creating the first aggregate for an InfoCube, the Proposals for Aggregates dialog box appears first. You can choose whether the
system proposes aggregates or whether you want to create them manually.
For more information, see Creating the First Aggregate for an InfoCube .
3. The left side of the screen shows the dimensions, characteristics and navigation attributes of the selected InfoCube in a tree structure as Selection
Options for Aggregates .
Select one or more objects to be copied to the aggregate.

Define the granularity you require for the data in the aggregate. Add all the characteristics derived from these characteristics.
For example, if you define an aggregate for the month, you should also include the quarter and year in the aggregate.
This enhancement does not enlarge the dataset, but allows:
A year aggregate to be built from this aggregate
Those who need the annual values to use the queries for this aggregate.
You can only include a characteristic and one of its attributes in an aggregate in expert mode ( Extras Switch Expert Mode On/Off ). An
aggregate of this type has the same granularity and size as an aggregate that has only been built using the characteristic, but is affected by
the hierarchy/attribute change run. Compared with the aggregate for the characteristic in which the attribute information is defined by a join with
the master data table, the aggregate for the characteristic and the attribute only saves the database join.
We therefore recommend that you either build an aggregate using the characteristic or you build a much smaller aggregate using the attribute.
4. You have different options for creating an aggregate:
Transfer the selected object(s) to the Aggregates column on the right side of the screen using drag and drop.
Select Create New Aggregate .
The Enter Description for Aggregate dialog box appears.
5. Enter:
Short description
Long description
To change the text at a later time, select Change Description Text in the context menu of the aggregate.
6. Choose Continue . The Maintain Aggregates screen appears.
The system displays the aggregate in the top-right area of the screen. The log is displayed in the lower part of the screen.
For more information, see Design and Components of Aggregates .
7. If an aggregate contains a time-dependent component, you must assign a key date to the aggregate.
When you fill the aggregate, the key date behaves like the key date of a query: The time-dependent attributes and hierarchies are evaluated on
this key date. For this reason, aggregates with a time-dependent component can only be used in a query if the key date of the query is the
same as the key date of the aggregate.
In the Select Variable or Fixed Date dialog box, select the following as the key date:
A variable that is also used in queries for the key date and can be automatically calculated in the SAP Exit or Customer Exit processing types (see
Variables),
0CWD current workday

0DAT current calendar day
0P_KEYDT key date of due date
0P_KEYD2 key date of posting (from key date of due date)
0P_KEYD3 key date of clearing (from key date of due date)
0P_KEYD4 key date of posting (posting date)
0P_KEYD5 key date of clearing (from key date of posting)
Aggregates with a variable key date must be updated regularly. You have to include this process in a process chain ( Further BI Processes ->
Adjust Time-Dependent Aggregates ).
A particular calendar day
To enter a calendar day, select object CALENDAR (<Calendar>) in the Select Variable or Fixed Date dialog box. Choose Transfer
Selection. The Calendar dialog box appears. You can copy this date to the aggregate definition by double-clicking on it.
In the aggregate tree, under Properties for node Variables for Key Date , the system displays the technical name of the variable you chose or the
fixed calendar date.
Once the aggregate has been activated and filled, the system copies the key date computed from the variable for when the aggregate should be filled, into
line Key Date .
8. By default, the system partitions the aggregate fact tables when the related InfoCube is partitioned and the partitioning characteristic is available in the
aggregate. Choose Properties Change Partitioning to prevent partitioning for individual aggregates.
If aggregates do not contain much data, very small partitions can result. This affects read performance. Aggregates with very little data should
not be partitioned. Note that if you change this property to Not Partitioned for an existing aggregate, you have to activate and fill the
aggregate again.
9. You can change the structure of the aggregate by adding additional components or deleting existing ones. You can also change the key date.
Inserting components into the aggregate
i. Select one or more objects in Selection Options for Aggregates .
ii. Use drag and drop to transfer them to the aggregate that you want to change on the right-hand of the screen.
Where necessary, change the selection type (BW-WHM) by choosing the appropriate entry in the context menu:
All characteristic values
Hierarchy level
Fixed value
Aggregates containing fewer than 14 components are stored on the database in optimized form (see Loading Data into Aggregates Efficiently).
Note that the characteristics that are defined in the InfoCube are also included in the aggregate and thus increase the number of components,
even though they are not visible on the interface.
Deleting components from the aggregate
i. In the aggregate tree, navigate to the characteristic(s) or navigation attributes that you want to delete.

ii. Select these components.
iii. To delete the components from the aggregate, you can:
- Choose Remove Components in the context menu.
- Use drag and drop to copy the components to the left part of the screen.
To delete a dimension from an aggregate, you have to delete all the characteristics and navigation attributes of this dimension.
Changing the key date
i. In the aggregate tree under Properties , select the node Variable for Key Date and choose Change in the context menu. The Select Variable
or Fixed Date dialog box appears.
ii. Select and transfer the required variable or calendar day.
The key date computed from a changed variable is only copied to line Key Date if the Adjust Time-Dependent Aggregates process has
been executed.
10. To check the aggregate definition for inconsistencies, choose Check Definition .
11. Save the new or changed aggregate.
Result
You can activate the new or changed aggregate and fill it with data. It is available for reporting.
Design and Components of Aggregates
Definition
On the Maintaining Aggregates screen in the Display of Aggregates and Their Components screen area, the aggregates and their components are displayed
in a logical tree structure.
Use
This screen area is used to:
Define aggregates
Obtain information about the status of individual aggregates
You can define several aggregates for an InfoCube. However, make sure that this is useful:
Advantage: Aggregates improve the performance of queries
Disadvantage: Aggregates increase load time
when uploading data packages
during the hierarchy/attribute change run after loading master data
when modifying time-dependent aggregates.
To optimize an InfoCube, you should repeatedly check:
Whether aggregates are missing: Create new aggregates.
Whether existing aggregates are still being used: Delete unnecessary aggregates.
The aggregates display in the Maintenance for Aggregate screen helps you to evaluate aggregates.
Structure
Column Information
Aggregates Aggregates with all transferred components in a tree display
Technical Name Technical name of the aggregate.
Save Marks new or changed aggregates
Proposed Action The system proposes actions, as required.
Once the system has proposed a new aggregate, it recommends that you activate
this aggregate. This is marked by in this column.
Status Created
Changed (the modified aggregate definition is no longer the same as the active
aggregate definition)
Saved and active
Filled/Switched Off Not filled with data

Filled with data
Individual components in the aggregate (see Selection Type (BW-WHM)): By default, the system aggregates according to the values of the selected objects:
* All characteristic values
H Hierarchy level

F Fixed value
In the context menu of the selection type, you can change this setting.
Hierarchies Name of the hierarchy you have selected, where applicable.
Hierarchy Level Level of the hierarchy you have selected, where applicable.
Fixed Value Fixed value you have selected, where applicable.
Valuation Representation in a bar chart:

The greater the number of minus signs, the worse the evaluation of the
aggregate:
"-----" means: Aggregate can potentially be deleted.
The larger the number of plus signs, the better the evaluation of the
aggregate:
"+++++" means: Aggregate potentially very useful.
The evaluation is based on a number of criteria. The following criteria are currently
used in the evaluation:
How does the compression of the data compare with the InfoCube: How
much smaller is the aggregate compared to the InfoCube?
When was the aggregate last used? (See under Last Used ).
Records Number of records in the filled aggregate.

This provides information about the size of the aggregate.
Records Summarized (Mean Value) Number of records read on average from the source to create a record in the
aggregate.
This example is based on an aggregate with three records. If 10 records are read
for the first record in the aggregate, 15 records are read for the second record
and 20 records are read for the third record, the aggregate has a mean of 15
"compressed records".
This provides information about the quality of the aggregate.
The greater the value, the greater the compression and better the quality
of the aggregate.
Since an aggregate should be 10 times smaller than its source, the number
should be larger than 10.
If the value is one, the aggregate is a copy of the InfoCube. In this case,
consider deleting the aggregate.
Use Number of uses (in queries).
How often is the aggregate used for reporting?
Last Used Date

When was the aggregate last used in reporting?
If an aggregate has not been used for a long time, deactivate or delete it.
Note that certain aggregates cannot be used at certain times (for example during
vacation).
Do not delete basic aggregates that you created to speed up the change run.
Last Roll Up Date

When was data last entered for the aggregate?
Last Roll Up By User name of the person who scheduled roll up.
Last Changed On Date

When was the aggregate definition last changed?
Last Changed By User name of the person who last changed the aggregate.
Integration
Log display
When you have defined the aggregate and filled it with data, the log display is shown in the lower part of the screen.
Status overview of aggregates

There is a status display for all the aggregates in the BI system in the Administration functional area of the Data Warehousing Workbench:
In the navigation pane, under Monitors , choose Aggregates . The Status of the Aggregates screen area lists all the InfoCubes and all the existing
aggregates under each InfoCube.
The structure of this screen area corresponds to the Aggregate screen area of the Maintenance for Aggregate screen. Only the status of the aggregates is
displayed, not their components.
By double-clicking on for a particular aggregate, the Aggregate Display screen appears. The aggregate is displayed here together with its components.
Further Editing Functions for Aggregates
Use

In order to work efficiently with aggregates, you must check the structure and use of the aggregates. You can save time during uploading by either
deactivating or deleting the aggregates that you no longer need for reporting.
Functions
Function Information
Aggregate Tree The Aggregate Tree dialog box appears.

The system shows how the aggregates of an InfoCube lie in relationship to one
another. In other words, which aggregate can be built from which other aggregate.
With the help of the aggregate tree, you can identify similar aggregates and
manually optimize the specific aggregates on this basis.
Choose automatic optimization in the Maintenance for Aggregate screen from
Propose Optimize . For further information about automatic optimization, look
under Automatically Selecting and Optimizing Aggregates).
Switch On/Off You can temporarily switch off an aggregate to check if you need to use it. An
aggregate that is switched off is not used when a query is executed.
To do this select the relevant aggregate and choose Switch On/Off . An
aggregate that is switched off is marked in column Filled/Switched off with .
Since aggregates that are switched off must also be consistent, you do not have to
activate the aggregate again or to fill it when you switch it back on.
Execute a query or trace that would use the aggregate that was switched off.
Compare the time that the database needs with the time that the query needs when
using the aggregate. If the query is not significantly slower without the aggregate,
you can deactivate or delete the aggregate.
You can find more information about evaluating and controlling the use of
aggregates in Displaying Aggregates and their Components.
Deactivate The system deletes all the data and database tables of an aggregate. The definition
of the aggregate is not deleted.
Select the required aggregate and choose Deactivate.
The status display in the columns Status and Filled/switched off change back to
.
If you want to, you can activate and fill the aggregate again later.
Delete The system deactivates the aggregate and deletes the definition of the aggregate.
To do this, select the aggregate to be deleted and select the delete function either
with Delete or from the context menu of the aggregate.
Automatic Selection and Optimization of Aggregates
Use
Data for the BI statistics InfoCube and the created queries can be used as part of the automatic selection and optimizing of aggregates.
In this, the system makes an assessment based on the definition of particularly suitable aggregates. Aggregates that appear to be suitable are proposed
automatically. You can optimize the proposed aggregates and use them for further working with the InfoCube.
Prerequisites
An active version of the InfoCube is available.
Before you can use the query statistics, queries have to exist for the InfoCube.
These must be collected before BI statistical data can be analyzed. In order to collect statistical data, the corresponding function has to be activated for the
InfoCube ( DW Workbench Tools BI Statistics for InfoCubes ) and queries must have already been executed.
Features
You can choose Proposals in the menu if you want the system to propose aggregates. You have the following options:
Proposals from queries: The system considers the queries that are created for an InfoCube.
Proposals from the previous navigation: The system evaluates the last navigational step that you carried out with a query.
Proposals from BI Statistics (tables): The system considers BI statistical data (database tables).
Proposals from BI Statistics (InfoCube): The system considers the data that is contained in the BI Statistics InfoCube.
You can also postprocess the aggregates and add or delete characteristics.
See also:
Proposals from Queries
Proposals from BI Statistics

1.3.2.2.2.5.1 Proposals from Queries
Use
By choosing Proposals Proposals from Queries , you can select existing BI queries for the selected InfoCubes and view proposals for a minimum and
maximum aggregate for each InfoCube. The name of the proposed aggregate is derived from MIN or MAX and a sequential number.
We recommend that you use this function the first time you optimize the InfoCube. If you have already executed queries, use the other
options for optimizing, because the number of times a query has been executed and the individual navigational steps are also taken into
account.
The minimal aggregate MIN corresponds to the smallest aggregate possible. This only contains the data that is needed for the initial drilldown on a query.
The query has to be set to hierarchical reading or reading on demand.

Activating a minimal aggregate accelerates the drilldown defined in the BEx Analyzer.
The maximum aggregate MAX represents an aggregate that supports every navigational step of a query. This is based on the assumption that you want to
perform drilldown for the query using all characteristics (all free characteristics too). Generally this is rarely the case. More frequently, the aim is to be able to
use an aggregate of this type in all possible navigation steps of the query. In any case, check whether it makes sense to use the maximum aggregate. This is
not the case if the volume of data for an aggregate of this type corresponds to the size of the InfoCube.
If the components (the characteristics and attributes of a newly defined aggregate that are not summarized) are identical to an aggregate that has already been
proposed, they will not be added to the list. Instead, the number of calls is increased by one.
Generally the number of calls an aggregate has, the more useful it is: The higher the number of calls for an aggregate, the higher the number of queries in
which it can be used.
You can modify or delete the proposed aggregates.
See also:
Proposals from BI Statistics
Optimizing Proposed Aggregates
1.3.2.2.2.5.2 Proposals from BI Statistics
Use
If you have activated the collection option for query runtime statistical data, every navigational step that requests data from the database is saved. This
includes the characteristics, navigation attributes and hierarchies that are involved. First the system saves this statistical data in database tables. You can
then load this data into BI statistics for evaluation purposes.
You can also use this statistical data for optimizing aggregates. The advantage of having proposals from BI statistics as opposed to proposals from BI queries
is that the actual user capacity is taken into account here.
We recommend that you use this function if representative statistical data already exists. You run this function at regular intervals to modify
the aggregates in accordance with changes to user actions.
You can evaluate the data saved in BI Statistics (database) or BI Statistics (InfoCube) by selecting the menu path Proposals Proposals from BI
Statistics (Tables) or Proposals from BI Statistics (InfoCube) . You can restrict the analysis to a subset of the data by specifying an interval for the start time
or runtime of the query.
After the data has been read from BI Statistics, the optimal aggregate is determined for every navigation step, and a list of the different aggregates is created.
For aggregates in a component that vary only in terms of their selection type, all aggregates with the selection type hierarchy (H) or fixed
value (F) are replaced with an aggregate that is grouped by characteristic values (*). This is possible as long as the aggregate has already
been proposed.
The list of proposed aggregates has the same structure as the proposals from BI queries. However, the list is generally longer.
You can modify or delete the proposed aggregates.
See also:
Proposals from Queries
Optimizing Proposed Aggregates

1.3.2.2.2.5.3 Optimizing Proposed Aggregates
Use
If the analysis of BI queries or BI statistics has proposed several aggregates, it is not advisable to activate all of them. Using aggregates reduces the runtimes
of queries and the roll up of data is optimized in such a way that allows aggregates that are already rolled up and available to be used. But, as a rule, the total
memory space required for all aggregates is too great and it takes too long to fill the aggregates.
In addition to the runtime for the queries, a complete optimization must also take into account the dependencies of the aggregates, their memory requirements,
the time taken to roll up new data, and other factors.
Activities
You can run a simplified optimization by choosing Proposal Optimize.
For this optimization it is usually assumed (heuristics), that the number of aggregates should be reduced first. In addition, those aggregates are selected that
have been called up least often and together account for 20% of all calls. These aggregates are checked, one after the other, to see if there are any
aggregates with exactly one extra component.
If the system finds more than one aggregate with exactly one additional component, it chooses the aggregate that has been called the most number of times.
The calls for the aggregates that have been checked are added to this number. The checked aggregate (from the 20% quantity) is then deleted from the list of
proposed aggregates.
However, this only happens if the number of calls for the checked aggregate is not more than double the calls for the aggregate with the extra
components. This prevents aggregates from being replaced by others that are used relatively rarely.
You can continue to optimize until the point where the aggregate is small enough, or until no more aggregates can be compressed.
Since the optimizer has no information about the data structure, you should check the proposals again before filling aggregates with data. For
example, a proposed aggregate may contain a characteristic that would make the aggregate almost the same size as the InfoCube. This would
mean that when the aggregate is filled, the system virtually creates a copy of the InfoCube. This is not generally the objective when using
aggregates.
See also:
(See System Response Upon Changes to Master Data and Hierarchies)
Activation and Provision of Data
Use
The following sections explain how you activate aggregates and fill them with data.
If you have created or changed an aggregate, you have to activate it and fill it with data before you can use it when you execute a query. See Activating
and Filling Aggregatess.
If you have loaded new data packages (requests) to the InfoCube, you have to roll up these data packages into aggregates before the current data is
available for reporting on the aggregate. See Rolling Up Data in Aggregatessap.
If the hierarchies and attributes of characteristics that belong to an InfoCube have been changed, you have to make structural changes to the aggregates
to modify the data accordingly. See System Response Upon Changes to Master Data and Hierarchiessa.
You can make the data load more efficient both when initially filling the aggregate and during roll up. See Loading Data into Aggregates Efficientlysap.
1.3.2.2.3.1 Activating and Filling Aggregates
Use
To use an aggregate for an InfoCube when executing a query, you must first activate it and then
fill it with data.
Prerequisites

You have created or changed an aggregate.
Procedure
Select the aggregate that you want to activate and fill.
Choose Activate and Fill . The system creates an active version of the aggregate.
System Activity Result
The system creates the tables required by the aggregate definition in the If the aggregate was activated successfully, the status display in the Status
database. Aggregates are created according to the same schema as column changes from for a newly create aggregate or for a changed
InfoCubes. aggregate to .
An aggregate contains two fact tables and a number of dimension
tables.
The table names are derived from the technical names of the
aggregates.
3. Once the aggregate was activated, you must trigger the action to fill the aggregate with data. The Subsequently Aggregate the Aggregates of an
InfoCube dialog box appears.
4. An active aggregate is selected and marked in the Active/Inactive column with an .
If you do not want to fill an aggregate, you can deselect it.

5. Select Fill aggregate . The Execution Time of Aggregation dialog box appears.
Since it can take a long time to build an aggregate from an InfoCube, all the aggregates are filled in the background.
Note that an aggregate can also read data from a larger aggregate that is already filled. You can therefore assign data to very compressed
aggregates quickly.
6. Define when you want to start the job to fill the aggregate:
now
later
This takes you to the Time of Subsequent Aggregation dialog box. Enter the date and time for the background processing.
7. In the Subsequently Aggregate the Aggregates of an InfoCube dialog box, choose Refresh. The system copies the relevant data to the columns
User who scheduled the aggregate for building,

Date for scheduling the new version of the aggregate
Time for scheduling the new version of the aggregate
Name of the background job
In the column Job Status you have the following display options:
shows that the job of filling the aggregate is currently running.
shows that the job of filling the aggregate is scheduled, but is not running yet.
shows that the job of filling the aggregate was canceled.
To find out about your background jobs for filling aggregates, choose Jobs . You get to the Simple Job Selection screen.
To view the logs for filling your aggregates, choose Log . The Evaluate Application Log dialog box appears.
By using the transaction SLG1, you can directly access the application log even if the job is not canceled. The Evaluate Application Log
dialog box appears.
Enter the required data in the following fields:
Field labels Entry
Object RSSM
(Scheduler; Monitor; Tree Callback)
Subobject MON
(Monitor)
Ext. Identif. For displaying all logs:

(External Identification) * InfoCube *
For filling new aggregates:
MON:PROTOCOLL_ACTION-AGGR2- InfoCube
(For rolling up already existing aggregates:
MON:PROTOCOLL_ACTION-AGGR1- InfoCube )
Instead of entering InfoCube , enter the technical name of the desired
InfoCube.
8. Choose .
System Activity Result

The system reports all the executed actions in the lower right part of the log If the aggregate was filled successfully, the status display in the column
display. Filled/Switched off, changes from to .
If you used a variable for the key date in an aggregate with time-dependent
attributes or hierarchies, the system evaluates this variable when it fills it and
builds the aggregate on the computed key date.
To activate and fill a number of aggregates at the same time, select them and choose Activate and fill .
The system chooses the optimum sequence for filling the aggregates.
1. The large, detailed aggregates are filled first.

2. The smaller, very compressed aggregates are filled next.
The larger aggregates can therefore be used already when you are still building the smaller ones.
Result
The active aggregate that is filled with data can be used for reporting. If the aggregate contains data that is to be evaluated by a query, the query data is read
automatically from the aggregate.
You can find more information about the number of records read and the use of an aggregate in queries in
Displaying Aggregates and their Components.
You can roll up new data packages (requests) into the aggregate. For more information see
Rolling up Data into an Aggregate.
1.3.2.2.3.2 Rolling up Data into an Aggregate
Use
When you load new data packages (requests) into the InfoCube, these are not immediately available in reporting for use in an aggregate. To fill the aggregate
with the new data from the InfoCube, you first have to load the data into the aggregate tables for a set time frame. This process is known as rolling up.
Prerequisites
New data packages (requests) have been loaded into an InfoCube.
Aggregates for this InfoCube have been activated and filled with data.
Procedure
In InfoCube maintenance, you can specify how the data packages are rolled up in the aggregate. You can do this on an InfoCube-by-InfoCube basis.
You are in the Data Warehousing Workbench in the Modeling functional area. In the context menu of the required InfoCube, choose Manage .
The system copies the InfoCube data into the table at the top of the screen.
To optimize data load performance, you can specify that you want to automatically delete indexes before the load operation and recreate them
when the data load is complete. You do this on the Performance tab page. Building indexes in this way accelerates the data load process, but
has a negative impact on system performance when the data is read. Only use this method if no read process takes place while the data is
being loaded.
If you want to switch on index building during roll up anyway, choose Create Index (Batch) and select the required options: Delete InfoCube
Indexes Before Each Data Load and then Refresh or Also Delete and then Refresh Indexes with Each Delta Upload .
Type of Execution Procedure
Include roll-up of the data packages as a process in a process chain 1. Choose the Roll Up tab page.
We recommend use in a process chain The system recommends the highest possible value for Rollup to Request ID .
with complex schedules You can overwrite this if you need to.
where there are difficulties with automations and event collectors 2. Choose Process Chain Maintenance .
for all new development
Call transaction RSPC. This opens the Process Chain Selection dialog box.
This provides an overview of the various process chains in the BW system.
If you cannot find any suitable process chains, you can create a new process
chain for the roll up.
For more information, see Creating Process Chains in Creating Process
Chains by Using a Maintenance Dialog for a Process.
Start data package roll up manually 1. Choose the Roll Up tab page.
2. Choose Selection . The Start Time dialog box appears.
3. Select the start date. You have the following options:
Use this procedure in particular if data from several data packages creates a

Use this procedure in particular if data from several data packages creates a - Immediately
logical unit, and therefore should to be released together. - Date/time
- After job
- After event
Different plants deliver their data at different points in time. The data only needs - In operation mode
to be visible in the InfoCube when all plants have loaded their data into the
4. If you want to run the job periodically, set the corresponding flag .
InfoCube.
The following procedures are also possible but should not be used for new scenarios.
Type of Execution Procedure
Postprocessing 1. Choose the Roll Up tab page.

2. Choose Postprocessing . The Maintain Events to Run After Processing
dialog box appears.
Roll up each data package in the aggregate automatically 1. On the Manage Data Targets screen choose Environment ->
Automatic Request Processing . The Automatism Maintenance dialog
box appears.
The InfoCube must be technically correct and you must be sure of its quality. 2. Under Automatic Processing , set the Roll Up Data into the Aggregate
flag.
Only use automatic roll-up if you load requests into the InfoCube in such a way
that there is no time overlap for the load process, the roll-up and other
automatisms in the InfoCube.
For more information, see Automatic Further Processing.
Program RSDDK_AGGREGATES_ROLLUP You can also run roll up using program RSDDK_AGGREGATES_ROLLUP (see
Direct Execution - Reports).
You can schedule this program as a regular background job or use it in an Event
Collector.
Result
The new data is available in reporting for queries started after the roll up.
See also:
Managing InfoCubes
System Response to Changes to Master Data and Hierarchies
Use
If the hierarchies and attributes of characteristics that belong to an InfoCube have been changed, you have to make structural changes to the aggregates to
modify the data accordingly.
Note that with a structural change, all aggregates of all InfoCubes are modified if they are affected by the changes to the hierarchies and
InfoObjects. This may take some time.
You can still report on the old hierarchies and attributes during the change run.
Integration
If the changes affect an amount of data that exceeds a certain threshold value, modifying the aggregate is more time consuming than reconstructing it. You
can change this threshold value. In the Implementation Guide (IMG), choose SAP NetWeaver Business Intelligence Performance Settings
Parameters for Aggregates in the section Percentage Change in the Delta Process . In the Limit with Delta field, enter the required percentage (a number
between 0 and 99). 0 means that the aggregate is always reconstructed. Keep changing these parameters until the system response is as quick as possible.
Features
If an aggregate is affected by changes to the data, it is either modified (in a delta process) or reconstructed. When you modify an aggregate, the obsolete data
records are posted negatively and the new data records are posted positively.
You can modify aggregates manually or automatically using a program.
You can start multiple change runs simultaneously. The prerequisite for this is that the lists of master data and hierarchies to be activated are different, and
that the changes affect different InfoCubes. If a change run terminates, you have to start the same change run again. You do this by starting the change run
again with the same parameters (same list of characteristics and hierarchies).
Activities
Manual Modification
1. In the Data Warehousing Workbench menu, select Tools Hierarchy/Attribute Changes . (Alternatively, in the Data Warehousing Workbench, in the
Administration functional area, choose Change Run ). The Execute Hierarchy/Attribute Changes for Reporting screen appears. On this screen, all the
executed change runs are listed with detailed information. Even if the application logs for change runs have been deleted, the change runs will still be
displayed in the history. All the InfoObjects and hierarchies that are scheduled for the structural change are selected by default.
2. If you only want to carry out the structural changes for individual InfoObjects and hierarchies, select the InfoObject List or Hierarchy List pushbutton.

Remove from the list the InfoObjects and hierarchies that you do not want to change.
3. Schedule a new structural change by choosing Selection and specifying the start date. The status of the structural change is displayed in the upper
section of the screen.
Automatic Modification
To schedule the same function when executing a report directly, enter the program name RSDDS_AGGREGATES_MAINTAIN.
You can also include the program in a process chain and schedule it regularly in background processing.
The attributes for characteristic 0MATERIAL are uploaded weekly. You can schedule the program so that it starts after the upload. You can
also use the InfoObject list 0MATERIAL as a variant so that only changes that are made to the material attributes are taken into account.
Other changes, which may only be needed later, are ignored.
Choose Log to display the messages for the hierarchies and attributes that have been changed manually or automatically.
Status Overview of Change Run

In the Administration functional area in Data Warehousing Workbench, a status display is displayed for all executed change runs in the BI system. In the
navigation window, choose Monitors Change Run. The Monitor for the Change Run screen appears.
Using choose Change Run . A dialog box for selecting a run ID appears.
When you choose Logs , a dialog box for selecting a process type appears. Choose Change Run. The screen for displaying the relevant log in the
application log appears.
Loading Data into Aggregates Efficiently
Setting Automatic Compression

For each InfoCube, you can set whether the aggregates of the InfoCube are compressed automatically when it is filled with data or after the roll up of data
packages (requests).
1. You are in the Data Warehousing Workbench in the Modeling functional area. In the InfoProvider tree, navigate to the required InfoCube.
2. In the context menu of the InfoCube, choose Manage .
3. In the lower part of the screen, select the Roll Up tab page.
4. Under the Aggregates group header, set the corresponding indicator in the Compress After Roll Up field.
Alternatively you can set automatic compression after roll up. This is described below:
You are in the Data Warehousing Workbench in the Modeling area. In the context menu of the required InfoCube, choose Display or
Change . Choose Environment InfoProvider Properties Display or Change . On the Roll Up tab page, choose option Compress
After Roll Up .
Indicator Information
Set (default): The aggregates of an InfoCube are compressed automatically when the
Automatic compression switched on InfoCube is filled with data or after the roll up of data packages (requests).
If you want to delete a data package (request) from the InfoCube and the
InfoCube has already been rolled up to the aggregate, you have to deactivate the
aggregate and build it again.
Not set: The aggregates are only compressed with the InfoCube.
Automatic compression switched off Use this setting if you have to frequently delete requests from the InfoCube. A
specific request can be deleted from the aggregates when it has been deleted
from the InfoCube.
Note the possible affects on performance; aggregates can become quite large if
they are not compressed automatically.
Reading the Data in Blocks

If the amount of data is very large when you fill the InfoCube, the system reads the data in blocks and not all at one time. This avoids problems with temporary
table space on the database which may occur if you have very large sources (InfoCubes or aggregates).
For more information about the block size settings, see Customizing under SAP Customizing Implementation Guide SAP NetWeaver Business
Intelligence Performance Settings Parameters for Aggregates .
Optimizing Performance of Aggregates with Fewer Characteristics

Aggregates with fewer than 14 characteristics are created for all databases in such a way that each characteristic is in a separate dimension (artificial) and
these dimensions are created as line item dimensions. Aggregates that only consist of line item dimensions are filled purely from the database. This improves
the performance when filling and rolling up.
The logical tree display in the right part of the Maintenance for Aggregate screen is copied from the left part of the Selection Options for Aggregates screen
but does not mirror this special form of storage on the database.

Optimizing Data Load Performance
To optimize data load performance, you can specify that you want to automatically delete indexes before the load operation and recreate them when the data
load is complete. Building indexes in this way accelerates the data load process, although it has a negative impact on system performance when the data is
read. Only use this method if no read process takes place during the data load.
If you want to switch on index building during roll up anyway, you have the following options:
You are in the Data Warehousing Workbench in the Modeling area. In the context menu of the required InfoCube, choose Display or Change . Choose
Environment InfoProvider Properties Display or Change. On the Database Performance tab page, chose options Delete index before each
data load and then recreate or Delete index before each data load and then recreate .
You are in the Data Warehousing Workbench in the Modeling area. In the context menu of the required InfoCube, choose Manage . On the
Performance tab page, choose the option Create Index (Batch) and select the required options: Delete InfoCube Indexes Before Each Data Load and
then Refresh or Also Delete and then Refresh Indexes with Each Delta Upload .
Parallel Execution of Processes for More Than One Aggregate

In BI Background Management (transaction RSBATCH), you can specify that the following processes are executed in parallel. These processes all serve to
process aggregates. Parallel processing is applied to the aggregates in any number of InfoCubes.
Process types for parallelization
Process Type Description
AGGRFILL Initial filling of aggregates
ATTRIBCHAN Attribute change run
CHECKAGGR Check aggregates during roll up
CONDAGGR Compress aggregates
ROLLUP Roll up
For roll up you can also make these settings in the InfoCube:
You are in the Data Warehousing Workbench in the Modeling area. In the context menu of the required InfoCube, choose Manage . On the
Roll Up tab page, choose Parallel Processing . A dialog box appears in which you can define settings for parallel processing.
For the change run, you can also make the settings in the Administration functional area of the Data Warehousing Workbench. Go to
Change Run : Under the group header Executing Change Runs , choose Parallel Processing . A dialog box appears in which you can
define settings for parallel processing.
By default, the system executes a maximum of three parallel processes. You can change this setting ( Number of Processes ) for each individual process
type. In process chains, the affected setting can be overridden for each of the processes listed above.
Note that fill, roll up and change run each consist of several subprocesses, all of which are processed in parallel.
For example, roll up consists of the following subprocesses:

Roll up data into an aggregate
Compress, as required
Check, as required
The parallel processing settings for the subjobs correspond to the parallel processing settings for the main job. For example, if you decide that
you want to perform roll up in five parallel processes and compression in two, the system executes the compress subprocess of the roll up in
five parallel processes.
If you do not want the system to respond in this way, you can set parameters for the InfoCube so that the system does not automatically
compress the aggregate (see section Setting Automatic Compression above). In addition, you can add the Compress Aggregate process as
a subsequent process to the Roll Up process in a process chain. In this case, the system applies the compression settings that you set in
the BI Background Management transaction (transaction RSBATCH). In the example above, the system executes roll up in five parallel
processes and compression in two.
The parallel processes are executed in the background, even if the main process is executed in the dialog. This can considerably decrease execution time for
these processes. You can determine the degree of parallelization and specify the server on which the processes are to run and with which priority (job
category). Job category A has the highest priority, followed by category B and finally C.
Note that if you choose more than two parallel processes ( Number of Processes ), one process monitors the other processes and divides the
work packages. You always have one process less in actual usage than the number of processes selected in the settings.
1.3.2.2.4 Performing Checks for Aggregates
Use
You perform aggregate checks to check the correctness of the data records in an aggregate. You can define as many aggregate checks as you require for
each InfoCube. You can check the required aggregates in different check modes at any time.

You can use check aggregates or strict characteristic restrictions to run quick aggregate checks on a daily basis after roll up and, in addition,
schedule a complete check of critical aggregates at the weekend. Or you can run checks on a weekly basis after weekly change runs.
You can view the results of the check in the logs in the application log. If the system finds incorrect records, it saves these incorrect records in a new
database table (/BI0/01xxxxxx). You can see the name and size of the table in the log messages.
You cannot transport aggregate checks because the number, type and size of the aggregates in the test and productive systems are normally
different. For this reason, you need to create individual aggregate checks in each relevant system. You can create analogous checks with
identical check IDs in the different systems.
Procedure
You access aggregate check maintenance either from aggregate maintenance (transaction TSDDV) in the Maintaining Aggregates screen (choose Extras
Automatic Check (On/Off/Change) ), or from transaction RSDDAGGRCHECK. The Maintain Aggregate Check: Select InfoCube screen appears.
Selecting Checks
Each check is specified by the InfoCube name and an ID.
1. Enter the name of the InfoCube.
2. Enter a valid check ID:
If you want to display, exit, execute or delete a check that already exists, enter the corresponding check ID. Input help is available for both the
InfoCube name and the check ID.
If you want to create a new check, provide an (unused) check ID. If you leave the field empty, the system automatically generates a new check ID.
Editing Checks
You can create, change, execute, execute ad hoc or delete aggregate checks for an InfoCube.
The following functions are available:
Editing Function Description
Display The Display of Check Time for the Aggregate screen appears. The system
displays the aggregate tree of selected aggregates with their check modes and
check times. If characteristic restrictions have been defined for the check for one or
more aggregates, these are displayed subsequently in a dialog box. Choose
confirm to close the display.
Edit The Check-Time Selection for Individual Aggregate screen appears. The system
displays the description of the check with the check mode settings, check time, and
characteristic relationships. You can change these properties here. If you save the
check, the previous settings are overwritten.
Create The Check-Time Selection for Individual Aggregate screen appears. The system
displays the aggregate tree with all the aggregates in the InfoCube.
1. Select the aggregates that you want to check.
2. Determine the check time by setting the corresponding indicator.
3. In the context menu of the aggregates to be checked, choose the check
mode. The system displays the selected check mode in the
corresponding column.
If you choose the Selection Options check mode, the Characteristic
Restrictions When Checking Aggregates screen appears. Enter the
restrictions and choose Continue .
4. Choose Continue .
The system checks whether new aggregates have to be created or whether
check aggregates exist that are no longer needed because the aggregates
have been deleted. The Confirmation of Aggregate Check screen appears .
The corresponding information is displayed in the Check Overview area.
5. Enter the following general check parameters:
Description/texts ( short description , long description ) for the check.
Block size for check: This value is not the block size that is observed when
building aggregates but the mechanism behaves in the same way: It ensures
that the system can also check large aggregates, without this causing
problems regarding temporary table space.
6. Save the check.
If check aggregates need to be created for this check, the corresponding
aggregates and tables are created and activated first. The dialog box for filling
check aggregates appears (see Activating and Filling Aggregates). Schedule a job
for filling the aggregate.
If you have Schedule as the check time in the check aggregate, the dialog box for
scheduling in background processing appears. Here you can enter the time(s) or
choose Cancel if you have only created the check for ad hoc purposes.
The system does not check an aggregate unless all the check aggregates that
this check requires are filled when the check starts.
If you have selected aggregates with check time Now , the system executes this
part of the check in dialog mode and displays the results afterwards in the
application log.

The settings for aggregates with check time Now are not transferred to the
definition of the aggregate check.
Delete If you confirm the confirmation prompt, the check is deleted.
Execute The check you have chosen is executed in dialog mode. The system displays the
results in the application log.
Ad hoc The Check-Time Selection for Individual Aggregate screen appears.

1. Select the aggregates that you want to check.
2. Choose Now as the check time.
3. In the context menu of the aggregates to be checked, choose the check
mode. You can only select the Check Aggregate check mode if a
corresponding check aggregate already exists.
Choose confirm again and the system executes the check you have selected in the
dialog.
Evaluating Logs
If the check is executed After Change Run , After Roll Up or After Deletion , you can find the logs for the aggregate check with the logs for the main
process.
If you execute an ad hoc check or execute a check using Now , the system displays the application log automatically at the end of the check.
If the check is scheduled for background processing and is executed in the background, the logs are available in the application log under object RSRV,
subobject AGGRCHECK. The InfoCube name and check ID are recorded in the identifier.
You can also display these logs by choosing Logs on the Maintain Aggregate Check: Select InfoCube screen.
For more information, see:

Check Time
Check Mode
Technical Information About Aggregate Check
1.3.2.2.4.1 Check Time
Definition
The check time is the time at which an aggregate is checked. Users determine check times.
Use
You can determine the check time in the following ways:
Check Time Description
After Change Run The aggregates are checked immediately after the change run. The system only
checks aggregates if they have been modified in previous change runs and
switches on the check for these aggregates.
After Roll Up The aggregates are checked immediately after the data from the InfoCube has been
rolled up. The system only checks those aggregates for which the check is switched
on.
After (Request) Deletion See After Roll Up .
Schedule You specify that you want to execute the check at a particular time or periodically in
background processing.
If you want to execute a particular check frequently but not on a regular basis,
choose the Schedule check time when you create the check. Save the check. If
you cancel the scheduling you can execute the check at any time using program
RSDDK_CHECK_AGGREGATE_CHECKID in the dialog or in background
processing (see section As Part of a Process Chain below).
Now The check is started immediately as a dialog process. Aggregates that are checked
with check time Now are not included in the definition of an aggregate check and
are not saved.
As Part of a Process Chain

You can also define a check in transaction RSDDAGGRCHECK and integrate this check into a process chain. To do this, you have to include program
RSDDK_CHECK_AGGREGATE_CHECKID in the process chain with the corresponding check ID and the name of the InfoCube. The system checks all
aggregates that have been selected with check time Schedule .

Aggregate checks cannot be transported. If you have included a check in a process chain and you transport this process chain, there is the
possibility that an incorrect check may be executed. In different systems, create checks that correspond to one another with identical check
IDs.
1.3.2.2.4.2 Check Mode
Definition
The check mode determines how an aggregate is checked.
Use
You have the following options for checking the aggregates of an InfoCube. The following table provides an overview.
Check Mode Description
Full For the full check, the system builds the aggregate again from the InfoCube as an
internal table and compares it with the data of the aggregate in the database, record
by record. This check can take a lot of time, but it offers the highest level of security.
Selection Options For the restricted check, you can set restrictions for characteristics on the
Characteristic Restrictions When Checking Aggregates screen. You can only
select those characteristics that exist in the aggregate and do not have hierarchies
or fixed value restrictions defined for them. The system runs the check in the same
way as it runs the full check, but only for InfoCube or aggregate data that meets the
defined restrictions. Depending on how strict the restrictions are, this check can be
considerably quicker than the full check.
This type of check is particularly useful in the following case: If the data in the
aggregate only changes in a particular time frame, you can restrict the dataset
considerably by restricting the check to this time frame.
Aggregated For the aggregated check, the system aggregates all the characteristics in the
InfoCube and aggregate and compares the result of each key figure. This check is
3-4 times quicker than the full check but does not provide the same level of security.
You cannot perform this check for the following aggregates:
Aggregates of non-cumulative InfoCubes
Aggregates with fixed values
Aggregates with a hierarchy that is not unique or a hierarchy that does not
have non assigned nodes.
Check Aggregate For the check with check aggregates, the system creates a check aggregate that is
aggregated using all characteristics. A check aggregate of this type is created for
each fixed value combination that occurs in the aggregates you have selected. The
check aggregates are filled from the InfoCube and are always modified during roll
up or deletion. The check checks that the key figure totals agree. This check is very
quick, but it cannot find every potential inconsistency in the aggregates.
You cannot create check aggregates for the following aggregates:
Aggregates of non-cumulative InfoCubes
Aggregates with fixed values for a navigation attribute
Aggregates with a hierarchy that is not unique or a hierarchy that does not
have non assigned nodes.
1.3.2.2.4.3 Technical Information

The technical information for the aggregate checks is stored in tables RSDDAGGRCHECKDIR, RSDDAGGRCHECKSEL and RSDDAGGRCHECKT.
Class CL_RSDDK_AGGR_AUTOCHECK and function group RSDDK2_CHECK contain the program source code.
The following programs are available for checking aggregates:
RSDDK_CHECK_AGGREGATE checks as many aggregates as required and also checks aggregates from different InfoCubes in modes A ( All ), Q
( Aggregated ) and C ( Check Aggregate )
RSDDK_CHECK_AGGREGATE_SELOPT serves to enter characteristic restrictions and the subsequent aggregate check.
RSDDK_CHECK_AGGREGATE_CHECKID executes specific checks that have been defined in transaction RSDDAGGCHECK.
1.3.2.3 Non-Cumulatives
Use

A non-cumulative is a non-aggregating key figure on the level of one or more objects, which is always displayed in relation to time. Examples of non-
cumulatives include headcount, account balance and material inventory.
How you model the folder for non-cumulatives in the BI system depends on your scenario. Depending on how often non-cumulatives change, and the total
number of objects for which you want to calculate non-cumulatives, you should choose one of the following two options:
Non-Cumulative Management with Non-Cumulative Key Figures:

If the non-cumulatives change infrequently, you should choose non-cumulative management with non-cumulative key figures.
If you use non-cumulative key figures, an absolute non-cumulative value (the marker) and all non-cumulative value changes are saved in the fact table of the
InfoCube. In this way, the retention and volume of data in the data loading process is optimized. A data record is then only loaded into the InfoCube if a non-
cumulative changes because of a transaction. Non-cumulatives can then be evaluated at any time in queries, using non-cumulative key figures.
The fact table for the InfoCube with non-cumulative key figures looks something like this (simplified):
Period Material Delta
2003001 AAA 1400
2003001 AAA 100
2003002 AAA -150
2003003 AAA -50
2003004 AAA 400
2003006 AAA -300
2003009 AAA 1400
The fact table contains the transaction data. The first record in the table is the initialization. This entry does not remain physically in the table, but it is
available for rebuilding the non-cumulatives.
The last record in this case is the marker (the InfoCube was compressed after this request). The non-cumulative for the period 2003005 is calculated as
follows: 1400 (-300) = 1700. This calculation takes place during the runtime of the query. Non-cumulatives can be displayed with this for time periods for
which transaction data has not been loaded.
The use of non-cumulative key figures is recommended when the amount of transaction data is 20 % less than the granularity of the InfoCube.
Advantages of this Solution:
The fact table is kept smaller.
The history remains.
Disadvantages of this Solution:
More administrative effort is required (for example, the InfoCube has to be compressed more often to keep the marker current).
The query runtime can be affected by the calculation of the non-cumulative.
Deletion of transaction data for material that is no longer current is not possible because deletion cannot be restricted by time.
See also Modeling of Non-Cumulatives with Non-Cumulative Key Figures.
Non-Cumulative Management with Normal Key Figures (Cumulative Key Figures):

If the non-cumulatives change frequently, you should choose non-cumulative management with normal key figures. That is, choose cumulative values.
Absolute non-cumulatives are then retained in InfoCubes for all objects for particular key dates (for example, the end of the month). These absolute non-
cumulatives can be determined from a DataStore object that is provided with non-cumulative value changes on an ongoing basis.
In this case, non-cumulative calculation takes place at query runtime. The marker is refreshed as a result of compression within the administration of an
InfoCube with non-cumulative key figures.
The fact table for the InfoCube with normal key figures looks something like this (simplified):
Period Material (Delta) Non-Cumulative Value
2003001 AAA (100) 1500
2003002 AAA (-150) 1350
2003003 AAA (-50) 1300
2003004 AAA (400) 1700
2003005 AAA (-) 1700
2003006 AAA (-300) 1400
The fact table contains the non-cumulative values, but no delta (this is here only to make it easier to understand). The non-cumulative value for a specific
period can be determined using a key figure with an exception aggregation over the period.
The values for the key figures are saved in the granularity of the InfoCube. If the amount of transaction data is almost the same as the number of the most
granular InfoObjects (for example, week multiplied by material) then using normal key figures is recommended.
Advantages of this Solution:
The query runtime is not affected by the calculation of the non-cumulative.
The deletion of transaction data for material that is no longer current is possible and easy.
Disadvantages of this Solution:
The fact table becomes larger than it is when using non-cumulative key figures.
In order to properly update postings in the future and the past, the data first has to be loaded into a DataStore object and then into the InfoCube.
"How to..." Paper for Inventory Management Scenarios in BI

SAP provides a document that deals extensively with the technical features of non-cumulative management in BI.

To display this document in SAP Developer Network (SDN), under https://www.sdn.sap.com/irj/sdn/howtoguides choose SAP NetWeaver 2004 Business
Intelligence How to Handle Inventory Management Scenarios.
Modeling Non-Cumulatives with Non-Cumulative Key Figures
Use
A non-cumulative key figure is modeled in BI using the corresponding field for the non-cumulative value change or the corresponding fields for inflows or
outflows in the InfoObject maintenance. You can determine the current non-cumulative or the non-cumulative at a particular point in time. To do so, you use
the current, end non-cumulative and the non-cumulative changes and/or the inflows and outflows.
The aim of the special folder for non-cumulative key figures is to optimize the data transport into the BI system, to retain data, and to access the database
when evaluating for reports in the BI system.
Whether the modeling of non-cumulatives with non-cumulative key figures is useful depends on your scenario. It is recommended that you use non-cumulative
key figures for areas in which non-cumulatives do not regularly change completely, for example with warehouse stock (retail) or with the number of employees.
For more information, see the detailed comparison in Non-Cumulatives.
Structure
Model of Non-Cumulative Key Figures

A non-cumulative InfoCube is modeled with at least one non-cumulative key figure. These non-cumulative key figures are mapped using one key figure for
non-cumulative changes or two key figures for inflows and outflows. Which option you choose depends on how you want to evaluate the non-cumulative key
figure.
The key figures for non-cumulative value change or for inflows and outflows are normal cumulative key figures that have summation both as aggregation and
exception aggregation. Non-cumulative key figures always have summation as standard aggregation (aggregational behavior on the database, for example,
upon compression or roll-up of aggregates). However, with reference to a time characteristic, they have an exception aggregation (in reporting) that is not equal
to summation, as it would not make sense to cumulate non-cumulatives by time.
Non-cumulative key figures such as Number of Employees are cumulated using characteristics such as Cost Center . However, it is not
meaningful to total the number of employees using different periods. Using the period, for example, you can map the average.
With the cumulative value Sales Revenue , for example, it makes sense to cumulate the individual sales revenues using different periods, and
using characteristics such as Products and Customers .
Example of the difference between non-cumulative and cumulative key figures:
Sales volume (cumulative value):
Sales volume 01/20 + sales volume 01/21 + sales volume 01/22 gives the total sales volume for these three days.
Warehouse stock (non-cumulative key figure):
Stock 01/20 + stock 01/21 + stock 01/23 does not give the total stock for these three days.
Technically, non-cumulatives are stored using a marker for the current time (current non-cumulative) and the storage of non-cumulative changes, or inflows
and outflows. The current, valid end non-cumulative (to 12/31/9999) is stored in the marker. You can determine the current non-cumulative or the non-
cumulative at a particular point in time. To do so, you use the current, end non-cumulative and the non-cumulative changes and/or the inflows and outflows.
Queries for the current non-cumulative can be answered very quickly, since the current non-cumulative is created as a directly accessible value. There is only
one marker for each combination of characteristic values that is always updated when the non-cumulative InfoCube (InfoCube that includes the non-cumulative
key figures) is compressed. So that access to queries is as quick as possible, compress the non-cumulative InfoCubes regularly (see Compressing
InfoCubes) to keep the marker as up-to-date as possible.
For example, in month 03 the marker is read with three non-cumulative changes for a query. In month 04, the marker is updated so that the
current marker has to be read with only one non-cumulative change for a query in month five. If the marker had not been updated, it would have
had four non-cumulative changes to read.
Data Transfer or Storage, and Aggregation for Non-Cumulative Key Figures

To optimize the data transport and data retention for non-cumulative key figures in the BI system, non-cumulative key figures are treated differently from
cumulative values in both technical data transfer and storage:
Non-cumulative key figures are mapped using one key figure for non-cumulative changes or two key figures for inflows and outflows.
See also: Non-Cumulative Key Figures
A non-cumulative InfoCube has to contain a time-reference characteristic, that means there must be a time-reference characteristic for exception
aggregation of the non-cumulative key figure.
See also: Time Reference Characteristics
A non-cumulative key figure always has a time-related exception aggregation.
See also: Aggregational Behavior of Non-Cumulative Key Figures
In specific cases it may be necessary to determine the validity of a non-cumulative.
See also: Validity Area.
Non-cumulatives are transferred in an initialization run and in the change runs that follow (initialization can also be omitted here).
See also Transferring Non-Cumulative Data into BW
Integration
In query definition and navigation in reporting, there is no difference in the way cumulative and non-cumulative key figures are dealt with. Cumulative and non-

cumulative key figures can be analyzed at the same time in a query.
The special treatment of non-cumulative key figures is only possible in the InfoCube. DataStore objects do not support this.
Non-Cumulative Key Figures

There are two different ways to define non-cumulative key figures:
Non-cumulative key figure with non-cumulative changes:
Before you can define the non-cumulative key figure, an additional cumulative key figure containing the non-cumulative change must exist as an
InfoObject.
Non-cumulative key figure with inflows and outflows
There has to be two additional cumulative key figures as InfoObjects for non-cumulative key figures - one for inflows and one for outflows. The cumulative
key figures have to have the same technical properties as the non-cumulative key figure, and the aggregation and exception aggregation have to be SUM.
You can evaluate separately the non-cumulative changes on their own, or also the inflow and outflow, according to the type of chosen non-cumulative key
figure in addition to the non-cumulative.
For aggregation, see Aggregational Behavior of 1.3.2.3.1.1 Non-Cumulative Key Figures
1.3.2.3.1.2 Time Reference Characteristic
Use
If the InfoCube contains a non-cumulative key figure, then a time-based reference characteristic for the exception aggregation of the non-cumulative key figure
must exist. There can be several time characteristics per InfoCube, but only one time reference characteristic. This means, that the time-based reference
characteristic is the same for all the non-cumulative key figures of an InfoCube.
Integration
The time reference characteristic for an InfoCube when there are several time characteristics in the InfoCube is always the most refined, since all other times
in the InfoCube are derived from this.
An InfoCube contains warehouse key figures that should be evaluated for the calendar month and calendar year. In this case, the calendar
month is the most refined common time reference characteristic.
You can only maintain the time-reference characteristic and the fiscal year variant when updating an InfoCube with non-cumulative key figures. All other time
characteristics are automatically derived from the time-reference characteristic. Therefore, the time-reference characteristic must not be left blank.
There is a difference between complete and incomplete time characteristics:
The complete time characteristics are the SAP time characteristics calendar day (0CALDAY), calendar week (0CALWEEK), calendar month (0CALMONTH),
calendar quarter (0CALQUARTER), calendar year (0CALYEAR), fiscal year (0FISCYEAR) and fiscal period (0FISCPER). They are clearly assigned to a point
in time. Only these SAP time characteristics can be used as time reference characteristics, since you must be able to derive time characteristics
automatically from the most detailed time characteristic must be possible with the non-cumulative folder.
Incomplete time characteristics, such as 0CALMONTH2, 0CALQUART1, 0HALFYEAR1, 0WEEKDAY1 or 0FISCPER3 can be used in a non-cumulative
InfoCube but cannot be a time reference characteristic, since they are not assigned to a specific point in time.
The following graphic gives an overview of the hierarchy for SAP time characteristics:
If you have a non-cumulative for a week and for a month in the same InfoCube at the same time, the roughest common time characteristic is
calendar day. The time characteristic calendar day must be included in the InfoCube, so that it can function as a reference characteristic for
time-based aggregation.


BI Platform

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BI Platform

Hochgeladen von

Copyright:

Verfügbare Formate

BI Platform

PDF download from SAP Help Portal:

Created on November 15, 2016

PUBLIC Page 1 of 139

PUBLIC Page 2 of 139

PUBLIC Page 3 of 139

PUBLIC Page 4 of 139

1.1 Metadata Repository

PUBLIC Page 5 of 139

Calling the Metadata Repository as an HTTP Service

1.1.1 BI Metadata Search

Data Warehousing Workbench

Functional Area BI Metadata Search

Modeling Data Warehousing Workbench search

Metadata repository Simple Search

PUBLIC Page 6 of 139

1.1.2 Displaying Graphics

PUBLIC Page 7 of 139

1.1.3 HTML Export

Export Function in the . Data Warehousing Workbench view

Menu Path Extras HTML Export Transport connection

Context Menu for Metadata Object

Search Depth Meaning

1.1.4 Exchanging Metadata in XMI Format

PUBLIC Page 8 of 139

Components of the URL

<Protocol> http or https

Example for the class InfoCube : CLASSID=COM.SAP.BW.CWM.OLAP.INFOCUBE

<Name> Specify the technical name for the required BI object.

You get an overview of all objects from the URL:

You can enter the following for InfoCubes for example:

Importing from another system

PUBLIC Page 9 of 139

Main Page of the Metadata Repository

An example of <SystemIDClient> is: AB5CLNT003.

List of Object Types for the Metadata Repository

Information About a Specific Metadata Object

An example of this: http://us7031.wdf.sap.corp:50031/

PUBLIC Page 10 of 139

PUBLIC Page 11 of 139

1.2.1 Document Classes

BI Object Document Class

Master data MAST

InfoProvider data TRAN

Document Class Document properties

PUBLIC Page 12 of 139

1.2.2 BAdIs for Use in Documents

BAdI for Documents (RSOD_DOC_BADI)

CHANGE_PROPERTIES Change properties of a document

CREATE_PROPERTIES Create properties of a document

DELETE_PROPERTIES Delete properties of a document

STORE_CONTENT Write document content to the database

SELECT Select documents (DW Workbench or Web application)

HIERARCHY_RESOLVE Control hierarchy resolution in reporting

BAdI for Single Document Web Item (RSOD_ITEM_DOC)

CHANGE_RENDERING Change output (HTML)

BAdI for List of Documents Web Item (RSOD_ITEM_DOC_LIST)

CHANGE_RENDERING_CONTEXT Change output of the context (the selection)

CHANGE_RENDERING_FUNCTIONS Change output of the Additional Functions pushbutton

CHANGE_RENDERING_LIST Change output of document list

CHANGE_RENDERING Change entire output of item

PUBLIC Page 13 of 139

DETERMINE_VERSION_HANDLING Determine version handling on the Web

BEFORE_RENDERING Option to change the document before displaying it