Web Intelligence XI3 On NetWeaver BW (External)

SAP BusinessObjects Web Intelligence XI 3.
x and
SAP NetWeaver Business Warehouse
Implementation Best Practices
February 2009
©SAP AG 2009
SAP BusinessObjects Web Intelligence XI 3.x and SAP NetWeaver Business Warehouse
Table of Contents
1 Introduction..........................................................................................................................................................3
1.1 Intended audience........................................................................................................................................3
1.2 Assumptions.................................................................................................................................................3
1.3 References...................................................................................................................................................4
2 Useful concepts...................................................................................................................................................4
2.1 BW modelling concepts................................................................................................................................4
2.2 Mapping BW concepts to universe concepts................................................................................................7
2.3 BW OLAP universe processing details.......................................................................................................20
Note: All those BAPI calls are as well traced within the SOFA/MDA logs (see ‘Tracing and troubleshooting the
Web Intelligence connectivity’ for more details)................................................................................................21
3 Security integration............................................................................................................................................23
3.1 Authentication.............................................................................................................................................23
3.2 BW authorizations for OLAP BAPI access..................................................................................................26
4 Lifecycle management.......................................................................................................................................29
5 Common scenarios and decisions.....................................................................................................................30
5.1 Customizing BW universe definition............................................................................................................30
5.2 Scheduling vs. on-demand reporting..........................................................................................................32
5.3 Hierarchies..................................................................................................................................................33
5.4 Filtering.......................................................................................................................................................34
5.5 Reports with high data volume....................................................................................................................37
5.6 Creating queries for Master Data reporting.................................................................................................42
5.7 Leveraging structures in a BEx query.........................................................................................................43
6 BW Performance tuning.....................................................................................................................................45
6.1 Performance impact of data modelling........................................................................................................46
6.2 Overall reporting performance....................................................................................................................48
6.3 Relevant SAP Notes...................................................................................................................................54
7 Troubleshooting.................................................................................................................................................55
7.1 Tracing and troubleshooting the Web Intelligence activity..........................................................................55
7.2 Tracing and troubleshooting the OLAP driver connectivity (ODA)..............................................................58
7.3 Additional troubleshooting tools..................................................................................................................59
7.4 Troubleshooting scenarios..........................................................................................................................69
©SAP AG 2009 Page 2

1 Introduction
This document aims to provide guidance for a successful deployment of SAP BusinessObjects Web
Intelligence (WebI) XI 3.x as a front-end to SAP NetWeaver Business Warehouse1 (BW). It is intended
to guide the reader through the high-level concepts relevant to such an implementation, and to
highlight the best practices to consider in the course of such a deployment. The focus is on the factors
which are unique to using Web Intelligence with BW, 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 Web Intelligence reports against BW. In this context, maximizing performance refers to
a balance of minimizing:
• The processing required (both in Web Intelligence and BW)

• The memory footprint required (both in Web Intelligence and BW)
• 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 Web Intelligence for query, reporting, and analysis off BW.
1.1 Intended audience
The intended audience of this document is with SAP BusinessObjects customer or partner personnel
who are in charge of deploying Web Intelligence as a front-end to BW.
1.2 Assumptions
This document assumes that the reader is comfortable with basic SAP BusinessObjects universe
design and query, reporting, and analysis capabilities in Web Intelligence XI 3.x.
It also assumes that the reader has had in-depth exposure to BW and the SAP Business Explorer
(BEx) Suite. More specifically it is expected that the reader is familiar with BEx Query design using the
BEx Query Designer.
1
: SAP NetWeaver Business Warehouse (BW) is the new name for SAP NetWeaver Business Intelligence (BI). Best practices
documented in this guide apply to all versions of BW superior to 3.5.

1.3 References
Available from http://help.sap.com, SAP BusinessObjects area:
• Using SAP BW in universe Designer

• Designer’s Guide
• BusinessObjects XI Integration for SAP User's Guide
Available from http://service.sap.com/releasenotes, SAP BusinessObjects area (login required):
• BusinessObjects XI 3 Release Notes
Available from http://service.sap.com/bosap-support (login required):
• BusinessObjects XI 3 for SAP - Supported Platforms
Available from http://service.sap.com/bosap-instguides (login required):
• BusinessObjects XI Integration for SAP Solutions Installation and Administration Guide
2 Useful concepts
2.1 BW modelling concepts
When creating an SAP BusinessObjects universe based on a BW 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 Data Store Object (DSO)
• an InfoSet
• an InfoObject (Master Data)
Note: Once the universe has been created, it can be exported to the Central Management System
(CMS) as any other universe, and is then available to Web Intelligence users to run queries and
create reports.
2.1.1 BW InfoCubes as data sources
The following types of InfoCubes are supported as data sources for building universes:

• Standard and Transactional InfoCubes: data and metadata are physically stored in the same BW
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 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
BW customers use BEx Queries to access data through the BEx front-ends.
Note: In order to serve as a data source and become available through the SAP OLAP BAPI interface
to universes, BEx Queries must be “released for OLE DB for OLAP” (ODBO). 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 (DSO) can be exposed to universes via BEx Queries.
2.1.2.1 BEx Queries based on a DSO
Data Store Objects (DSO) are often used to manage detailed transactional-level data before it is
aggregated into InfoCubes. To include DSO in the BW data store design is a way to minimize
InfoCube size and improve loading and querying performance. DSO can be exposed to a universe via
a BEx Query.
Note: DSOs are usually large and detailed relational structures. Accessing DSO via the SAP OLAP
BAPI interface might not deliver the expected query performance. Direct access to DSO via BAPI calls
in Crystal Reports XI 3.x is an alternative to consider in order to meet end-user expectations for fast
report delivery.
Direct access to DSO is also now supported via Data Federator driver (this solution is for
BusinessObjects Enterprise XI 3.1 and FixPack1.1). Using Data Federator connection on DSO, a
relational universe is automatically generated that satisifies both performance and class universe
behavior. This is the recommended usage for Web Intelligence.

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 BW 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 2 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, Structures and SAP
Variables
• In the OLAP BAPI interface, not all BW metadata features can be retrieved on an InfoCube level,
as summarized in the following table:
BW metadata feature OLAP BAPI availability
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
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 included in the Web Intelligence query have no direct
impact on the query performance.
Note: SAP 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 BW universes
The result-set language is dependent on Unicode support in BW. 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 BW.
2.2 Mapping BW concepts to universe concepts
When you create a universe from either an InfoCube or a BEx Query, the Universe Designer product
maps BW OLAP structures to equivalent classes and objects in the universe. A SAP OLAP universe is
based on a single Query or InfoCube – different solutions must be considered to use a single universe
to join multiple Queries or InfoCubes2. Note that this section deals only with the default universe
created for an InfoCube or BEx Query. As explained in the section Customizing BW universe
definition, it is possible and sometimes highly recommended to customize this structure.
Note: The universe creation process is automatic once you have selected the connection. The
universe structure appears in the Universe pane. There is no table schema in the Structure pane.
Only one OLAP Universe is generated per cube, infoquery or infocube. OLAP Universes do not
support multiple cubes in the same Universe.
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 BW hierarchies.
For InfoCubes, all the dimensions, characteristics, key figures, and hierarchies are mapped. The
following table shows the universe objects created for each BW object.
The term “Dimension” is used differently between BW/BEx and universes/WebI. For BW/BEx 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 universe/Web Intelligence side the term “Dimension” is identical to a characteristic in BW/BEx.
2
: SAP BusinessObjects Data Federator can be implemented to federate multiple BW and non-SAP data sources in a single
universe. Please refer to the Data Federator product documentation for more information on these capabilities.

BW objects Universe/Web Intelligence 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 Class with single dimension object for the structure
Queries only)
Subclass with dimension and detail objects (identical to

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

Key Figure with dimension objects for units/currency, numeric
value and formatted value (based on User preferences)
Calculated Key Figure (BEx Queries only) Measure and dimension objects (same as Key Figure)
Restricted Key Figure (BEx Queries only) Measure and dimension objects (same as Key Figure)
Pre-defined Filter in the universe

In the class for the dimension to which the variable
Variables (BEx Queries only) applies, 2 dimension objects supporting the list of
values (value help): one for caption, one for
description.
5 Universe parameters defining key date variable in the

Key date variable (BEx Queries only)
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 all Web
Intelligence queries based on this universe. If the characteristic has a variable defined, the variable is
mapped to a pre-defined filter object in the universe.

2.2.1 How BW characteristics are mapped and used in a universe
When no hierarchy is defined on the characteristic in the BEx Query or InfoCube, the Universe
Designer creates a class containing the characteristic as 2 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 BW is All members). The Level 01 dimension contains all
members for the characteristic as a flat list of values.
For each dimension object, the Universe Designer creates a detail object for the key, up to 3 detail
objects for the description (short, medium, and long descriptions), and a detail object for each display
attribute.
Navigational attributes applied 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 may impact the
overall performance (please refer back to SAP best practices for data modelling).
In fact, navigational attributes are used as dimensions in MDX query. Thus leads to lot of “Crossjoin”
operators (in the MDX statements) and might return thousands of useless rows.
Note: 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 BW 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 BW with either a currency or a unit characteristic. Based on the details
of the key figure, the Universe Designer creates up to 3 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' or
'€'.
• 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' or '345 €'.
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.
A sub-class having named the key figure name is created for each key figure defined in BW with either
a currency or a unit characteristic. Other key figures are created under the “key figures” class, see
figure below:

Note: Having a large number of key figures in the BEx query may 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 Web Intelligence 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 correction for this issue may become available in the future. Please consult
SAP customer support for information on availability.
2.2.3 How BW hierarchies are mapped and used in a universe
Hierarchies are mapped to allow Web Intelligence users to drill down according to BW hierarchies in
the same way as classic universe hierarchies.
BW hierarchies are slightly different than the classic definition of a hierarchy in a universe, though. In
BW, 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, the Universe Designer creates a
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, the Universe 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, the Universe 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. The 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 may
significantly improve drill-down performance.
Note: If you have a dimension object with Level 00 and Level 01, its definition in the universe is
[<Object_Name>].[LEVEL00] and [<Object_Name>].[LEVEL01]. After applying a hierarchy on this
object in the BEx query, running the Refresh Structure feature in Designer will list the elements that
are added and the ones that are removed. You might be surprised to see that the object (where you

applied a hierarchy) is part of the removed elements list and then of the added elements list. The
object name does not change while its own definition does change. Indeed its definition will be similar
to [<HIERARCHY_OBJECT_NAME>].[LEVEL00] (for the L00 Object) and
[<HIERARCHY_OBJECT_NAME>].[LEVEL01] (for the L01 Object).
A new feature that will be added in SP2 removes this limitation and takes into account the original
characteristic. That means that universe object is not hidden/deleted when the BEx query definition
changes are:
• Characteristic to hierarchy X
• Hierarchy X to hierarchy Y
• Hierarchy X to Characteristic
• Characteristic to Hierarchy variable
• Hierarchy X to Hierarchy variable
• Hierarchy variable to hierarchy X
• Hierarchy variable to Characteristic
Only objects corresponding to new levels or deleted levels can be added or deleted.
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 BEx Query contains 3 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,
this BEx Query display setting will not be reflected in a universe created on that query, though.
2.2.4 How BW variables are mapped and used in a universe
2.2.4.1 BW 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.
Note: Only BW 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 not be available as a filter in the universe.
The following types of BW 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
Formula Price, quota, and numeric values 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 BW variables.
Note: SAP BW only supports ONE Keydate variable per InfoQuery so that means only ONE Keydate
variable per Universe is supported.
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 node Supported N/A N/A Supported Supported
Note: The Exclude operator is not supported but can be replaced by “Not equal” or “Not in”: this is not
a recommended solution for performance reasons. 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 BW 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
WebI. Mandatory variables become mandatory prompts in Web Intelligence.
For characteristic variables, the Universe Designer creates a filter in the universe. For each filter, 2
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.
Note: If those objects are removed by mistake, either the user creates them manually or executes the
Refresh Structure feature but this last solution is not advised as the IDs of every object will be
regenerated and existing reports based on this universe might need to be recreated.
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 BW variable
This example shows the WHERE clause generated for a BW 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 BW 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, it is not necessary to
update the filter syntax because it will be automatically updated by the changes you have made on the
class or list of values.
Note: To avoid conflict between BW variables and filters defined by Web Intelligence users, it’s
important to be careful with which objects you allow users to use in defining Web Intelligence
conditions, as filtering the same characteristics in 2 places can cause unexpected results.
2.2.4.3 Mandatory Filters
There are 2 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.
BW variables are created as universe mandatory filters when generating OLAP universes on BW.
• Class: a class mandatory filter appears only if an item of the class or subclass 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 WebI.

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 class mandatory filter can reference list of values coming from objects that belong to other classes.
For instance you can create a class mandatory filter that prompts the user to select a period when an
object from the product class is selected.
A mandatory filter is hidden and cannot be selected in the Query Panel in WebI. In the Universe
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 then 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">
<CONSTANT
TECH_NAME="@Prompt('CO_CODE Char
Validate the code entered
User MultiSingle Man Def', 'A','Company
by a user in a prompt
code\Lov[BCOMUSI]Base',
multi,primary_key)"/>
</CONDITION>
</FILTER>
Note: In the case of an optional filter, the <OPTIONAL> tag is added before the <FILTER KEY> tag.
Example:
<OPTIONAL>
<FILTER KEY="[BCOMUSI]">
<CONDITION OPERATORCONDITION="InList">

<CONSTANT TECH_NAME="@Prompt('CO_CODE Char User MultiSingle

Man Def', 'A','Company code\Lov[BCOMUSI]Base',
multi,primary_key)"/>
</CONDITION>
</FILTER>
</OPTIONAL>
2.2.4.4 BW 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 BW 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 BW 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 2 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.
BW 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 BW
system.
The key date variable properties of the query are mapped to 5 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 key dates 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 Key date properties.
2.2.4.6 BW 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 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 expected for selecting a node from the correct hierarchy. This
behaviour might be improved in future releases.
Note: The hierarchy node variable is used to browse and pick one or more values of a specific
hierarchy.

2.3 BW OLAP universe processing details
In order to understand how to optimize universe and Web Intelligence query design for BW reports, it
is necessary to understand some of the processing that occurs while running a report based on a BW
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 an
OLAP universe for BW.
2.3.1 The OLAP BAPI as an interface to BW
The connectivity to BW is made through the SAP OLAP BAPI.
Note: The OLAP BAPI interface is based on MDX and so uses MDX-like terms to describe the various
constructs and concepts used. In some cases, this will differ from the representation in BEx.
This OLAP BAPI consists of 2 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 BW, and
returning the results. It consists of a number of RFC function modules (BAPI_MDDATASET_*).

2.3.2 APIs used in creating an OLAP universe for BW
The table below shows the functions within the OLAP BAPI which are used during the process of
creating an OLAP universe on BW. The order within the table also indicates the processing flow.
BAPI function called Purpose
BAPI_MDPROVIDER_GET_CATALOGS Retrieves the list of BW cubes
Retrieves the list of BEx queries based on the selected

BAPI_MDPROVIDER_GET_CUBES
cube
Retrieves the list of characteristics based on the

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

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

BAPI_MDPROVIDER_GET_LEVELS result of BAPI_MDPROVIDER_GET_HIERARCHYS as
input
BAPI_MDPROVIDER_GET_MEASURES Retrieves the key figures for the selected query or cube
Retrieves the list of display attributes for each

BAPI_MDPROVIDER_GET_PROPERTIES
characteristic
Retrieves data type information for the list of key figures

BAPI_IOBJ_GETDETAIL
and characteristics
BAPI_MDPROVIDER_GET_VARIABLES Retrieves the list of variables for the selected BEx query
Note: All those BAPI calls are as well traced within the SOFA/MDA logs (see ‘Tracing and
troubleshooting the Web Intelligence connectivity’ for more details).
2.3.3 Process flow for viewing a Web Intelligence report
The approximate process flow for viewing a Web Intelligence report off BW 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 BW. The order within the table also
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 the

BAPI_MDPROVIDER_GET_DIMENSIONS
dimension
Called for each referenced dimension to retrieve

BAPI_MDPROVIDER_GET_HIERARCHYS
the hierarchies

BAPI_MDPROVIDER_GET_LEVELS
the levels of the hierarchies

BAPI_MDPROVIDER_GET_PROPERTIES
the display attributes

BAPI_MDPROVIDER_GET_MEMBERS
the list of values (used for LOV)
BAPI_MDDATASET_SELECT_DATA Called to execute MDX statement for main 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 functions below are used simply to verify that the cube/query definition matches
what is expected.
2.3.3.2 Resolving of Web Intelligence 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 BW, 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. This resolution
of caption to member-unique name may take some times, particularly for high cardinality dimensions.
In some cases, this resolution may take as long as the processing of the generated MDX query in its
entirety. For more details on avoiding this, see .

Note: See the section on Relevant SAP Notes for reference to some potential performance
improvements in this area.
2.3.3.3 Processing of result set data for Web Intelligence MicroCube
The table above shows the flow which occurs up to the point when the BW system returns data to
Web Intelligence (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 Web Intelligence 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 may be time-consuming and memory-
intensive within the Web Intelligence processing server, and depending on the structure of the data
(hierarchy depths, etc.), may necessitate tuning the universe and/or Web Intelligence queries to
optimize.
We have released a fix pack (BOE XI 3.1 FP 1.2) that removes the bottlenecks mentioned above:
• XI 3.1 without FP 1.2 workflows:
• Read data from BW (relation warehouse): row set
• Transform row set into dataset and pass it to SAP OLAP engine
• SAP OLAP engine pass it to ODA
• ODA transform the data set into a row set and pass it to Web Intelligence
• XI 3.1 with FP 1.2 workflows:
• Read data from BW (relation warehouse): row set
• SAP BW pass the row set to ODA
• ODA pass the row ser to Web Intelligence
No useless transformation is applied.
3 Security integration
3.1 Authentication
In order to connect to the BW system to retrieve data, it is necessary for the user to be authenticated
against the BW system. This can be accomplished:
• By specifying and saving the BW 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.
Note: Select Use BusinessObjects credential mapping to use the user's BusinessObjects Enterprise
login credentials for the connection. If you then use this Authentication type, proceed as follows:
- Create and save a new user in the Central Management Console (CMC),
- Edit the properties of this newly created user (still in the CMC) and make sure to check the option
box "Enable Data Source Credentials for BusinessObjects Universes",
- Fill the SAP credentials (username and password) to use for the user that is created in the first step.
- Save the modifications and assign the needed rights to this user
- Run Designer and create a new connection towards a SAP datasource
- Use Authentication Mode "Use BusinessObjects Credential mapping"
- A list of cubes and queries should be then proposed.
3.1.1 SAP login in the 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 BW
with the SAP credentials used to logon to the Universe Designer, where possible. If SAP credentials
are not used when logging into the Universe Designer, it is not possible to design a universe
configured for SSO.
Note: This requires the SAP Authentication to be configured in the

SAP BusinessObjects Enterprise (BOE) Central Management
Console (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 BW 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 BW.

The connection life-time option can have a significant impact when working with BW. It is 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
To disconnect and reconnect in-between every transaction might lead to a performance overhead.
However, it is important to note that the OLAP BAPI interface builds a metadata cache on the client
side every time a connection to BW 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 close 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 (SSO)
When the user who is running a Web Intelligence report is defined as an SAP user on the BW system
used in the universe connection, SSO to the database may be possible.
The following criteria must be met for SSO:
• Universe connection is configured to use SSO

• Web Intelligence user connected is defined in BOE as an SAP user, or has an SAP user alias in
BOE, on the BW 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 BW and the BOE server processing the
request. Note that SNC support in Web Intelligence is available since the Fix Pack 2 of the
version XI 3.0.
3.1.4 Secure Network Communication environments
It is possible to configure Server-Side trust between the BOE processing servers and the BW system
using Secure Network Communication (SNC). As highlighted in the Single Sign-On section, using

SNC is the way to achieve SSO in cases where the user’s authentication against BOE is done with an
account on a system other than the BW system used by the query, or in schedule-time cases. For
details on configuring SNC, please refer to the section titled Configuring SAP Server-Side Trust in the
guide: BusinessObjects XI Integration for SAP Solutions Installation and Administration Guide
3.1.5 Scheduling
When scheduling a Web Intelligence document there is no option to enter credentials that will be used
for processing the query on the BW 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 BW authorizations for OLAP BAPI access
BW system or dialog accounts are fine to work with universes and WebI. However, this section
provides a list of SAP authorizations that are required to carry out common tasks with universes for
BW. Additional authorization objects or fields may be required, depending upon your individual
implementation. For more information on Authorizations for Data Warehousing in BW, 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.

3.2.1 Creating a new universe from a query or a cube in a BW role

Object Object Fields Values
class
AAAB – S_RFC – ACTVT - Activity Execute

Cross- Authorization
application Check for RFC_NAME – Name of RFC to be protected RSOB, RZX2,
Authorization RFC Access SYST
Objects
RFC_TYPE - Type of RFC to be protected FUGR
RS - S_RS_COMP ACTVT - Activity Create or

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

component
S_RS_HIER - ACTVT - Activity Display, Analyze

Administrator
Workbench - RSHIENM - Hierarchy name *
Hierarchy
RSIOBJNM - InfoObject *
RSVERSION - Hierarchy version *

3.2.2 Creating/refreshing a Web Intelligence query/report
Object class Object Fields Values
AAAB - S_RFC ACTVT - Activity Execute

Cross- Authorization
RFC_NAME – Name of RFC to be protected RSOB, RZX2, SYST
application Check for RFC
Authorization Access
RFC_TYPE - Type of RFC to be protected FUGR
Objects
RS - S_RS_COMP ACTVT - Activity Create or generate,

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

component
S_RS_COMP1 ACTVT - Activity Display, Execute

Business
Explorer -
Components:
RSINFOCUBE - InfoCube All values
Enhancements
to the Owner
RSZOWNER – RS Owner (Person *
Responsible)
S_RS_HIER ACTVT - Activity Display, Analyze

Administrator
RSHIENM - Hierarchy name *
Workbench -
Hierarchy
RSIOBJNM - InfoObject *
RSVERSION - Hierarchy version *
S_RS_ICUBE ACTVT - Activity Display

Administrator
RSICUBEOBJ - InfoCube subobject All values
Workbench
-InfoCube

4 Lifecycle management
When making changes to the structure of an InfoCube or BEx Query, it is often necessary to update
the universe definitions for all 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.
Starting the XI 3.x version, the Refresh Structure feature is available for any OLAP Universe. It allows
the Designer user to automatically update, add or remove the structure of the OLAP Universe. Starting
XI 3 version (it was not the case with the previous XI R2 release), the manual addition of objects,
classes, details, measures, calculated measures, pre-defined filters is now supported.
The life Cycle Management of OLAP Universes is only able to maintain the structure of the universes
that was automatically generated. All the objects that were manually added cannot be updated by the
OLAP change management tool.
As we now support the creation of Calculated Measures for SAP BW, we recommend to use as much
as possible the following Designer functions:
 @SELECT
 @PROMPT
 @VARIABLE
 @WHERE
Note: @AGGREGATE_AWARE function is not supported by OLAP Universes.
Measure metadata used in a MDX statement must refer to its Unique Name or Technical Name
It is recommended:
 To always generate and set the Index Awareness for each Object definition,
 To use a reference to an Object/Detail whose definition refers to the Technical Name or
Unique Name of the level/attribute.
Here is a list of restrictions for the OLAP Universes:
- Row/Level security in OLAP Universes has been disabled: the security is applied on
Tables/Columns and there are no Tables and Columns in the OLAP universes.
- List Of Values (LOV) cannot be customized: only standard LOVs and Cascading LOVs are
available.
- Desktop Intelligence does not consume any OLAP Universes.

5 Common scenarios and decisions

While every 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, Web Intelligence query, and BEx Query design for each scenario.
5.1 Customizing BW universe definition
While the default universe generated for a BW query or cube is usable, it contains a lot of elements
which might not be required for most reporting needs, and other elements which may require some
tuning based on the detailed requirements.
5.1.1 Removing unnecessary L00 objects
As specified in the section How BW 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 simplify the report design
experience.
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 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 BW 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 the Universe 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
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 BW 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:
Note: All objects based on OLAP Universes are generated with Index Awareness. Index Awareness
brings 3 major improvments for OLAP Objects:
• Better performance (as the Index Awareness refers to the OLAP Object Unique Name:
[<characteristic>].[TECH_NAME], or [<characteristic>].[LEVEL<xx>].[TECH_NAME])
• Cascading LOVs in tree mode are displayed correctly
• Remove inconsistency in case of duplicate values for the concerned Object.
You have to take into account that if you want to set a prompt that allows manual entry then the index
awareness option becomes disabled.
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 can be met by having users access scheduled instances
of the report. In general, if is possible to minimize the number of times a report is run against the BW
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 BW 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 reminder of this document, in order to
minimize the load on the BW system and Web Intelligence processing servers.
5.3 Hierarchies
5.3.1 Defining custom hierarchies in the universe
Creating custom universe hierarchies in BW universes is fully supported and behaves the same way
as classic universe hierarchies.
Universe hierarchies behave as drill paths and are similar to a set of characteristics with option
“Display as hierarchy” set on (see paragraph “Display as hierarchy”)
5.3.2 Query Drill for hierarchies
Multiple hierarchies can be defined at the Characteristic level. They will be automatically exposed in
the universe. The Universe Designer capabilities to define and maintain drill-down paths in Web
Intelligence should be leveraged to enable Web Intelligence users to drill down according to BW
hierarchies as with any other custom universe hierarchies. It is important to note that the Use Query
Drill option that is available in Web Intelligence Document Properties dialog helps to significantly
improve the drill down performance. Activating this option can make Web Intelligence behave more
like BEx in terms of fetching limited result sets when drilling down.
Therefore it must be kept activated to have drill down performance in Web Intelligence as fast as
within BEx. Of course, Web Intelligence user preferences (General Drill Options) also enables to
prompt users for applying query filters when drilling.
By default, Web Intelligence documents built on top of OLAP universes have the “Use Query Drill”
option activated.

“Use Query Drill” option is incompatible with “Scope of Analysis” option. When “Use Query Drill” option
is activated, “Scope of Analysis” option (available in the Query Panel) is grayed out, and vice versa.
5.3.3 Hierarchies with linked nodes
Currently, using hierarchies which contain linked nodes may cause unexpected behaviour.
Specifically, if a node which is returned by the Web Intelligence query is a linked node, Web
Intelligence may display that node’s parent as the “original” parent node, rather than the parent who
linked to that node. A correction for this issue may become available in the future. Please consult
SAP customer support for information on availability.
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. There are several methods which may be employed to filter the
results. The method applied may have an impact on the overall performance of the reports.
Generally, filtering requirements can be separated into 2 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 characteristic member
values and not filtering based on key figure values.
5.4.1 Static filtering of characteristic values
Static filtering with Web Intelligence is only available for Characteristics and Hierarchies that
used as of mandatory or free characteristics in the BEx query
5.4.1.1 Static filtering with Web Intelligence Query filters
Defining filters in the Web Intelligence query panel rather than in the underlying BW query provides a
lot of flexibility and allows a single BW query and single universe to be reused for many Web
Intelligence reports. By following a few simple guidelines, it is possible to implement quite well-
performing queries using static Web Intelligence 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 Web Intelligence query
panel. Due to the need to resolve filters to member-sets, these types of filters may impact the
performance. 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 BW 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 Web Intelligence query filters to member selection), ensure that any characteristics which
are filtered in Web Intelligence are filtered on indexed values. In order to ensure this, 2 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 BW. See for details
2. 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 Web Intelligence 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 2 basic approaches possible: defining
the filter and prompt within the Web Intelligence query panel, or utilizing BEx Query variables.
Dynamic filtering with Web Intelligence is only available for Characteristics and Hierarchies
that used as of mandatory or free characteristics in the BEx query
5.4.2.1 Dynamic filtering with BEx query variables
As detailed in the section How BW 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 BW has some internal optimizations for handling
variable-based restrictions.

Using variables rather than Web Intelligence 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 Web
Intelligence 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 Web Intelligence queries instead.
To replace existing Web Intelligence filters with BEx Query variables:
• Replace Web Intelligence “Equal to” filters with Single value BEx Query variables
• Replace Web Intelligence “InList” filters with Multi value BEx Query variables
• Replace Web Intelligence “Between” filters with Range BEx Query variables.
Note: It is necessary to update your universe after making this change to a BEx Query.
5.4.2.2 Dynamic filtering with Web Intelligence 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 Web Intelligence query filters to
member selection), ensure that any characteristics which are filtered in Web Intelligence are filtered on
indexed values. In order to ensure this, 2 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 BW. See for details
2. The value(s) for the filter must be selected from the LOV, rather than being typed in manually
3. 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 Web Intelligence queries in a single document, Web
Intelligence 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 2 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 BW 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 designed to run queries which return a high volume of data in a single
request3. This is due both to internal design within the OLAP processor and 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 Web Intelligence queries
5.5.1.1 Remove unused fields from the query
While this may seem simple and not obviously necessary, it can have an important impact. During the
process of Web Intelligence 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. Web Intelligence 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 Web Intelligence Detail objects / BW characteristic properties) which does not change per-
row, it is worth considering splitting 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.
3
: SAP BusinessObjects Data Federator can be implemented to address requirements for running queries which return
large result sets. Please refer to the Data Federator product documentation for more information on these capabilities.

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. Please 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 result set, 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, we split 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 Web Intelligence report panel is:
Notice that the 2 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 Web Intelligence 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 2 main methods to achieving this: using drill-down in the
report, and using report linking.
5.5.2.1 Using Drill
Drill can be used within your Web Intelligence report as long as you have a hierarchy defined. It is
possible to use either BW 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 Web Intelligence 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 Web Intelligence 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 Web Intelligence 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 appropriate Master Data queries for reporting in WebI, it is necessary to understand
what each type of Master Data query will request from the BW system. Following are 3 high-level
types of Master Data queries:
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 2
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 result set over the million cell limit if there are many measures.
Note: One million cell limitations had been removed in BusinessObjects Enterprise XI 3.1 Fix Pack
1.2 and also need to be used with SAP Netweaver BI 7.0 EhP1.
As a result, it is recommended to add at least one measure to the Web Intelligence 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.
Note: If you want to retrieve all members from all characteristics, you can create a calculated
measure in the universe that will ensure you to retrieve all members.
This solution has to be used very cautiously as it will also retrieve a Cartesian product. You can create
an object in a universe having the following definition: <EXPRESSION>1</EXPRESSION>

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 2 elements of the structure are selections where the key figure Amount
is restricted to the type Actual or Planned:
The additional 2 items in the structure are formulas which calculate the variance between the 2
amounts and the variance as a percentage value.

5.7.1 Queries with multiple structures
One BEx query can contain up to 2 structures. In the case where the user creates a query which
contains 2 structures, the user created a query that creates a very well defined result set which will –
based on the definition – result in a grid layout.
The query in the above screenshot contains 2 structures:
• The first structure is a grouping of countries into specified groups: USA, Europe, and Asia Pacific
• The second structure contains 3 key figures
• In addition, the query contains 3 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 right level.

As a concrete example – let’s assume the original query returns the following result set:
Country Region Calendar 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
Now, by creating a query with 2 structures you could create the following result set:
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, and the Sales figures have been aggregated for the first and second quarter.
Depending on the actual requirements for the reporting landscape this capability can become very
helpful for 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 Web Intelligence query will be
representative of this grid layout.
6 BW Performance tuning
This section deals with some aspects of performance tuning within the BW 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 BW performance for reporting, refer to the appropriate BW
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 with 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 regular 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.
A simple way to retrieve the necessary information is to leverage the program

SAP_INFOCUBE_DESIGNS
(run the SE38 transaction in the SAP Frontend, then type and execute the SAP_INFOCUBE_DESIGNS
program).
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:
• In the enhanced star schema of an InfoCube, navigational attributes lay 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 Data Store 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).
• 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 BW 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 BW 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/content.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 BW 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.
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 InfoCubes only
because all the • Limitation in the
data is being use of aggregates • Should only used
cached for queries with
• More memory in few free
the OLAP cache characteristics
required
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
results
• Good response
for small
hierarchies
Read data when • First call will be • The smallest • This mode should
navigate or expand fast because only amount of data is be used to
hierarchies required data is being selected for leverage hierarchy
being selected the first call 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 does 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 BW Query.

Below an example of the display after the execution of a BW 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 spent 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 BW 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./Transf.” 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
Web Intelligence against BW. 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 BW hierarchies.
Note 1161911 for general OLAP BAPI performance
In order to take advantage of the performance improvement that is part of the FixPack 1.2 for
BusinessObjects Enterprise XI 3.1, the following SAP Notes are mandatory (on top of SAP NetWeaver
BI 7.01 SP2):
- 1248806 v4,
- 1241650 v6,
- 1257923 v1,
- 1257723 v1,
- 1254300 v1,
- 1254205 v1,
- 1168013 v3,
- 1250186,
- 1252370,
- 1255918
You need to install as well the following dependent SAP Note (still on top of SAP BI 7.01 SP2)
- 1250242: fixes the memory leak issue in rfclib.

7 Troubleshooting
In this section, you will learn about the tools that are available to you to troubleshoot and trace the
SAP connectivity for WebI.
7.1 Tracing and troubleshooting the Web Intelligence activity
Activating Web Intelligence traces allow having access to the XML generated query.
This is the best way to:
• Copy filters definition to be reused in universes
• Understand prompts and variables resolution
• Debug
To activate Web Intelligence traces, you have to register 3 environment variables.
• BO_TRACE_CONFIGDIR = %MyPath%
• BO_TRACE_CONFIGFILE = %MyPath%\bo_trace.ini
• BO_TRACE_LOGDIR = %MyPath%
The 3 environment variables reference a file “BO_trace.ini” stored in “%MyPath%”

This file contains the following information:
Active = true;
Keep = true;
Importance = '<<';
Size = 100000;
When the traces are activated, Web Intelligence and Universe Designer write logs in “%MyPath%”.
Here is a screenshot of possible log files name:

Only files having name like “WebIRichClient…….trace.log” and having the latest modification date are
relevant for debugging the generated XML.
You have to pay attention that you can find several files and only file ending by “…_trace.log” is
worthwhile (do not open file ending by “…jtrace.log”).
An XML string enclosed by “<DPCOMMANDS>” and “</DPCOMMANDS>” tags contains the XML
query. This XML is then sent to the OLAP driver (ODA) that will translate it in MDX statement.
Once you have opened a file, search for the string “</DPCOMMANDS>”.
Here is a sample query with an SAP variable before prompt resolution:

<DPCOMMANDS>
<DPCOMMAND>
<DP>
<QUERY>
<QUERYRESULT>
<QUERYOBJECT KEY="[0CALYEAR].[LEVEL01]" />
<QUERYOBJECT KEY="[Measures].[D4ZE950PAZX9G2YWNEWFTM30F]" />
<QUERYOBJECT KEY="[Measures].[A1]" />
<QUERYOBJECT KEY="[Measures].[A1].[UNIT]" />
<QUERYOBJECT KEY="[Measures].[A1].[FORMATTEDVALUE]" />
<QUERYOBJECT KEY="[Measures].[B2]" />
<QUERYOBJECT KEY="[Measures].[B2].[UNIT]" />
<QUERYOBJECT KEY="[Measures].[B2].[FORMATTEDVALUE]" />
<QUERYOBJECT KEY="[Measures].[D4]" />
<QUERYOBJECT KEY="[Measures].[D4].[UNIT]" />
<QUERYOBJECT KEY="[Measures].[D4].[FORMATTEDVALUE]" />
</QUERYRESULT>
<QUERYSCOPE />
<QUERYCONDITION>
<WHERE>
<FILTER KEY="[0D_DISCH]"><CONDITION
OPERATORCONDITION="Between"><CONSTANT TECH_NAME="[0D_DIS_CHAN].[10]"/><CONSTANT
TECH_NAME="[0D_DIS_CHAN].[10]"/></CONDITION></FILTER>
</WHERE>

</QUERYCONDITION>
</QUERY>
</DP>
</DPCOMMAND>
</DPCOMMANDS>
Here is the same sample after prompt resolution:

<DPCOMMANDS>
<DPCOMMAND>
<DP>
<QUERY>
<QUERYRESULT>
<QUERYOBJECT KEY="[0CALYEAR].[LEVEL01]" />
<QUERYOBJECT KEY="[Measures].[D4ZE950PAZX9G2YWNEWFTM30F]" />
<QUERYOBJECT KEY="[Measures].[A1]" />
<QUERYOBJECT KEY="[Measures].[A1].[UNIT]" />
<QUERYOBJECT KEY="[Measures].[A1].[FORMATTEDVALUE]" />
<QUERYOBJECT KEY="[Measures].[B2]" />
<QUERYOBJECT KEY="[Measures].[B2].[UNIT]" />
<QUERYOBJECT KEY="[Measures].[B2].[FORMATTEDVALUE]" />
<QUERYOBJECT KEY="[Measures].[D4]" />
<QUERYOBJECT KEY="[Measures].[D4].[UNIT]" />
<QUERYOBJECT KEY="[Measures].[D4].[FORMATTEDVALUE]" />
</QUERYRESULT>
<QUERYSCOPE />
<QUERYCONDITION>
<WHERE>
<FILTER KEY="[0D_DISCH]"><CONDITION
OPERATORCONDITION="Between"><CONSTANT TECH_NAME="[0D_DIS_CHAN].[10]"/><CONSTANT
TECH_NAME="[0D_DIS_CHAN].[10]"/></CONDITION></FILTER>
</WHERE>
</QUERYCONDITION>
</QUERY>
</DP>
</DPCOMMAND>
</DPCOMMANDS>

7.2 Tracing and troubleshooting the OLAP driver connectivity (ODA)
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\SAP BusinessObjects\Suite 12.x\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\SAP BusinessObjects\Suite
12.x\MDA\Log\Modules\SAPMODULE
o Verbosity (highest value is 10 decimal)

o MDX Query Log (full path to the log file)
• HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Suite 12.x\MDA\Log
o LogFile (full path to the log file)
These traces are instrumental when troubleshooting or merely seeking to understand what is
happening between the lowest level of SAP BusinessObjects XI 3.x software and the BW 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
These settings will generate 2 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).
Note: To stop recording the MDA logs (known as SOFA logs) and MDX logs, the services from BusinessObjects
Enterprise need to be stopped. Then the registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\SAP
BusinessObjects\Suite 12.x\MDA\Log\Modules can be removed. At last, the services from
BusinessObjects Enterprise need to be restarted (Web Intelligence services, Connection Server).
7.3 Additional troubleshooting tools

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

• The OLAP trace tool RSRTRACE
• The MDX Test editor (transaction MDXTEST)
7.3.1 Using OLAP BAPI functions
The connectivity for BW 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 result set. When getting
unexpected results from the flow outlined in APIs used in creating an OLAP universe or , 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 2 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 result set
Note: You can export the result set 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/UBW_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 result set
Note: You can click Single Entry to view all values for one row.
7.3.2 Using the OLAP trace tool (RSRTRACE)
The OLAP trace tool allows you to trace all OLAP related functions on the BW server. The benefit of
the tool is that the actual trace is stored on the BW 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.3.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 Web Intelligence 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 Web Intelligence query, see the section Tracing and troubleshooting
the Web Intelligence activity 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 BW cube and the phrase CUBE
refers to the BEx query.
3. Select the BW 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.4 Troubleshooting scenarios
The following is a list of potential problem scenarios that and some recommendations on identifying
the issue.
7.4.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 you should
switch on the traces for the MDA.log (seeTracing and troubleshooting the OLAP driver connectivity
(ODA)) and Web Intelligence traces “WebIRichClient…….trace.log” (see Tracing and
troubleshooting the Web Intelligence activity) and send the log files and a screenshot of the query
to SAP Customer Support
• In case you receive error messages in the BAPI Function it indicates an error that should get
transferred to SAP Customer Support.
7.4.2 Scenario 2: SAP Variables are not showing up in WebI
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 WebI
• 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.4.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” (see Tracing and troubleshooting the Web
Intelligence activity). 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.4.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 (seeTracing and troubleshooting the
OLAP driver connectivity (ODA)) 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 XI3 On NetWeaver BW (External)

Uploaded by

Copyright:

Available Formats

Web Intelligence XI3 On NetWeaver BW (External)

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 XI3 On NetWeaver BW (External)

Uploaded by

Copyright:

Available Formats

SAP BusinessObjects Web Intelligence XI 3.

Implementation Best Practices

©SAP AG 2009 Page 2

• The processing required (both in Web Intelligence and BW)

1.1 Intended audience

©SAP AG 2009 Page 3

Available from http://help.sap.com, SAP BusinessObjects area:

• Using SAP BW in universe Designer

Available from http://service.sap.com/releasenotes, SAP BusinessObjects area (login required):

• BusinessObjects XI 3 Release Notes

Available from http://service.sap.com/bosap-support (login required):

• BusinessObjects XI 3 for SAP - Supported Platforms

Available from http://service.sap.com/bosap-instguides (login required):

• BusinessObjects XI Integration for SAP Solutions Installation and Administration Guide

2.1 BW modelling concepts

2.1.1 BW InfoCubes as data sources

©SAP AG 2009 Page 4

2.1.2 BEx Queries as data sources

2.1.2.1 BEx Queries based on a DSO

©SAP AG 2009 Page 5

2.1.2.2 BEx Queries based on an InfoSet

2.1.2.3 BEx Queries as recommended data sources

BW metadata feature OLAP BAPI availability

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

Restricted Key Figures BEx Query only

Custom Structures BEx Query only

Variables BEx Query only

©SAP AG 2009 Page 6

2.1.2.4 Multilingual BW universes

2.2 Mapping BW concepts to universe concepts

©SAP AG 2009 Page 7

BW objects Universe/Web Intelligence objects created

Characteristic Subclass with dimension and detail objects

If data source is a BEx Query: Subclass containing

Subclass with dimension and detail objects (identical to

Display Attribute Detail object for the dimension

Measure object in the class for the Key Figure structure

Pre-defined Filter in the universe

5 Universe parameters defining key date variable in the

©SAP AG 2009 Page 8

2.2.1 How BW characteristics are mapped and used in a universe

2.2.2 How BW key figures are mapped and used in a universe

©SAP AG 2009 Page 9

2.2.3 How BW hierarchies are mapped and used in a universe

2.2.3.1 Characteristic Hierarchies

©SAP AG 2009 Page 10

In the given example the hierarchy itself is based on a single characteristic.

©SAP AG 2009 Page 11

• Characteristic to Hierarchy variable

• Hierarchy X to Hierarchy variable

• Hierarchy variable to hierarchy X

• Hierarchy variable to Characteristic

2.2.3.2 “Display as hierarchy”

©SAP AG 2009 Page 12