Web Intelligence On SAP Implementation Best Practices

Web Intelligence XI 3.
0 on SAP
NetWeaver BI
Field implementation guide
Confidential and Proprietary

Internal Business Objects/SAP use ONLY
Version 1.0
2008-10-02
Contents
Contents .......................................................................................................................................... 2
1 Introduction ............................................................................................................................. 5
1.1 Intended audience........................................................................................................... 5
1.2 Assumptions .................................................................................................................... 5
1.3 References ....................................................................................................................... 6
2 Useful concepts ....................................................................................................................... 7
2.1 SAP NetWeaver BI Modelling concepts........................................................................... 7
2.1.1 BI InfoCubes as data sources ................................................................................... 7
2.1.2 BEx Queries as data sources .................................................................................... 7
2.2 Mapping SAP NetWeaver BI concepts to Universe concepts.......................................... 9
2.2.1 How BI characteristics are mapped and used in a universe .................................. 11
2.2.2 How BI key figures are mapped and used in a universe........................................ 11
2.2.3 How BI hierarchies are mapped and used in a universe ....................................... 12
2.2.4 How BI variables are mapped and used in a universe........................................... 14
2.3 Under the hood – BI OLAP Universe processing details ................................................ 21
2.3.1 The OLAP BAPI as an interface to BI ...................................................................... 21
2.3.2 APIs used in creating an OLAP Universe ................................................................ 22
2.3.3 Process flow for viewing a Web Intelligence report.............................................. 23
3 Security integration ............................................................................................................... 25
3.1 Authentication ............................................................................................................... 25
3.1.1 SAP login in Universe Designer .............................................................................. 25
3.1.2 Universe connection settings ................................................................................ 25
3.1.3 Single Sign-On ........................................................................................................ 26
3.1.4 Secure Network Communication environments ................................................... 27

3.1.5 Scheduling ............................................................................................................. 27
3.2 BI authorizations for OLAP BAPI access......................................................................... 27
3.2.1 Creating a new Universe from a query or a cube in a BI role................................ 28
3.2.2 Creating/refreshing a WebI query/report ............................................................. 29
4 Lifecycle management........................................................................................................... 31
5 Common scenarios and decisions ......................................................................................... 32
5.1 Customizing BI Universe definition ............................................................................... 32
5.1.1 Removing unnecessary L00 objects....................................................................... 32
5.1.2 Removing unused or redundant detail objects ..................................................... 32
5.1.3 Optimizing detail object syntax ............................................................................. 32
5.1.4 Adding keys to objects used in an LOV for filtering............................................... 33
5.2 Scheduling vs. on-demand reporting ............................................................................ 33
5.3 Hierarchies..................................................................................................................... 34
5.3.1 Defining custom hierarchies in the Universe ........................................................ 34
5.3.2 Query Drill for hierarchies ..................................................................................... 34
5.3.3 Hierarchies with linked nodes ............................................................................... 35
5.4 Filtering .......................................................................................................................... 35
5.4.1 Static filtering of characteristic values .................................................................. 35
5.4.2 Dynamic filtering of characteristic values ............................................................. 36
5.4.3 Large LOVs for prompting...................................................................................... 37
5.5 Reports with high data volume ..................................................................................... 37
5.5.1 Reducing the size of rows by optimizing WebI queries ......................................... 38
5.5.2 Reducing the number of rows per request by using guided navigation ............... 42
5.6 Creating queries for Master Data reporting .................................................................. 42
5.6.1 Query containing a single level of a single characteristic ...................................... 43

5.6.2 Query containing multiple levels of a single characteristic ................................... 43
5.6.3 Query containing multiple characteristics............................................................. 43
5.7 Leveraging structures in a BEx query ............................................................................ 43
5.7.1 Queries with multiple structures........................................................................... 44
6 BI Performance tuning........................................................................................................... 46
6.1 Performance impact of data modelling......................................................................... 46
6.1.1 Line item dimension and high cardinality ............................................................. 46
6.1.2 Navigational Attributes.......................................................................................... 47
6.2 Overall reporting performance ..................................................................................... 48
6.2.1 Query monitor ....................................................................................................... 48
6.2.2 Transaction ST03 ................................................................................................... 52
6.3 Relevant SAP Notes ....................................................................................................... 54
7 Troubleshooting .................................................................................................................... 55
7.1 Tracing and troubleshooting the Web Intelligence connectivity .................................. 55
7.2 Additional troubleshooting tools .................................................................................. 56
7.2.1 Using OLAP BAPI functions .................................................................................... 56
7.2.2 Using the OLAP trace tool (RSRTRACE).................................................................. 61
7.2.3 MDX Testeditor...................................................................................................... 63
7.3 Troubleshooting scenarios ............................................................................................ 65
7.3.1 Scenario 1: Dimensions are missing in the SAP OLAP Universe ............................ 65
7.3.2 Scenario 2: SAP Variables are not showing up in Web Intelligence ...................... 66
7.3.3 Scenario 3: Values are missing in the List of Values for prompting ...................... 66
7.3.4 Scenario 4: Data is missing when executing the report ........................................ 67

1 Introduction
This document aims to provide guidance for a successful deployment of Web Intelligence on SAP
NetWeaver BI or SAP BW 3.x. In general, where the terms BI or SAP NetWeaver BI are used in
this document, it may refer to either SAP NetWeaver BI or to SAP BW 3.x. It is intended to guide
the reader through the high-level concepts relevant to such an implementation, and to highlight
the potential issues and pitfalls which may be encountered in the course of such a deployment.
The focus is on the factors which are unique to using WebI with BI, as opposed to general
guidance on deploying WebI.
A primary focus of this document is a set of practices and steps which may be taken to maximize
the performance of WebI reports against SAP NetWeaver BI. In this context, maximizing
performance refers to a balance of minimizing:
• The processing required (both in WebI and BI)

• The memory footprint required (both in WebI and BI)
• The report viewing user’s perceived response time
In order to properly explain and rationalize these practices, it is also necessary to provide a lot of
insight into the processing flow. As a result, there is a lot of such information in the beginning of
this guide.
Upon reading this document, it is expected that the reader will have the basic knowledge
required to successfully deploy WebI for reporting on BI.
1.1 Intended audience

The intended audience of this document is a technical Business Objects or partner field
professional who is responsible for successfully deploying Web Intelligence (WebI) against BI.
1.2 Assumptions
This document assumes that the reader is proficient in classic universe design and the QRA
capabilities offered in WebI XI 3.0.
It also assumes that the reader has had in-depth exposure to BI and the Business Explorer Suite
(BEx). More specifically it is expected that the reader is familiar with BEx Query design using the
BEx Query Designer.
Lack of knowledge in these areas will most likely result in serious challenges in successfully
positioning and deploying the solutions described in this document.
Web Intelligence XI 3.0 on SAP NetWeaver BI Intended audience 5

Confidential and Proprietary – Business Objects/SAP internal use only
1.3 References
Available from http://help.sap.com, in the Business Objects area, under BusinessObjects XI 3.0
version:
Using SAP BW in Universe Designer
Designer’s Guide
BusinessObjects XI Integration for SAP User's Guide
Available from http://service.sap.com/releasenotes, in the Business Objects area (login

required):
BusinessObjects XI 3.0 Release Notes
Available from http://service.sap.com/bosap-instguides, in the Business Objects area (login

required):
BusinessObjects XI Integration for SAP Installation Guide
BusinessObjects XI 3.0 - Integration for SAP Solutions - Supported Platforms

SAP Library – Business Intelligence: Modeling
Web Intelligence XI 3.0 on SAP NetWeaver BI References 6

2 Useful concepts
2.1 SAP NetWeaver BI Modelling concepts
When creating an OLAP universe based on a BI data source, you can build the universe based
directly on an InfoCube/Multiprovider, or based on a BEx Query enabled on top of any
InfoProvider. An InfoProvider can be:
• an InfoCube
• a Multiprovider
• an Operational Data Store (ODS)
• an InfoSet
• an InfoObject (Master Data)
2.1.1 BI InfoCubes as data sources

The following types of InfoCubes are supported as data sources for building OLAP universes:
• Standard and Transactional InfoCubes: Data and metadata are physically stored in the same
BI system
• Remote InfoCube: Data is physically stored on a remote system
Note: While fully supported, building and deploying universes on remote InfoCubes is not
recommended for ad-hoc query-, reporting-, and analysis scenarios. Such architecture is
generally not expected to meet query performance expectations with interactive queries.
• MultiProvider
Note: Building and deploying a Business Objects universe on top of a MultiProvider is

identical to building and deploying a universe on top of an InfoCube. All the characteristics,
hierarchies, key figures, including time and unit, in the InfoCube are visible in the universe.
2.1.2 BEx Queries as data sources

SAP NetWeaver BI customers use BEx Queries to access data through SAP Business Explorer
front-ends.
Note: In order to serve as a data source and become available through the OLAP interface to
Business Objects universes, BEx Queries must be released for OLE DB for OLAP. You allow
external access to the BEx Query in the BEx Query Designer, on the Extended tab of the Query
Properties dialog box.
All InfoObjects in the BEx Query selected as rows, columns, and free characteristics are visible in
the universe. This includes characteristics, hierarchies, key figures, structures, and variables.
Both InfoSets and Operational Data Stores (ODS) can be exposed to universes via BEx Queries.
Web Intelligence XI 3.0 on SAP NetWeaver BI SAP NetWeaver BI Modelling concepts 7

2.1.2.1 BEx Queries based on an ODS
ODS objects are often used to manage detailed transactional-level data before it is aggregated
into InfoCubes. Including ODS objects in the BI data store design is a way to minimize InfoCube
size and improve loading and querying performance. An ODS can be exposed to a Universe via a
BEx Query.
Note: An ODS is usually a large, detailed relational structure. Accessing an ODS via the OLAP
BAPI interface does not deliver ideal query performance. Consider these alternatives to meet
end-user expectations for fast report delivery:
• Create direct access to an ODS via BAPI calls (only available for Crystal Reports in XI 3.0)
2.1.2.2 BEx Queries based on an InfoSet

An InfoSet can be exposed to a universe via a BEx Query. InfoSets are sometimes defined in BI
to report off master data or to leverage specific JOIN types between InfoCubes.
Note: You can report off master data by basing the universes on InfoCubes, eliminating the
requirement to go through InfoSets and BEx Queries. The key difference between the two
approaches is that master data reported off InfoCubes limits data to valid transactions and does
not allow you to leverage specific join types.
2.1.2.3 BEx Queries as recommended data sources

BEx Queries are recommended as data sources for generating universes for the following
reasons:
• BEx Queries offer a flexible extension to the data modeling environment. InfoCubes require
more effort to change.
• BEx Queries offer significant functionality to create customized data sources that meet end-
user requirements, such as Calculated Key figures, Restricted Key figures and SAP Variables.
• In the OLAP BAPI interface, not all BI metadata features can be retrieved on an InfoCube
level, as summarized in the following table:
BI metadata feature SAP OLAP BAPI support level
Characteristics (incl. Time and Unit) InfoCube/BEx Query
Hierarchies InfoCube/BEx Query
Basic Key Figures InfoCube/BEx Query
Navigational Attributes BEx Query only
Display Attributes InfoCube/BEx Query
Calculated Key Figures / Formulas BEx Query only
Web Intelligence XI 3.0 on SAP NetWeaver BI SAP NetWeaver BI Modelling concepts 8

Restricted Key Figures BEx Query only
Custom Structures BEx Query only
Variables BEx Query only
Although BEx Queries have advantages as data sources, you do not need a BEx Query for every
report, nor do you need a universe for every existing BEx Query. To minimize maintenance
costs, focus the implementation strategy on limiting the final number of BEx Queries and
universes required to meet all the ad-hoc query and reporting needs. Keep in mind the following
points to reduce the number of universes needed:
• When Web Intelligence is the front-end tool, you are not restricted by the output format in
the BEx Query.
• There is no direct impact on performance when working with OLAP universes created from
large BEx Queries. OLAP universe objects not inserted in the Web Intelligence query have no
direct impact on the query performance.
Note: Business Objects recommends having a few BEx Queries – from a single one to a handful
of them – for every InfoCube or MultiCube that is in scope for ad-hoc query and reporting. Then
build a universe on top of each of these BEx Queries.
2.1.2.4 Multilingual SAP NetWeaver BI universes

The result-set language is dependent on SAP’s Unicode support. If the SAP system does not
contain the data in the desired language, the data is not available in Web Intelligence in this
language. Web Intelligence reverts to displaying technical names instead of descriptions when
the descriptions are not translated in BI.
2.2 Mapping SAP NetWeaver BI concepts to Universe concepts

When you create a universe from either an InfoCube or a BEx Query, Designer maps BI OLAP
structures to equivalent classes and objects in the universe. An SAP OLAP Universe is based on a
single Query or InfoCube -- it is not possible to use a single universe to join multiple Queries or
InfoCubes. Note that this section deals only with the default universe created for an InfoCube
or BEx Query. As explained in the section Customizing BI Universe definition, it is possible and
sometimes necessary to customize this structure.
All InfoObjects in the BEx Query set as rows, columns, and free characteristics are exposed to
the universe. This includes characteristics, hierarchies, key figures, structures, and variables.
Hierarchies are mapped, allowing Web Intelligence users to drill down according to BI
hierarchies.
For InfoCubes, all the dimensions, characteristics, key figures, and hierarchies are mapped. The
following table shows the universe objects created for each BI object.
Web Intelligence XI 3.0 on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 9

Field implementation guide Universe concepts
The term “Dimension” is used differently between the SAP products and BusinessObjects
products. For SAP a “Dimension” is a grouping of logically or technically related characteristics
into a generic term. Up to 248 characteristics can be combined within one dimension.
On the BusinessObjects side the term “Dimension” is identical to what SAP defines as a
characteristic.
BI object: Universe objects created:
Dimension Class
Characteristic Subclass with dimension and detail objects
If data source is a BEx Query: Subclass containing

dimension and detail objects for each hierarchy
level in the currently defined hierarchy
Characteristic with hierarchy If data source is an InfoCube: Subclasses containing
dimension and detail objects for each hierarchy
level for all hierarchies defined for the
characteristic
Structure based on Characteristics (BEx Queries Class with single dimension object for the structure
only)
Subclass with dimension and detail objects

Navigational attribute
(identical to characteristic)
Display Attribute Detail object for the dimension
Measure object in the class for the Key Figure

structure with dimension objects for
Key Figure
units/currency, numeric value and formatted value
(based on User preferences)
Measure and dimension objects (same as Key

Calculated Key Figure (BEx Queries only)
Figure)
Measure and dimension objects (same as Key

Restricted Key Figure (BEx Queries only)
Figure)
Pre-defined Filter in the Universe
Variables (BEx Queries only) In the class for the dimension to which the variable
applies, two dimension objects supporting the list
of values (value help): one for caption, one for

description.
Universe parameters defining key date variable in

Key date variable (BEx Queries only)
the universe
Characteristics in the Filters section of the BEx Query are not mapped. However, the filtering
applies to the universe. If the filter has a fixed value, the filter is applied transparently when
running the Web Intelligence query. If the characteristic has a variable defined, the variable is
mapped to a pre-defined filter object in the Universe.
2.2.1 How BI characteristics are mapped and used in a universe

When no hierarchy is defined on the characteristic in the BEx Query or InfoCube, Designer
creates a class containing the characteristic as two dimension objects: Level 00 and Level 01. The
Level 00 dimension represents the aggregation of the characteristic when all members are
selected (the member returned from BI is All members). The Level 01 dimension contains all
members for the characteristic as a flat list of values.
For each dimension object, Designer creates a detail object for the key, up to three detail
objects for the description (short, medium, and long descriptions), and a detail object for each
display attribute.
Navigational attributes leveraged in the BEx Query are mapped in the parent object class in the
same way as characteristics are mapped.
Note: A large number of navigational attributes defined in the underlying InfoProvider

negatively impacts the overall performance (please refer back to SAP Best Practices for Data
Modelling). Structures defined in the BEx Query that are based on characteristics are included
in the universe as single-dimension objects with the elements of the structure as dimension
members.
2.2.2 How BI key figures are mapped and used in a universe

All key figures in the InfoCube or defined in the BEx Query are included in the universe under a
single object class called “Key Figures”.
Most key figures are defined in BI with either a currency or a unit characteristic. Based on the
details of the key figure, Designer creates up to three objects:
 A measure object with the numeric value corresponding to the key figure without the
unit.
 A dimension object with character format that contains the unit or currency. For
example, 'USD', '€', 'km'.
 A dimension object with character format that contains the key figure and the unit
(formatted value) based on user preferences configured on the SAP server. For example,
'200 USD', '345 €', '25 km'.

The Key Figures class includes the calculated key figures and restricted key figures defined in the
BEx Query. The original calculation and restrictions are applied to the query, but are not
exposed in the universe.
Note: Having a large number of key figures in the BEx query will currently incur a significant
performance penalty when running queries using Universe data access. This is regardless of
whether the key figures are included in the Universe or used in the WebI query. It is therefore
suggested to have only those key figures intended to be used for reporting included in the BEx
query definition. This performance impact is due to time spent loading metadata for units,
which is currently executed for all measures in the query. A fix for this issue may become
available in the future.
2.2.3 How BI hierarchies are mapped and used in a universe

Hierarchies are mapped to allow Web Intelligence users to drill down with BI hierarchies in the
same way as custom-made universe hierarchies.
BI hierarchies are slightly different than the classic definition of a hierarchy in a universe. In BI,
the user is able to leverage hierarchical functionality in multiple different ways.
2.2.3.1 Characteristic Hierarchies

A characteristic hierarchy is a hierarchical structure for one or more InfoObjects. A typical
example would be a hierarchical structure of cost centers or as shown below a hierarchical
structure of the Sales Representatives.
In the given example the hierarchy itself is based on a single characteristic.
When a hierarchy is defined on a characteristic in the BEx Query, Designer creates one
hierarchical structure in the universe, with a subclass for each level in the hierarchy. The
structure depends on the current BEx Query definition:

• If a hierarchy is defined in the BEx Query, Designer creates this hierarchy structure in
the universe with the maximum amount of hierarchy levels defined.
• If a hierarchy variable is defined in the BEx Query that allows the user to choose a
hierarchy at run time, Designer creates a generic hierarchy in the universe. The
structure has the highest number of levels defined for any of the hierarchy structures
available for the characteristic.
 When building a universe on top of an InfoCube, all hierarchies defined on the
characteristic are exposed in the resulting universe. Designer creates subclasses for each
hierarchical structure, each containing subclasses for the levels in that hierarchy.
In the universe, Level 00 of a hierarchy represents the top node of the structure. When multiple
top nodes exist for the hierarchical structure, the Level 00 dimension contains all top nodes as a
list of values. When the hierarchy attribute is set to not filter unassigned nodes, it is necessary
to include Level 00 with the top node for unassigned members. Unassigned members are
grouped at the lowest level of the hierarchy.
Note: The Use Query Drill option in the Web Intelligence Document Properties dialog box
significantly improves drill down performance.
2.2.3.2 “Display as hierarchy”

A second option for the user is to leverage multiple characteristics and “display” them as a
hierarchical structure. This can be configured as part of the BEx query.
As shown below, the query contains three characteristics, but when executed in BEx it is shown
in a hierarchical display.

Hence, the option to “Display as Hierarchy” comes the closest to the hierarchy definition in a
universe, but this is only a BEx query display setting and will not be reflected in a universe
created on that query.
2.2.4 How BI variables are mapped and used in a universe
2.2.4.1 BI variables supported in universes

SAP variables can be interpreted as user prompts defined in the BEx Query. Variables can be
mandatory or optional, and can have default values.
Variables for characteristics are used to filter values for a characteristic. Variables are populated
with values when a query is executed. They can store characteristic values, hierarchies,
hierarchy nodes, texts, and formula elements.

BI variables apply to BEx Queries only.
Note: Only BI variables defined as 'Ready for Input' are available as filter objects in the Universe.
When defining the variable in the BEx Query Designer without using the option “Ready for
input” the variable will still get processed by the BI query but will not be available as a filter in
the universe.
The following types of BI variables are supported in universes:
• Characteristic variables
• Hierarchy variables
• Hierarchy node variables
• Currency variables
• Formula variables
• Text variables (as replacement path and authorization processed variables)
• Key date variables
The following table shows a detailed list of the variable type “User Entry / Default Value” only
and how those are leveraged in a universe. User entry variables can be mandatory or optional,
and can have default values.
Variable Type Support Level
Single value prompt Supported
Multiple single value prompt Supported
Characteristic Interval prompt Supported
Selection option prompt Supported as interval prompt
Pre-calculated value set Supported
Text Not supported
Price, quota, and numeric values

Formula
supported
Hierarchy Supported
Hierarchy node Supported
Hierarchy Version Not Supported
Keydate Supported
Currency Supported

The following table shows universe support for other processing types of BI variables.
Variable type Processing Type

User Entry/ Replacement Authorization Customer SAP exit
Default Value path exit
Characteristic Supported Supported Supported Supported Supported

Text Not Supported Supported N/A N/A N/A
Formula Supported Supported N/A Supported Supported
Hierarchy Supported N/A N/A Supported Supported
Hierarchy Supported N/A N/A Supported Supported
node
Note: The Exclude operator is not supported. Other operators, such as Less than and Greater
than, can only be used with Selection option entry type. The selection option type is turned into
an interval for Web Intelligence prompting.
Note: For Text variables of type Replacement path, only those which have a static value which
will not change between design time and view time will produce the results the user is likely to
expect.
2.2.4.2 BI variable mapping to a universe

The user needs to know if a variable is mandatory or optional, and be able to ignore optional
variables. Optional variables are defined as optional filters in the universe, and become optional
prompts in Web Intelligence. Mandatory variables become mandatory prompts in Web
Intelligence.
For characteristic variables, Designer creates a filter in the universe. For each filter, two
dimension objects are created as reference objects for the @Prompt function to display the
expected list of values (value help). The list of values dimensions are hidden in the universe.
They are necessary for the correct functioning of the prompt so must not be deleted and must
be moved or modified carefully.
Default values for variables are defined in the @Prompt function in the filter using the primary
key, persistent/not persistent, and default values parameters. The @Prompt function syntax can
be seen in the Properties page of the filter in the universe.
Example: WHERE clause generated for a BI variable

This example shows the WHERE clause generated for a BI variable on dimension object
Customer2. The syntax for the generated WHERE clause for a variable can be seen on the
Properties page of the filter.
<FILTER KEY="[Z_VAR002]">

<CONDITION OPERATORCONDITION="Equal">
<CONSTANT TECH_NAME="@Prompt(
'Customer Variable Single Value Mandatory',
'A',
'Customer2\LovCustomer Variable Single Value
MandatoryBase',
mono,
primary_key)"/>
<CONDITION>
</FILTER>
The prompt text is generated from the BI variable name. You can edit the text to make it more
descriptive.
Customer2\LovCustomer Variable Single Value MandatoryBase is the name of the hidden

universe object that is used to build the list of values.
Note: If you rename the class or move the list of values object to another folder, you must
update the syntax in the filter key.
Note: To avoid conflict between BI variables and filters defined by Web Intelligence users, it’s
important to be careful with which objects you allow users to use in defining WebI conditions,
as filtering the same characteristics in two places can cause unexpected results.
2.2.4.3 Mandatory Filters

There are two types of mandatory filter:
• Universe: A universe mandatory filter has no dependency on the class to which it belongs. A
universe mandatory filter is included in the query independently of the objects (dimensions,
measures, and details) that are included in the query.
BI variables are created as universe mandatory filters when generating OLAP universes on
BI.
• Class: Class mandatory filters appear only if an item of the class of the object is used in the
query.
A class mandatory filter is triggered when users:
o Add an object (dimension, measure, or detail) to the Result pane of the Query Panel
in Web Intelligence.
o Add a universe pre-defined filter to the Filter pane of the Query Panel, even if no
object that belongs to the same class has been selected in the Result pane.

o Create a filter with an object (dimension, measure, or detail) that belongs to a class
with a mandatory filter.
A mandatory filter is hidden and cannot be selected in the Query Panel in Web Intelligence. In
Designer, when you set a filter as mandatory in the query, then it is hidden automatically and
the Show Item(s) command is disabled. If you uncheck the mandatory option, the filter is no
longer hidden. The Hide Item(s) command is enabled.
An end-user query can include more than one mandatory filter. By default, all mandatory filters
are joined in the query with the AND operator.
All sub-classes inherit the mandatory filters from the parent class. Note, however:
• An object (dimension, measure, detail) that references another object with the @SELECT
function does not inherit the class mandatory filter of the referenced object.
• A WHERE clause of an object that references another object WHERE clause with the
@WHERE function does not inherit the class mandatory filter of the referenced object.
• A pre-defined filter that references another pre-defined filter or an object WHERE clause
with the @WHERE function does not inherit the class mandatory filter of the referenced
object.
Example: Mandatory filter in an OLAP universe
Purpose of Filter Sample XML code
<FILTER KEY="[BCOMUSI]">
<CONDITION OPERATORCONDITION="InList">
Validate the code entered by a <CONSTANT TECH_NAME="@Prompt('CO_CODE
user in a prompt Char User MultiSingle Man Def', 'A','Company
code\Lov[BCOMUSI]Base', multi,primary_key)"/>
</CONDITION>
</FILTER>
2.2.4.4 BI variables and list of values

A BEx Query can contain many variables, meaning that many lists of values may have to be
loaded. Loading and refreshing lists of values can have a major impact on performance. The
following options are available for improving query performance for queries with variables:
• Optional variables are generated as optional prompts. An optional prompt does not
automatically load the list of values at query run time.
• The delegate search option on the list of values properties presents the user with an empty
list of values at query run time. The user enters search criteria to limit the number of values
returned in the list of values.

To activate the delegated search option for a list of values, edit the list of values properties
on the object properties page of the object to which the list of values applies.
Note: Delegated search is not supported for cascading lists of values.
2.2.4.5 BI key date variables in a universe

A key date variable in a BEx Query allows you to specify a date for time-dependent data. Key
dates can influence the data retrieved for a dimension, for example, a product description can
change over time. A key date can influence a hierarchy structure, for example, a specific cost
center can be on Level 01 in one year, and on Level 02 in a different year.
The key date variable is a special BI variable because the date value entered by the user is not
contained in any dimension of the BEx Query. The key date is a property of the query.
In a BEx Query, the key date variable can be defined for two uses:
• To specify the valid date for a specific hierarchy, impacting only that hierarchy.
• To specify a date for the complete query. In this case, the key date that is set in a query
influences the following:
o time-dependent master data
o currency exchange rates
o the list of hierarchies
o time-dependent hierarchy structures
Note: In the universe, the use of a key date is limited to the whole universe. Therefore, the key
date generated in a universe impacts all other SAP variables and data.
BI supports multiple key date variables per BEx Query, but a universe as of now is only able to
support a single Key date variable.
Key date variables can be mandatory or optional, and can have a default value. If no default
value is defined and the user does not enter a value, the query uses the current system date of
the BI system.
The key date variable properties of the query are mapped to five universe parameters,
described in the following table.
Parameter Description
KEYDATE_ENABLED Set to Yes if a key date is enabled on the

universe

KEYDATE_NAME Technical name of the key date variable
KEYDATE_CAPTION Caption for the key date variable presented

when prompting the user for a value
KEYDATE_DEFAULT_VALUE Default value for the key date, if it exists
KEYDATE_MANDATORY Set to Yes if a user must enter a value or use

the default
At query run time, Web Intelligence is able to handle different keydates for multiple queries
based on a single Universe, which allows the user to create a very simple comparison of
different set of data. The user can modify the key date behaviour as part of the Keydate
properties.
2.2.4.6 BI hierarchy and hierarchy node variables in a universe

A hierarchy variable is used to prompt the user for the hierarchy to be used in the query. Web
Intelligence users can create queries and reports to retrieve and display members from any
hierarchy.
If the hierarchy variable is optional and the user leaves the prompt empty, no hierarchy is used
and the report will leverage the standard display of the characteristic.
A report can contain the largest number of hierarchy levels independent of the hierarchy that is
selected. Hierarchy levels that are not returned in the result set are empty in the report.
A hierarchy node variable is used to prompt the user for the node to be used as a filter for the
report.
When a query contains both a hierarchy and hierarchy node variable, the Web Intelligence user
must first select a hierarchy in the list of available hierarchies. Next, the user selects the
hierarchy node.
The list of hierarchy nodes will show hierarchy nodes for all available hierarchies regardless of
which hierarchy is selected. The user is responsible for selecting a node from the correct
hierarchy. This has been raised as a major concern and will be addressed in a future release.

2.3 Under the hood – BI OLAP Universe processing details
In order to understand how to optimize Universe and WebI query design for BI reports, it is
necessary to understand some of the processing that occurs while running a report based on a
BI OLAP universe. The previous sections have explained logically how SAP constructs are
represented in a universe. This section will go into the details of what this means when
designing and using a BI OLAP universe.
2.3.1 The OLAP BAPI as an interface to BI

The connectivity to BI is made through the SAP OLAP BAPI.
Note: The OLAP BAPI interfaces are based on MDX and so use MDX-like terms to describe the
various constructs and concepts used. In some cases, this will differ from the representation
within BEx and other tools.
This BAPI consists of two main parts:
The MDProvider interface

This interface is used mainly for fetching metadata. It consists of a number of RFC function
modules (BAPI_MDPROVIDER_*), which provides the ability to list and get details for things like:
• Cubes
• Queries
• Hierarchies
• Levels
• Dimensions
• Measures
• Members
The MDDataSet interface

This interface is used for executing MDX statements against BEx Queries or InfoCubes in BI, and
returning the results. It consists of a number of RFC function modules (BAPI_MDDATASET_*).
Web Intelligence XI 3.0 on SAP NetWeaver BI Under the hood – BI OLAP Universe 21
Field implementation guide processing details
2.3.2 APIs used in creating an OLAP Universe
The table below shows the functions within the OLAP BAPI which are used during the process of
creating an OLAP Universe on BI. The order within the table also roughly indicates the
processing flow.
BAPI function called Purpose
BAPI_MDPROVIDER_GET_CATALOGS Retrieves the list of BI cubes.
Retrieves the list of BEx queries based on the

BAPI_MDPROVIDER_GET_CUBES
selected cube.
Retrieves the list of characteristics based on

BAPI_MDPROVIDER_GET_DIMENSIONS
the selected BEx query or cube.
Retrieves the list of hierarchies based on the

BAPI_MDPROVIDER_GET_HIERARCHYS
list of available characteristics.
Retrieves the number of levels per hierarchy.

Uses the result of
BAPI_MDPROVIDER_GET_LEVELS
BAPI_MDPROVIDER_GET_HIERARCHYS as
input.
Retrieves the key figures for the selected

BAPI_MDPROVIDER_GET_MEASURES
query or cube.
Retrieves the list of display attributes for each

BAPI_MDPROVIDER_GET_PROPERTIES
characteristic.
Retrieves data type information for the list of

BAPI_IOBJ_GETDETAIL
key figures and characteristics.
Retrieves the list of variables for the selected

BAPI_MDPROVIDER_GET_VARIABLES
BEx query.
2.3.3 Process flow for viewing a Web Intelligence report
The approximate process flow for viewing a Web Intelligence report based on BI is:
1. Process LOVs (value help) for any prompts – done through

BAPI_MDPROVIDER_GET_MEMBERS calls.
2. Execute Report Query – done by executing MDX through
BAPI_MDDATASET_SELECT_DATA.
2.3.3.1 APIs used

The table below shows the functions within the OLAP BAPI which are used during the process of
viewing a Web Intelligence report based on an OLAP Universe on BI. The order within the table
also roughly indicates the order the calls are made in.
BAPI function Purpose
BAPI_MDPROVIDER_GET_CUBES Called to verify the selected BEx query or cube.
Called to retrieve the list of variables for the

BAPI_MDPROVIDER_GET_VARIABLES selected query.
Called for each referenced dimension to verify

BAPI_MDPROVIDER_GET_DIMENSIONS the dimension.
Called for each referenced dimension to

BAPI_MDPROVIDER_GET_HIERARCHYS retrieve the hierarchies

BAPI_MDPROVIDER_GET_LEVELS retrieve the levels of the hierarchies

BAPI_MDPROVIDER_GET_PROPERTIES retrieve the display attributes

BAPI_MDPROVIDER_GET_MEMBERS retrieve the list of values (used for LOV)
Called to execute MDX statement for main

BAPI_MDDATASET_SELECT_DATA query.
BAPI_MDDATASET_GET_AXIS_DATA Called to retrieve axis data for executed MDX.
BAPI_MDDATASET_GET_CELL_DATA Called to retrieve cell data for executed MDX.
Note: With the exception of BAPI_MDPROVIDER_GET_MEMBERS and the BAPI_MDDATASET_*
functions, all of the below are used simply to verify the cube/query definition matches what is
expected.
2.3.3.2 Resolving of WebI query filters to member selection

When a filter is applied on a universe object which does not have a key field defined and
mapped to the appropriate member-unique name in BI, it is necessary to first resolve the
textual caption to a member-unique name before generating MDX for the query. This process
involves making another call to BAPI_MDPROVIDER_GET_MEMBERS, passing the relevant
caption as a filter. Presently, this resolution of caption to member-unique name is quite
expensive, particularly for high cardinality dimensions. In some cases, this resolution will take as
long as the processing of the generated MDX query in its entirety. For more details on avoiding
this, see
Adding keys to objects used in an LOV for filtering.
Note: See Relevant SAP Notes for reference to some potential performance improvements in
this area.
2.3.3.3 Processing of result set data for WebI MicroCube

The table above shows the flow which occurs up to the point when the BI system returns data to
WebI (by BAPI_MDDATASET_GET_CELLDATA). However, there is a substantial amount of work
to be done after this point, as the data returned by the BAPI is in a multidimensional format, and
WebI requires the data to be in a flat format in order to be loaded into the MicroCube. As a
result, the data must be flattened. This flattening process can be quite time-consuming and
memory-intensive within the WebI processing server, and depending on the structure of the
data (hierarchy depths, etc.), may necessitate changes to the universe and/or WebI query to
minimize this.
3 Security integration
3.1 Authentication
In order to connect to the BI system to retrieve data, it is necessary for the user to be
authenticated against the BI system. This can be accomplished:
• By specifying and saving the BI user and password in the universe connection properties
• By configuring the universe connection as an SSO connection.
• In on-demand viewing cases, by configuring the universe to prompt the user for credentials
at view-time.
3.1.1 SAP login in Universe Designer

The Universe Designer supports SAP authentication. If logging in to the Universe Designer using
SAP authentication and for a connection with logon set to SSO, the designing user will be logged
into BI with the SAP credentials used to logon to the designer, where possible. If SAP credentials
are not used when logging into Universe Designer, it is not possible to design a universe
configured for SSO.
Note: This requires the SAP Authentication to be configured in the CMC as a pre-requisite.
3.1.2 Universe connection settings
3.1.2.1 SAP login parameters

When defining the universe connection parameters, there
are 2 alternative options to define the SAP login
information:
1. With a direct access to a BI application server
2. With access through a SAP message server
Option #2 enables SAP load balancing capabilities. A valid

SAP Logon Group and System ID are required to enable
this login. In addition, an entry for the system is required in the services file.
3.1.2.2 Advanced connection parameters

When defining the connection a few advanced
parameters are available as indicated on the
picture beside:
Array fetch/bind size and login timeout

parameters have no effect on a connection to BI.
The connection life-time option can have a

significant impact when working with BI. It is
Web Intelligence XI 3.0 on SAP NetWeaver BI Authentication 25

strongly recommended to keep the connection life-time to the default option and to not
disconnect after each transaction as this would significantly slow down the universe building
process and also impact key end-user workflows such as working with hierarchical list of values.
Examples of individual “transactions” which are executed within a single workflow are:
 Retrieving the list of dimensions

 Retrieving the list of hierarchies
 Retrieving the list of hierarchy levels
Clearly, disconnecting and reconnecting between each of these transactions will lead to a
significant performance penalty.
However, it is important to note that the OLAP BAPI interface builds a metadata cache on the
client side every time a connection to BI is established. This cache is only emptied when the
connection shuts down.
When working in parallel to edit BEx Queries and map new universes to these queries, it is
therefore recommended to shut down the universe Designer (so that universe connections are
also shut down and the metadata cache is emptied) before building any new universes to take
into changes that were just made on the BEx Query side.
To minimize the risk of the metadata cache being desynchronized with BEx Query updates, the
default universe connection life-time can also be changed to decrease its value from 10 minutes
down to 1 minute.
3.1.3 Single Sign-On

When the BOE user who is running a WebI report is defined as an SAP user on the BI system
used in the universe connection, SSO to the database may be possible.
The following criteria must be met for SSO to function:
 Universe connection is configured to use SSO

 BOE user connected is defined in BOE as an SAP user, or has an SAP user alias in BOE, on
the BI system the connection is configured against
 One of the following is true:
o When viewing on-demand, user signed into BOE using his SAP credentials or
with an SAP Logon Ticket.
o When viewing on-demand or scheduling, SNC with server-side trust (see Secure
Network Communication environments) is configured between BI and the BOE
server processing the request. Note that SNC support in WebI was not delivered
in the XI 3.0 release, but is available as a Limited Availability fix or in Fix Pack 2
(FP2 was not yet released at the time of writing of this paper).
Web Intelligence XI 3.0 on SAP NetWeaver BI Authentication 26

3.1.4 Secure Network Communication environments
In order to more robustly and universally support Single Sign-on, it is possible to configure
Server-Side trust between the BOE processing servers and the BI system using Secure Network
Communication (SNC). As highlighted in the Single Sign-On section, using SNC is the only way to
achieve SSO in cases where the user’s authentication against BOE is done with an account on a
system other than the BI system used by the query, or in schedule-time cases. For details on
configuring SNC, refer to the section titled Configuring SAP Server-Side Trust in the guide:
BusinessObjects XI Integration for SAP Installation Guide
3.1.5 Scheduling
When scheduling a WebI document there is no option to enter credentials that will be used for
processing the query on the BI system. In order to successfully run the report, you must either:
• Define hard-coded User-id and password in the universe connection at design time. In
this case, these credentials will be used for all scheduled instances, regardless of which
user scheduled it.
• Define the universe connection to use SSO at view time, and meet the SSO requirements
(see Single Sign-On).
3.2 BI authorizations for OLAP BAPI access

BI system or dialog accounts are fine to work with universes and WebI. However, this section
provides a list of SAP authorizations that, in our experience and in our test environment, are
required to carry out common tasks with universes for BI. Additional authorization objects or
fields may be required, depending upon your individual implementation. For more information
on Authorizations for Data Warehousing in BI, follow this link.
From each authorization object, you must create an authorization and define the appropriate
field values. You then apply the appropriate authorizations to the profiles (or roles) of your SAP
users.
Web Intelligence XI 3.0 on SAP NetWeaver BI BI authorizations for OLAP BAPI access 27
3.2.1 Creating a new Universe from a query or a cube in a BI role
Object class Object Fields Values
AAAB -Cross- S_RFC – Authorization Check for RFC ACTVT - Activity Execute
application Access
Authorization RFC_NAME – Name RSOB, RZX2,
Objects of RFC to be SYST
protected
RFC_TYPE - Type of FUGR

RFC to be protected
RS - Business S_RS_COMP - Business Explorer - ACTVT - Activity Create or

Information Components generate,
Warehouse Display,
Execute
RSINFOAREA - *
InfoArea
RSINFOCUBE - *
InfoCube
RSZCOMPID - ID of *
reporting
component
RSZCOMPPTP - Type All values

of reporting
component
S_RS_HIER -Administrator Workbench - ACTVT - Activity Display,

Hierarchy Analyze
RSHIENM - Hierarchy *
name
RSIOBJNM - *
InfoObject
RSVERSION - *
Hierarchy version
3.2.2 Creating/refreshing a WebI query/report
Object class Object Fields Values
AAAB S_RFC ACTVT - Activity Execute
Cross-application Authorization Check for RFC Access RFC_NAME – Name RSOB, RZX2,
Authorization of RFC to be SYST
Objects protected
RFC_TYPE - Type of FUGR

RFC to be protected
RS S_RS_COMP ACTVT - Activity Create or

generate,
Business Information Business Explorer -Components Display,
Warehouse Execute
RSINFOAREA - *
InfoArea
RSINFOCUBE - *
InfoCube
RSZCOMPID – ID of *
reporting component
RSZCOMPPTP - Type All values

of reporting
component
S_RS_COMP1 ACTVT - Activity Display,

Execute
Business Explorer - Components:
Enhancements to the Owner RSINFOAREA - *
InfoArea
RSINFOCUBE - All values

InfoCube
RSZOWNER – RS *
Owner (Person
Responsible)
S_RS_HIER ACTVT - Activity Display,

Analyze
Administrator Workbench - Hierarchy
RSHIENM - Hierarchy *
name
RSIOBJNM - *
InfoObject
RSVERSION - *
Hierarchy version
S_RS_ICUBE ACTVT - Activity Display
Administrator Workbench -InfoCube RSICUBEOBJ - All values

InfoCube subobject
RSINFOAREA - *
InfoArea
RSINFOCUBE - *
InfoCube
4 Lifecycle management
When making changes to the structure of an InfoCube or BEx Query, it is often
necessary to update the universe definition for any universes based on that InfoCube or
Query. The Update OLAP Universe Wizard (accessible via the menu View -> Refresh
structure in the Universe Designer) makes this process relatively simple for most cases.
For details on lifecycle management, see the section OLAP universe lifecycle
management in the document Using SAP BW in Universe Designer
.
5 Common scenarios and decisions
While each overall implementation and individual reporting requirement is unique, most have
common elements. The following section details several common scenarios you will come
across and gives guidance on optimizing Universe, WebI Query, and BEx Query design within
each scenario.
5.1 Customizing BI Universe definition

While the default universe generated for a BI query or cube is usable, it contains a lot of
elements which are not strictly required for most reporting needs, and other elements which
are not defined optimally.
5.1.1 Removing unnecessary L00 objects

As specified in the section How BI characteristics are mapped and used in a universe, when a
characteristic has no active hierarchy, the L00 node will be All members, and will not provide
any reporting value. In this case, it is best to delete all L00 objects in order to reduce complexity
for the report designing users.
Even in cases where an active hierarchy does exist, the L00 objects may be unnecessary. In
cases where there is only one top-level root of the hierarchy, it may be desirable to remove the
L00 object for a hierarchy, unless it is necessary to report members which are not assigned in
the hierarchy.
5.1.2 Removing unused or redundant detail objects

It is recommended to remove or hide any detail objects from the Universe which are redundant
or unlikely to add any value to reporting, in order to prevent report designing users from
including them unnecessarily in queries.
5.1.3 Optimizing detail object syntax

For queries on BI universes that include only the key and medium name detail objects of a
dimension, it is possible to modify the generated syntax of the objects to improve query
performance, due to some internal details of the OLAP BAPI interface.
To modify the syntax:
1. Open the universe in Designer.

2. Double click the key detail object you want to modify.
3. In the Select text box on the "Definition" tab of the "Edit Properties" dialog box, change
the syntax to refer to the NAME attribute of the SAP characteristic.
For example, for the object L01 Customer Key, change the generated select syntax:
[Z_CUSTOM].[LEVEL01].[[2Z_CUSTOM]].[Value] to refer to the NAME attribute:
[Z_CUSTOM].[LEVEL01].[NAME]
4. Click OK to save the changes.
5. Follow the same steps for the name object. Change the syntax to refer to the
DESCRIPTION attribute of the SAP characteristic.
Web Intelligence XI 3.0 on SAP NetWeaver BI Customizing BI Universe definition 32

For example, for the object L01 Customer Medium Name, change the generated select
syntax:
[Z_CUSTOM].[LEVEL01].[[1Z_CUSTOM]].[Value] to refer to the DESCRIPTION attribute:
[Z_CUSTOM].[LEVEL01].[DESCRIPTION]
5.1.4 Adding keys to objects used in an LOV for filtering

As indicated in the sections below on filtering, it is sometimes important that objects which have
an LOV associated with them should always have a key which points to the underlying technical
name for the characteristic values represented by the objects. By default, all Dimension objects
automatically created when generating a BI universe have this defined. In cases where
customization has been done or where detail objects are used in this way, this will have to be
done manually as follows:
1. In the Universe Designer, double-click the object to be used.

2. Select the “Keys” tab.
3. Insert a key entry as follows:
• Character
• Key Type: Primary Key
• Select: [<characteristic>].[TECH_NAME], or
[<characteristic>].[LEVEL<xx>].[TECH_NAME]
For Example:
5.2 Scheduling vs. on-demand reporting

One of the first factors to consider when designing a report is whether it is necessary to have
the report run on-demand, or if the reporting need would be just as well met by having users
access a regularly scheduled instance of the report. In general, if is possible to minimize the
Web Intelligence XI 3.0 on SAP NetWeaver BI Scheduling vs. on-demand reporting 33

number of times a report is run against the BI system, it is desirable to do so. So, it is
recommended to use scheduling when practical.
The primary benefits of scheduling rather than viewing on-demand are:
• Vastly improved viewing response time for the user

• Overall reduction in burden on the BI system versus having many ad-hoc queries run.
Scheduling is not viable for reports which meet one of the following criteria:
• Report has a high level of interactivity, especially when the user will be prompted for values
which will filter a large portion of the results.
• Report makes use of drill, to the point that orders of magnitude more data would be
required to be read into the scheduled instance than would have been read in the user’s
combined initial view and likely drill workflows.
• Different users have different views of the data returned by a query, either due to
personalization or security reasons.
Given the above factors, in some cases it will not be clear whether a single scheduled instance
will result in a lesser load on the various processing systems than many smaller on-demand
viewing requests. In some cases, experimentation will be required to determine the best
approach.
Note that, regardless of whether scheduling or on-demand viewing is chosen for a given report,
it is still important to follow the recommendations laid out in the remainder of this document, in
order to minimize the hit on the BI system and WebI processing servers.
5.3 Hierarchies
5.3.1 Defining custom hierarchies in the Universe
Creating custom universe hierarchies in BI universes is fully supported and behaves the same
was as regular universe hierarchies.
5.3.2 Query Drill for hierarchies

Multiple hierarchies can be defined at the Characteristic level. They will be automatically
exposed in the universe. Universe Designer capabilities to define and maintain drill-down paths
in WebI should be leveraged to enable WebI users to drill down according to BI hierarchies as
with any other custom universe hierarchies. It is important to note that the Use Query Drill
option that is available in WebI Document Properties dialog helps to significantly improve the
drill down performance. Activating this option can make WebI behave more like BEx in terms of
fetching limited result sets when drilling down.
Therefore it must be kept activated when there is an expectation to have drill down
performance in WebI as fast as within BEx. Of course, WebI user preferences (General Drill
Options) also enables to prompt users for applying query filters when drilling.
Web Intelligence XI 3.0 on SAP NetWeaver BI Hierarchies 34

5.3.3 Hierarchies with linked nodes
Currently, using hierarchies which contain linked nodes can cause unexpected behaviour.
Specifically, if a node which is returned by the WebI query is a linked node, WebI may display
that node’s parent as the “original” parent node, rather than the parent who linked to that
node. This issue is currently under investigation.
5.4 Filtering
In all but the most basic cases, it is necessary to filter the data exposed by an InfoCube or BEx
Query in order to get the desired result. In most cases, there are several methods which may be
employed to filter the results. In many cases, the method applied will have a profound impact
on the overall performance of reports.
Generally, filtering requirements can be separated into two categories: Static filtering, which
will apply the same values each time the report is run, and Dynamic filtering, which will filter
results based on user or other input.
Filtering in the context of this section deals primarily with filtering based on filtering based on
characteristic member values and not filtering based on key figure values.
5.4.1 Static filtering of characteristic values
5.4.1.1 Static filtering with WebI Query filters

Defining filters in the WebI query panel rather than in the underlying BI query provides a lot of
flexibility and allows a single BI query and single Universe to be reused for many WebI reports.
By following a few simple guidelines, it is possible to implement quite well-performing queries
using static WebI filters.
Use Inclusive member filters rather than exclusive ones

Avoid using Not Equal To, Not In, Not between, etc. in the filter pane of the WebI query panel.
Due to the need to resolve filters to member-sets, these types of filters do not perform well.
When practical (typically in cases where the set of members selected is relatively small), replace
these types of filters with the inclusive equivalent. If this is not possible, consider doing the
filtering in the BI query (see Static filtering with BEx Query restrictions)
Filter on indexed values

In order to avoid the need to resolve member captions to member-unique names when viewing
(see Resolving of WebI query filters to member selection), ensure that any characteristics which
are filtered in WebI are filtered on indexed values. In order to ensure this, two things are
required:
1. The object which is being filtered must have a key associated with it. That key must be
the “technical name” of the underlying characteristic in BI. See
2. Adding keys to objects used in an LOV for filtering for details.
Web Intelligence XI 3.0 on SAP NetWeaver BI Filtering 35

3. The value(s) for the filter must be selected from the LOV, rather than being typed in
manually.
If both of the above criteria are not met, the value entered or selected will have to be resolved
to the member-unique name each time the report is run, causing needless overhead. The
degree to which this is important varies depending on the cardinality of the characteristic: low-
cardinality characteristics will not incur a severe penalty in doing member caption lookups. In
any case, doing these lookups will always incur some overhead.
5.4.1.2 Static filtering with BEx Query restrictions

When the suggestions in Static filtering with WebI Query filters cannot be practically followed, it
may be necessary to consider altering or duplicating the relevant BEx query to impose the
restriction. This has the advantage of always producing the best-performing report, but the
disadvantage of added maintenance overhead and the need for potentially more BEx queries
and Universes to be defined if the filtered values needed are not the same for all consumers of
the existing BEx query.
Note: It is not necessary to update your Universe after making this change to an existing BEx
Query.
5.4.2 Dynamic filtering of characteristic values

When filtering based on user selection of value(s), there are two basic approaches possible:
Defining the filter and prompt within the WebI query panel, or utilizing BEx Query variables.
5.4.2.1 Dynamic filtering with BEx query variables

As detailed in the section How BI variables are mapped and used in a universe, it is possible to
define variables within a BEx Query and these will be exposed as universe prompts. There is a
performance incentive to using this approach, as BI has some internal optimizations for handling
variable-based restrictions.
Using variables rather than WebI filters also has the potential advantage of requiring less
maintenance of prompt definitions, in cases where multiple reports source the same universe,
and share some of the same prompted filtering requirements. Of course, in cases where
different WebI reports have very similar data requirements but slightly differing
prompting/filtering requirements, it may be preferable from a maintainability perspective to use
a base query with no variables and implement the prompted filtering in the WebI queries
instead.
To replace existing WebI filters with BEx Query variables:
• Replace WebI “Equal to” filters with Single value BEx Query variables.
• Replace WebI “InList” filters with Multi value BEx Query variables.
• Replace WebI “Between” filters with Range BEx Query variables.
Note: It is necessary to update your universe after making this change to a BEx Query.
Web Intelligence XI 3.0 on SAP NetWeaver BI Filtering 36

5.4.2.2 Dynamic filtering with WebI filters
When filtering on high cardinality characteristics, in order to avoid the need to resolve member
captions to member-unique names when viewing (see Resolving of WebI query filters to member
selection), ensure that any characteristics which are filtered in WebI are filtered on indexed
values. In order to ensure this, two things are required:
1. The object which is being filtered must have a key associated with it. That key must be
the “technical name” of the underlying characteristic in BI. See
2. Adding keys to objects used in an LOV for filtering for details.
3. The value(s) for the filter must be selected from the LOV, rather than being typed in
manually.
4. The prompt must be configured to “Select only from list” in the prompt options dialog.
If all of the above criteria are not met, the value entered or selected will have to be resolved to
the member-unique name before the report is run, causing needless overhead. The degree to
which this is important varies depending on the cardinality of the characteristic: low-cardinality
characteristics will not incur a severe penalty in doing member caption lookups. In any case,
doing these lookups will always incur some overhead.
Note: There is one case when the above recommendation to always use technical names as
keys for filtering is invalid. When working with multiple WebI queries in a single document,
WebI will share the prompt for filters in different queries which share the same prompt name.
In the case where this sharing is desired and the underlying characteristic being filtered is not
from the same InfoObject for both queries, it is essential to not have a key specified for the
Universe object being filtered, as doing so will result in the technical name for the first object
being used, which will not be a valid identifier for the other object (based on a different
underlying InfoObject) being filtered. In the case where this sharing is not desired, it is
necessary to simply name the two prompts differently.
5.4.3 Large LOVs for prompting

When generating an LOV for prompting on high cardinality characteristics, even retrieving the
member set for the LOV can be very expensive. In such cases, the user will commonly have to
use the search functionality in the prompt page in order to find the desired values. If it is not
necessary to present the user with an initial list to choose from, it may be desirable to enable
delegated search for the characteristic in the LOV. This will force the user to enter a pattern to
match before any LOV values are returned, and will only request the member set from BI which
matches the user’s specified pattern.
Delegated search is enabled in the Properties tab of the object properties dialog in the Universe
Designer.
5.5 Reports with high data volume

The OLAP BAPI interface is not suitable to be used for queries which return a high volume of
data in a single request. This is due both to internal limitations within the OLAP processor and
Web Intelligence XI 3.0 on SAP NetWeaver BI Reports with high data volume 37
to the flattening process which occurs before the data can be consumed by WebI. The volume
of data returned can be measured by the number of cells returned. In general, it is desirable to
reduce this number to the minimum required for the reporting requirement. This can be done
by reducing the number of columns or rows returned in the request.
5.5.1 Reducing the size of rows by optimizing WebI queries
5.5.1.1 Remove unused fields from the query

While this may seem simple and not obviously necessary, it can have a profound impact. During
the process of WebI query and report creation, it is possible that fields may have been added in
the query panel which are not actually used in the report. It is very important to review the
query definition before publishing a document, and remove any fields from the query definition
which are not actively used or desired to be made available during analysis. WebI will not
optimize the query at run-time to remove those fields which are not required.
It may also be desirable to customize the universe definition to remove any dimension or detail
objects which are found to be redundant, avoiding the possibility of a user inserting multiple
versions of the same thing into a report.
5.5.1.2 Refactor queries to extract more constant master data

When creating reports which contain a lot of rows of data and display a lot of master data
columns (typically WebI Detail objects / BI characteristic properties) which does not change per-
row, it is worth considering refactoring a single query into multiple queries to separate the more
constant master data from detail records. Note that it is important to weigh the inherent cost of
making additional queries against the savings realized by removing static master data from the
mass result set. This approach should only be used when the number of unique master data
values to be retrieved is at least an order of magnitude greater than the number of detail rows,
and the number of master data fields is relatively large.
Following is an example to illustrate this case:
The above screenshot shows a query definition with Customer, Order Date, Order ID, plus a
couple of measures. Note that we are including 7 Detail objects from the Customer dimension.
Below is the report in which you can see that we have many detail rows for a single Customer
(City Cyclists).
Although the customer detail fields are only displayed once in the report, they are in fact
fetched and replicated once per row in the MicroCube. For each row in the resultset, the
number of cells returned will be 15:
• 2 for Order Date (index and value)

• 2 for Order ID (index and value)
• 1 for Delivered Value
• 1 for Order Quantity
• 9 for Customer (value, index, 7 detail cells)
If we assume there are 1000 rows returned per customer, then the number of cells in the result
set is 15,000 in this case.
Now, assume that we refactor this query into a master data query and a detail query as follows:
Master data query:
Notice that there is a Key Figure from the Detail query included in the Master Data query. This is
to ensure that only master data entries with corresponding data are returned by the Master
Data query. This is more important when your Master Data query contains more than one
characteristic (see Creating queries for Master Data reporting).
Detail Query:
The result in the Data pane of the WebI report panel is:
Notice that the two L01 Customer dimension object have been merged under a single L01
Customer object. To configure merged dimensions, right-click a dimension and select “Edit
Merged Dimension” (shown below).
At this point, a WebI report can be designed in the same way as the original example, but the
resulting number of cells returned per detail row will be 8:
• 2 for Order Date (index and value)

• 2 for Order ID (index and value)
• 1 for Delivered Value
• 1 for Order Quantity
• 2 for Customer (value, index)
The number of master data cells returned will be 9:
• 9 for Customer (value, index, 7 detail cells)
If we assume there are 1000 rows returned per customer, then the total number of cells in all
the result sets is now 8,000 (detail data) plus 9 (master data), a reduction of nearly 7,000 cells
when compared to the original design.
While this is a somewhat simplistic example, the concept is extensible to more complex
scenarios involving reporting off master data and a high number of rows of data.
5.5.2 Reducing the number of rows per request by using guided navigation
Another approach to reducing the number of cells returned per request, and indeed the total
number of cells, is to employ more guided navigation techniques in reporting, rather than
presenting the user with both high-level aggregates and details up front. This technique is
appropriate when the total set of data exposed by a report is vast, and the user is likely to be
interested in all of the highly aggregated data but only specific details. There are two main
methods to achieving this: Using Drill in the report, and using report linking.
5.5.2.1 Using Drill

Drill can be used within your WebI report as long as you have a hierarchy defined. It is possible
to use either BI hierarchies or custom hierarchies defined in the Universe for drill. In order to
have only the data for the current drill context fetched, rather than the entire dataset being
fetched up-front, ensure that “Use query drill” is checked in the WebI document properties.
As the query used to process the drill is essentially the same as any other filter request, it is
important to use ensure that objects to be used for drill also have an index defined when
drilling, as specified in the section Static filtering with WebI Query filters.
5.5.2.2 Using Report Linking

As another alternative to using drill, you may choose to use report linking. In this case, you
would define an initial report which contained only the highly aggregated levels of data which
the user will use to decide where more information is desired. Report linking is much more
flexible in that you may define links at any level desired, and reports linked to do not have to
maintain the same formatting (or indeed, have much data in common at all with the source
report). All that is required is a relationship between the data in the source context and the
data in the target.
It is important to follow the same techniques when linking to a report as are followed in the
other dynamic filtering cases specified in the section Dynamic filtering with WebI filters, in order
to avoid unnecessary member caption resolution in processing the query for the target report.
5.6 Creating queries for Master Data reporting

In order to create performant Master Data queries for reporting in WebI, it is necessary to
understand what each type of Master Data query will request from the BI system. Following are
three high-level types of Master Data queries:
Web Intelligence XI 3.0 on SAP NetWeaver BI Creating queries for Master Data 42
Field implementation guide reporting
5.6.1 Query containing a single level of a single characteristic
In this case, master data values will be read directly using OLAP BAPI calls, without executing
any MDX (and so without using the OLAP processor). This will result in all members being
returned, whether or not there are any corresponding entries in any fact tables for them. The
performance of such a query will be good, but may result in retrieving members which are not
relevant.
5.6.2 Query containing multiple levels of a single characteristic

In this case, values will be read by creating a simple MDX statement to get the relevant
members, with no measures included in the query. This will also result in all members being
returned, whether or not there are any corresponding entries in any fact tables for them. The
performance of such a query will be good, but may result in retrieving members which are not
relevant.
5.6.3 Query containing multiple characteristics

In this case, values will be read by creating an MDX statement including several characteristics
and all measures. The reason for this is that if no measures are included, the cross join of the
two characteristics will result in a Cartesian product, which delivers no value and is quite
expensive. Unfortunately, including all measures adds a lot of unnecessary calculation and
memory overhead, and can easily push the resultset over the million cell limit if there are many
measures.
As a result, it is recommended to add at least one measure to the WebI query. Note that the
result in this case will include only members which have data for at least one of the measures
included in the query. So it is important to include a sufficient set of measures to ensure that all
desired members are included, but no more measures than that.
5.7 Leveraging structures in a BEx query

The BEx Query Designer allows you to build custom structures as part of your BEx query. You
can think of a structure as a characteristic. However, structural components can be complex
objects (selections, formulas…).
A classic example of a structure would be a structure comparing the actual and planned
amounts of a key figure.
As shown below you can identify a structure which shows the Actual Amount and the Planned
Amount of the key figure Amount. The two elements of the structure are selections where the
key figure Amount is restricted to the type Actual or Planned.
Web Intelligence XI 3.0 on SAP NetWeaver BI Leveraging structures in a BEx query 43

The additional two items in the structure are formulas which calculate the variance between the
two amounts and the variance as a percentage value.
5.7.1 Queries with multiple structures

One BEx query can contain up to two structures. In the case where the user creates a query
which contains two structures, the user created a query that creates a very well defined
resultset which will – based on the definition – result in a grid layout.
The query in the above screenshot contains two structures:
 The first structure is a grouping of countries into specified groups: USA, Europe, and Asia
Pacific.
 The second structure contains three keyfigures.
 In addition, the query contains three additional characteristics in the free characteristic
area.

For reporting purposes the usage of a custom structure can help to provide the right
information for the report at the “correct” level.
As a concrete example – lets assue the original query returns the following resultset
Calendar
Country Region Month Sales Amount Costs
USA NY 01 100 50
USA WA 02 200 50
Canada BC 02 300 50
Canada AB 04 200 50
Germany 04 100 50
France 02 200 50
By now creating a query with two structures you could create the following resultset:
Sales
Sales Area Q1 Q2
North America 600 200
Europe 200 100
In this case North America is a representation of USA and Canada, Europe is a representation of
Germany and France; the Sales amount have been aggregated for the first and second quarter.
Depending on the actual requirements for the reporting landscape this capability can become
very helpful because of multiple reasons:
 A structure will leverage the underlying SAP backend to perform the calculation and
aggregation
 A structure can be shared across multiple queries, which reduces the amount of
required maintenance
 By using a structure in the underlying source every user will receive an identical
definition of the summarized and combined values
When using a query with multiple structures, the resulting WebI query will be representative of
this grid layout.

6 BI Performance tuning
This section deals with some aspects of performance tuning within the BI system itself, which
have a significant effect on reporting performance. This is intended mainly to highlight some of
the key areas. For details on all aspects of tuning BI performance for reporting, refer to the
appropriate BI documentation.
6.1 Performance impact of data modelling

6.1.1 Line item dimension and high cardinality
When compared to a fact table, dimensions ideally have a small cardinality. However, there is an
exception to this rule. For example, there are InfoCubes in which a characteristic document is
used, in which case almost every entry in the fact table is assigned to a different document. This
means that the dimension (or the associated dimension table) has almost as many entries as the
fact table itself. We refer here to a degenerated dimension. You can use the indicators line item
and high cardinality to execute the following optimizations:
...
Line item:
This means the dimension contains precisely one characteristic. This means that the
system does not create a dimension table. Instead, the SID table of the characteristic
takes on the role of dimension table. Removing the dimension table has the following
advantages:
 When loading transaction data, no IDs are generated for the entries in the
dimension table. This number range operation can compromise performance
precisely in the case where a degenerated dimension is involved.
 A table- having a very large cardinality- is removed from the star schema. As a
result, the SQL-based queries are simpler. In many cases, the database optimizer
can choose better execution plans.
Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot

subsequently include additional characteristics. This is only possible with normal
dimensions.
High cardinality:
This means that the dimension is to have a large number of instances (that is, a high
cardinality). This information is used to carry out optimizations on a physical level in
depending on the database platform. Different index types are used than is normally the
case. A general rule is that a dimension has a high cardinality when the number of
dimension entries is at least 20% of the fact table entries. If you are unsure, do not
select a dimension having high cardinality.
Web Intelligence XI 3.0 on SAP NetWeaver BI Performance impact of data modelling 46

A simple way to retrieve the necessary information is to leverage the program
SAP_INFOCUBE_DESIGNS.
A very generic rule is that the dimension table should not take more than 10% of the
fact table.
Sample screenshot from SAP_INFOCUBE_DESIGNS:
6.1.2 Navigational Attributes

Characteristic attributes can be converted into navigational attributes. They can be selected in
the query in exactly the same way as the characteristics for an InfoCube. In this case, a new
edge/dimension is added to the InfoCube. During the data selection for the query, the data
manager connects the InfoProvider and the master data table (‘join’) in order to fill the Query.
From a pure performance point of view, you should model an object on a characteristic rather
than on a navigational attribute, because:
 In the enhanced star schema of an InfoCube, navigational attributes lie one join further out
than characteristics. This means that a query with a navigational attribute has to run an
additional join (compared with a query with the same object as a characteristic) in order to
arrive at the values. This is also true for DataStore objects.
 For the same reason, in some situations, restrictions for particular values in the navigational
attribute (values that have been defined in the query) are not taken into account by the
database optimizer when it creates run schedules. This can result in inefficient run
schedules, particularly if the restrictions are very selective. In most cases, you can solve this
problem by indexing the navigational attribute in the corresponding master data tables (see
below).
Web Intelligence XI 3.0 on SAP NetWeaver BI Performance impact of data modelling 47

 If a navigational attribute is used in an aggregate, the aggregate has to be adjusted using a
change run as soon as new values are loaded for the navigational attribute (when master
data for the characteristic belonging to the navigational attribute is loaded). This change run
is usually one of the processes critical to the system performance of a productive BI system.
This is why avoiding using navigational attributes, or not using navigational attributes in
aggregates, you can improve the performance of this process. On the other hand, not using
navigational attributes in aggregates can lead to poor query response times. The data
modeler needs to find the right balance
6.2 Overall reporting performance

6.2.1 Query monitor
The Query monitor is a tool which allows administration, testing and monitoring of SAP BI
Queries. The tool can be used to generate, test and configure properties (SAP documentation
for the Query monitor :
http://help.sap.com/saphelp_nw70/helpdata/EN/a0/2a183d30805c59e10000000a114084/cont
ent.htm)
The Query monitor can be started using the transaction RSRT.
6.2.1.1 Read Mode

In the Query Properties dialog box for the query monitor you can make settings for a BI query
with regard to the read mode, the cache mode, the selection of structure elements, the
optimization mode and the calculation accuracy. You can switch off the default Parallel
Processing for queries on a MultiProvider
The read mode determines how the OLAP processor gets data during navigation. You can set the
mode in Customizing for an InfoProvider and in the Query Monitor for a query.
The following types are supported:
Query to be read when you navigate or expand hierarchies (H)
The amount of data transferred from the database to the OLAP processor is the smallest
in this mode. However, it has the highest number of read processes.
In the following mode Query to read data during navigation, the data for the fully
expanded hierarchy is requested for a hierarchy drilldown. In the Query to be read when
you navigate or expand hierarchies mode, the data across the hierarchy is aggregated
and transferred to the OLAP processor on the hierarchy level that is the lowest in the
start list. When expanding a hierarchy node, the children of this node are then read.
Web Intelligence XI 3.0 on SAP NetWeaver BI Overall reporting performance 48

You can improve the performance of queries with large presentation hierarchies by
creating aggregates on a middle hierarchy level that is greater or the same as the
hierarchy start level.
Query to read data during navigation (X)
The OLAP processor only requests data that is needed for each navigational status of the
query in the Business Explorer. The data that is needed is read for each step in the
navigation.
In contrast to the Query to be read when you navigate or expand hierarchies mode,
presentation hierarchies are always imported completely on a leaf level here.
The OLAP processor can read data from the main memory when the nodes are
expanded.
When accessing the database, the best aggregate table is used and, if possible, data is
aggregated in the database.
Query to read all data at once (A)
There is only one read process in this mode. When you execute the query in the
Business Explorer, all data in the main memory area of the OLAP processor that is
needed for all possible navigational steps of this query is read. During navigation, all
new navigational states are aggregated and calculated from the data from the main
memory.
Read Mode Advantages Disadvantages Recommendation
Read all data  Fast query  First call will be  Should be used
navigation after slower for smaller
the first call  Limitation in the InfoCubes only
because all the use of aggregates  Should only used
data is being  More memory in for queries with
cached the OLAP cache few free
required characteristics
Read data during  First call will be  Requires  Should be used

navigation fast because only additional call for for small
required data is further navigation hierarchies
being selected steps  Should be used
 Good usage of with larger
aggregates quantities of
 Good response results

for small
hierarchies
Read data when  First call will be  The smalles  This mode should
navigate or expand fast because only amount of data is be used to
hierarchies required data is being selected for leverage
being selected the first call hierarchy
aggregates
6.2.1.2 Performance Information in the query monitor

As part of the Query Monitor you are able to retrieve some performance information by using
the “Performance Info” button.
The system displays performance-relevant information for the query that do not correspond to
the system recommendations ( ). The information refers to the following areas:
Query definition:
Query cannot use aggregates (corresponds to specifications in “Technical Information”

under OLAP-Relevant Data) and is related to the read mode X or A.
Query cannot use the cache (corresponds to specifications in Technical Information

under OLAP-relevant Data).
InfoProvider:
 InfoProvider is a MultiProvider
 Database statistics need to be checked
 Database indexes need to be checked
Especially the last set of information on the InfoProvider could help in regards to
increase the performance when it might be necessary to verify the Database statistics
(could lead to new aggregates) and the Database indexing.
6.2.1.3 Debugging options in the query monitor

As part of the Query Monitor you have the option to activate the debugging for the query and
you can select from a large set of options.

The option to “Display Statistics Data” in the “Others” area is very helpful because it will show
you in a very simple way where the time is being spend during the process of a BI Query.
Below an example of the display after the execution of a BI Query:

The numbers shown will also show up in transaction ST03 but in case you only need the
information for one particular case this might be much easier.
Especially the information “QDBSEL” (database selected records) and “QDBTRANS” (transferred
number of records) is helpful in evaluating the need for aggregated data.
The measurements starting with “QTIMExx” are showing where the time was spend during the
process.
6.2.2 Transaction ST03

The Workload monitor (transaction ST03) allows you to quickly identify the statistics around
query performance from the BI System. Switch to the Expert Mode of the tool to get all available
functionality.

Navigate to the BW System Load area and you can retrieve the data based on cube or query
level.
A high ratio on “database selected records” and “Select. / Transfer.” Is an indication for a need
of further aggregated data.

6.3 Relevant SAP Notes
The following is a list of some SAP notes which are particularly relevant to addressing issues in
using WebI against BI. This is not an exhaustive list. For other notes, it is recommended to
check the release notes and/or supported platforms list.
Notes 1162416 and 1162349 for improving performance of caption resolution
Note 1170323 and 1230303 for improving performance when working with BI hierarchies.
Note 1161911 for general OLAP BAPI performance
Web Intelligence XI 3.0 on SAP NetWeaver BI Relevant SAP Notes 54

7 Troubleshooting
In this section, you will learn about the tools that are available to you to troubleshoot and trace
the SAP connectivity for Web Intelligence.
7.1 Tracing and troubleshooting the Web Intelligence connectivity

To be able to trace the SAP connectivity for Web Intelligence the necessary registry entries need
to be configured.
The entries can be found in the following part of the registry:
• HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\MDA\Log.
The image shows that underneath the Log entry, each module of the OLAP connectivity can be
configured for tracing.
For the SAP connectivity, the relevant registry values are:
• HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite
12.0\MDA\Log\Modules\SAPMODULE
o Verbosity (highest value is 10 decimal).
o MDX Query Log (full path to the logfile).
• HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\MDA\Log
o LogFile (full path to the logfile).
These traces are instrumental when troubleshooting or merely seeking to understand what is
happening between the lowest level of the Business Objects XI 3.0 stack and the BI system.
However, at the highest verbosity levels the axis and member data is written to the log,
potentially incurring a significant runtime penalty.
The recommendation is to use the following trace levels:
 0 for production systems

 5 during general development and UAT
 10 only when troubleshooting
Web Intelligence XI 3.0 on SAP NetWeaver BI Tracing and troubleshooting the Web 55
Field implementation guide Intelligence connectivity
These settings will generate two log files:
• An MDA log file that includes all steps that have been performed on the SAP server side.
• A MDX log file that includes all executed MDX statements.
Note: After setting the registry value the corresponding services from BusinessObjects
Enterprise need to be restarted (Web Intelligence services, Connection Server)
7.2 Additional troubleshooting tools

This section covers additional tools and techniques used to troubleshoot BI connectivity:
• OLAP BAPI functions

• The OLAP trace tool RSRTRACE
• The MDX Test editor (transaction MDXTEST)
7.2.1 Using OLAP BAPI functions

The connectivity for SAP NetWeaver BI is based on OLAP BAPI functions from SAP. These BAPI
functions can be executed using transaction SE37 (Function builder). Each of the BAPI functions
is different and accepts a different set of input parameters and will provide a different resultset.
When getting unexpected results from the flow outlined in
Web Intelligence XI 3.0 on SAP NetWeaver BI Additional troubleshooting tools 56

APIs used in creating an OLAP Universe or Process flow for viewing a Web Intelligence report, it
may be desirable, in combination with analyzing the log files, to verify the results of some of the
BAPI functions from within the SAP GUI.
The following are two outlines showing how to use the OLAP BAPI functions. Note that the
values specified for the parameters are to be replaced with values relevant to your
troubleshooting task.

To call the BAPI function BAPI_MDPROVIDER_GET_CUBES
1. Start the SAP Logon pad.

2. Log onto the SAP system.
3. Start transaction SE37 (Function Builder).
4. Enter the function name BAPI_MDPROVIDER_GET_CUBES into the field Function module.
5. Select the menu Function Module > Test > Single Test (an alternative is pressing F8).
Note: In the given scenario the BAPI function allows you to specify input values.
6. Enter the input parameters.

7. Select the menu Function modules > Execute (F8).
8. Click on the icon next to the number of entries for your resultset.

Note: You can export the resultset via the menu System > List > Save > Local file.

To call the BAPI function BAPI_MDPROVIDER_GET_MEMBERS
1. Start transaction SE37 (Function Builder).

2. Enter the function name into the field Function module.
3. Select the menu Function Module > Test > Single Test (an alternative is pressing F8).
Note: In the given scenario the BAPI function allows you to specify input values.
• CAT_NAM The technical name of the Catalog, which is the technical name of the
cube. For example: Z_BOBJ
• CUBE_NAM The technical name of the query in the syntax CUBE/QUERY. For
Example: Z_BOBJ/UBI_TRAIN_QUERY_SIMPLE
• DIM_UNAM The member unique name of the dimension.For example: [Z_COUNTRY]
• HRY_UNAM The unique name of the hierarchy.
• LVL_UNAM The unique name of the level.
• LVL_NUMBER The numeric level number.
• START_ROW The numeric value for a starting row.
• END_ROW The numeric value for a row.
4. Enter the input parameters.

5. Select the menu Function modules > Execute (F8).
6. Click on the icon next to the number of entries for your resultset.
Note: You can click Single Entry to view all values for one row.
7.2.2 Using the OLAP trace tool (RSRTRACE)

The OLAP trace tool allows you to trace all OLAP related functions on the BI server. The benefit
of the tool is that the actual trace is stored on the BI server and in this way the steps can be
recalled.
To activate the OLAP trace
1. Start the SAP Logon pad.

2. Log onto the SAP system.
3. Start transaction RSRTRACE.
4. Enter the user name into the field User.

5. Click Activate User.
6. Perform the tasks that have to be traced.
To view the results of an OLAP trace
1. Start transaction RSRTRACE.

2. Click All Logs.
Note: The option User logs shows the logs that belong to the current user.
Note: A list of logs is displayed and the administrator is able to view them.
5. Double-click the log entry.

Note: All used functions are listed and can now be entered via the ABAP debugger.
7.2.3 MDX Testeditor

By using the MDX Testeditor the user can test BEx queries by entering an MDX statement. You
may use this to simply test that the query you are reporting off has data, or to validate the
results returned by the MDX generated as a result of a WebI query. The example below uses a
function of the MDX Testeditor to generate a sample MDX statement for a query. For details on
retrieving the MDX generated as a result of a WebI query, see the section Tracing and
troubleshooting the Web Intelligence connectivity or Using the OLAP trace tool (RSRTRACE).
To start the MDX Testeditor:
1. Log onto the SAP server.

2. Start transaction MDXTEST (MDX Testeditor).
Note: In the MDX Testeditor the phrase CATALOG refers to the BI cube and the phrase CUBE
refers to the BEx query.
3. Select the BI cube from the list box CATALOG.
Note: The entry InfoProvider refers to the option to connect directly to cubes without the usage
of a BEx query.

4. Select the BEx query from the list box CUBE.
Note: The screen shows all available elements of the select BEx query.
5. Click Generated Test Sequence.
Note: The MDX Testeditor generates a MDX test sequence. The test sequence includes all
measures (key figures) and one characteristic (dimension).

6. Click Run Query Multidim. to execute the MDX Statement.
Note: The partial results of the MDX Statement are displayed in the bottom pane of the MDX
Testeditor.
7.3 Troubleshooting scenarios

The following is a list of potential problem scenarios that and some recommendations on
identifying the issue.
7.3.1 Scenario 1: Dimensions are missing in the SAP OLAP Universe

In the following scenario we will assume that the user was able to create an OLAP Universe
based on top of the BEx Query but the Universe is missing one or more dimensions.
In this case you should use the following steps to identify the issue:
• Identify the technical name of the query. You can easily identify the technical name of the
cube and query in the BEx Query Designer or in the log file.
• Start transaction SE37 and execute function BAPI_MDPROVIDER_GET_DIMENSIONS.
Do all dimensions of the BEx Query show up in the result set?
Does the result set match the Universe?
• In case you receive less dimensions than expected (keep in mind that dimensions from the
“Filter” area of the BEx Query will not show up in the OLAP Universe) in the BAPI Function
Web Intelligence XI 3.0 on SAP NetWeaver BI Troubleshooting scenarios 65

you should switch on the traces for the MDA.log (see Tracing and troubleshooting the Web
Intelligence connectivity) and send the log file and a screenshot of the query to TechSupport.
• In case you receive error messages in the BAPI Function it indicates an error that should get
transferred to SAP TechSupport. Please work with BusinessObjects TechSupport to open a
case with SAP’s TechSupport in the customer’s name.
7.3.2 Scenario 2: SAP Variables are not showing up in Web Intelligence

In this scenario we will assume that the user was able to create the OLAP Universe but the user
is missing a prompt for a SAP Variable.
• As a first step open the Query in the SAP BEX Analyzer and verify for which items the user is
getting prompted and compare it with Web Intelligence.
• Make sure the dimension for the prompt is actually used in the Query Panel for Web
Intelligence (Web Intelligence will always prompt the user for mandatory SAP variables but
the user will only get prompted for optional SAP Variables in case the dimension is part of
the Web Intelligence query).
• Open the Universe in the Universe Designer and verify if the LOV definition shows up in the
Universe itself
• In case you still are not getting prompted and SAP BEx Analyzer is prompting the user, start
transaction SE37 and execute the function BAPI_MDPROVIDER_GET_VARIABLES.
• Switch on logging and create a new Universe based on the query and examine the log file.
7.3.3 Scenario 3: Values are missing in the List of Values for prompting
In this scenario we will assume that the List of values shown in Web Intelligence does not match
the List of Values shown in SAP Business Explorer – Web Intelligence is missing some members.
• as a first step create a new query without the SAP Variable and generate a Web Intelligence
report for the dimension that is using the SAP Variable to see if the value shows up without
using an SAP Variable
• Switch on logging and execute the report with the SAP Variable and search the log file for
the value that should be part of the List of values.
• Open the Logfile and search for “<DPCOMMANDS”. There is an XML definition for each
prompt and one for the report. After the XML Definition for the prompt the values are
loaded and shown in the log file.
• You can also use the function BAPI_MDPROVIDER_GET_MEMBERS to verify the List of
values.
• In case you want to verify a single missing value you can also use the function
BAPI_MDPROVIDER_GET_MEMBERS and provide as much input values as possible.
Example:

In this example the function is called for the BEx Query Z_BOBJ/QRY_SIMPLE_TEMPLATE,
dimension [Z_COUNTRY] and the member [Z_COUNTRY].[000000000000000000000000000008]
for this dimension.
This would verify if the member exists in the SAP system for the selected dimension.
7.3.4 Scenario 4: Data is missing when executing the report

In this case we assume that the Universe is correct and that the user can see all SAP Variables
correct, but that the report when executed is not providing any data.
• As an initial step run the query inside the SAP BEx Analyzer with identical user credentials
and identical SAP Variable values to see if data exists and if data gets returned for the
selected parameter values.
• If that is the case activate logging and execute the report again.
• When the report has been finished open the MDA log file and search for the wording
“MDDataSetBW.SelectData”
• You should see above that line an MDX Statement
• Use this MDX Statement and run the MDX Statement in transaction MDXTEST. Make sure
the MDX statement “makes sense”. What is meant by that?
• Open the MDA log and search for the text “<DPCOMMANDS”. In case the report makes use
of SAP Variables you will see this multiple times (once for each prompt and once for the
report).
You should see something similar to this :
<DPCOMMANDS>
<DPCOMMAND>
<DP>
<QUERY>
<QUERYRESULT>

<QUERYOBJECT KEY="[Z_CUSTOM].[LEVEL01].[CAPTION]" />
<QUERYOBJECT KEY="[Z_CITY].[LEVEL01].[CAPTION]" />
<QUERYOBJECT KEY="[Z_COUNTRY].[LEVEL01].[CAPTION]" />
<QUERYOBJECT KEY="[Measures].[AWUNOIYT142BYXSX5WBW4TU60]" />
<QUERYOBJECT KEY="[Measures].[3UKX2OXIATD91FHR2T3YAGSLQ]" />
<QUERYOBJECT KEY="[Measures].[4XFOLB6LWDUD6AASDRPQN8TGD]" />
<QUERYOBJECT KEY="[Measures].[1440135PLJGNL69G88PAXJCBF]" />
</QUERYRESULT>
<QUERYSCOPE />
<QUERYCONDITION>
<WHERE/>
</QUERYCONDITION>
</QUERY>
</DP>
</DPCOMMAND>
</DPCOMMANDS>
The items in “QUERYOBECT” should be the items you selected in the query panel for your
report.
In case you made use of filters or SAP Variables you should find items in the QUERYCONDITION
area as well.
So in this case the MDX Statement should at least include Z_CUSTOM, Z_CITY, Z_COUNTRY and
4 Key figures, for example:
SELECT NON EMPTY {[Measures].MEMBERS} DIMENSION

PROPERTIES PARENT_UNIQUE_NAME ON COLUMNS ,
NON EMPTY CROSSJOIN( CROSSJOIN( HIERARCHIZE( {
[Z_CUSTOM].[LEVEL01].MEMBERS } ) , HIERARCHIZE( {
[Z_CITY].[LEVEL01].MEMBERS } ) ), HIERARCHIZE( {
[Z_COUNTRY].[LEVEL01].MEMBERS } ) ) DIMENSION PROPERTIES
PARENT_UNIQUE_NAME ON ROWS FROM
[Z_BOBJ/QRY_SIMPLE_TEMPLATE]


Web Intelligence On SAP Implementation Best Practices

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Intelligence On SAP Implementation Best Practices

Uploaded by

Copyright:

Available Formats

Web Intelligence XI 3.

Field implementation guide

Confidential and Proprietary

1.1 Intended audience........................................................................................................... 5

1.2 Assumptions .................................................................................................................... 5

1.3 References ....................................................................................................................... 6

2 Useful concepts ....................................................................................................................... 7

2.1 SAP NetWeaver BI Modelling concepts........................................................................... 7

2.1.1 BI InfoCubes as data sources ................................................................................... 7

2.1.2 BEx Queries as data sources .................................................................................... 7

2.2 Mapping SAP NetWeaver BI concepts to Universe concepts.......................................... 9

2.2.1 How BI characteristics are mapped and used in a universe .................................. 11

2.2.2 How BI key figures are mapped and used in a universe........................................ 11

2.2.3 How BI hierarchies are mapped and used in a universe ....................................... 12

2.2.4 How BI variables are mapped and used in a universe........................................... 14

2.3 Under the hood – BI OLAP Universe processing details ................................................ 21

2.3.1 The OLAP BAPI as an interface to BI ...................................................................... 21

2.3.2 APIs used in creating an OLAP Universe ................................................................ 22

2.3.3 Process flow for viewing a Web Intelligence report.............................................. 23

3 Security integration ............................................................................................................... 25

3.1 Authentication ............................................................................................................... 25

3.1.1 SAP login in Universe Designer .............................................................................. 25

3.1.2 Universe connection settings ................................................................................ 25

3.1.3 Single Sign-On ........................................................................................................ 26

3.1.4 Secure Network Communication environments ................................................... 27

3.2 BI authorizations for OLAP BAPI access......................................................................... 27

3.2.1 Creating a new Universe from a query or a cube in a BI role................................ 28

3.2.2 Creating/refreshing a WebI query/report ............................................................. 29

5 Common scenarios and decisions ......................................................................................... 32

5.1 Customizing BI Universe definition ............................................................................... 32

5.1.1 Removing unnecessary L00 objects....................................................................... 32

5.1.2 Removing unused or redundant detail objects ..................................................... 32

5.1.3 Optimizing detail object syntax ............................................................................. 32

5.1.4 Adding keys to objects used in an LOV for filtering............................................... 33

5.2 Scheduling vs. on-demand reporting ............................................................................ 33

5.3.1 Defining custom hierarchies in the Universe ........................................................ 34

5.3.2 Query Drill for hierarchies ..................................................................................... 34

5.3.3 Hierarchies with linked nodes ............................................................................... 35

5.4 Filtering .......................................................................................................................... 35

5.4.1 Static filtering of characteristic values .................................................................. 35

5.4.2 Dynamic filtering of characteristic values ............................................................. 36

5.4.3 Large LOVs for prompting...................................................................................... 37

5.5 Reports with high data volume ..................................................................................... 37

5.5.1 Reducing the size of rows by optimizing WebI queries ......................................... 38

5.6 Creating queries for Master Data reporting .................................................................. 42

5.6.1 Query containing a single level of a single characteristic ...................................... 43

5.6.3 Query containing multiple characteristics............................................................. 43

5.7 Leveraging structures in a BEx query ............................................................................ 43

5.7.1 Queries with multiple structures........................................................................... 44

6.1 Performance impact of data modelling......................................................................... 46

6.1.1 Line item dimension and high cardinality ............................................................. 46

6.1.2 Navigational Attributes.......................................................................................... 47

6.2 Overall reporting performance ..................................................................................... 48

6.2.1 Query monitor ....................................................................................................... 48

6.2.2 Transaction ST03 ................................................................................................... 52

6.3 Relevant SAP Notes ....................................................................................................... 54

7.1 Tracing and troubleshooting the Web Intelligence connectivity .................................. 55

7.2 Additional troubleshooting tools .................................................................................. 56

7.2.1 Using OLAP BAPI functions .................................................................................... 56

7.2.2 Using the OLAP trace tool (RSRTRACE).................................................................. 61

7.2.3 MDX Testeditor...................................................................................................... 63

7.3 Troubleshooting scenarios ............................................................................................ 65

7.3.4 Scenario 4: Data is missing when executing the report ........................................ 67