You are on page 1of 68

Web Intelligence on SAP NetWeaver BI

Field implementation guide

FOR INTERNAL Business Objects/SAP USE ONLY


Contents
Contents..................................................................................................................................... 2

1 Introduction ....................................................................................................................... 5

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

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

1.3 References .................................................................................................................. 5

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

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

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

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

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

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

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

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

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

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

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

2.3.2 Process flow for creating an OLAP Universe ........................................................22

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

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

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

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

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

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

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


3.1.5 Scheduling ..........................................................................................................27

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

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

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

4 Lifecycle management .......................................................................................................30

5 Common scenarios and decisions ......................................................................................30

5.1 Customizing BI Universe definition .............................................................................30

5.1.1 Removing unnecessary L00 objects.....................................................................30

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

5.1.3 Optimizing detail object syntax ...........................................................................31

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

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

5.3 Hierarchies .................................................................................................................33

5.3.1 Using BI hierarchies .................................................Error! Bookmark not defined.

5.3.2 Query Drill for hierarchies...................................................................................33

5.3.3 Defining custom hierarchies in the Universe ............Error! Bookmark not defined.

5.4 Filtering......................................................................................................................33

5.4.1 Static filtering of characteristic values.................................................................34

5.4.2 Dynamic filtering of characteristic values ............................................................35

5.4.3 Large LOVs for prompting ...................................................................................36

5.4.4 Impact of different meta data types on overall performance ..............................36

5.5 Reports with high data volume...................................................................................36

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

5.5.2 Reducing the number of rows per request by using guided navigation................40

5.6 Leveraging structures in a BI Query ............................................................................41


6 BI Performance tuning .......................................................................................................44

6.1 Performance impact of data modelling.......................................................................44

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

6.1.2 Navigational Attributes.......................................................................................46

6.2 Overall reporting performance ...................................................................................46

6.2.1 Query monitor....................................................................................................46

6.2.2 Transaction ST03 ................................................................................................50

6.2.3 Leveraging Aggregates........................................................................................51

6.3 Relevant SAP Notes ....................................................................................................51

7 Troubleshooting ................................................................................................................52

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

7.2 Additional troubleshooting tools ................................................................................54

7.2.1 Using OLAP BAPI functions .................................................................................54

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

7.2.3 MDX Testeditor ..................................................................................................61

7.3 Troubleshooting scenarios .........................................................................................64

7.3.1 Scenario 1: Dimensions are missing in the SAP OLAP Universe ............................64

7.3.2 Scenario 2: SAP Variables are not showing up in Web Intelligence ......................64

7.3.3 Scenario 3: Values are missing in the List of Values for prompting ......................65

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


1 Introduction
This document aims to provide guidance for a successful deployment of Web Intelligence on SAP
NetWeaver BI or SAP BW 3.x. In general, where the terms BI or SAP NetWeaver BI are used in this
document, it may refer to either SAP NetWeaver BI or to SAP BW 3.x. . It is intended to guide the reader
through the high-level concepts relevant to such an implementation, and to highlight the potential
issues and pitfalls which may be encountered in the course of such a deployment. The focus is on the
factors which are unique to using WebI with BI, as opposed to general guidance on deploying WebI.

A primary focus of this document is a set of practices and steps which may be taken to maximize the
performance of WebI reports against SAP NetWeaver BI. In this context, maximizing performance refers
to a balance of minimizing:

The processing required (both in WebI and BI)

The memory footprint required (both in WebI and BI)

The report viewing users perceived response time

In order to properly explain and rationalize these practices, it is also necessary to provide a lot of insight
into the processing flow. As a result, there is a lot of such information in the beginning of this guide.

Upon reading this document, it is expected that the reader will have the basic knowledge required to
successfully deploy WebI for reporting on BI.

1.1 Intended audience


The intended audience of this document is a technical Business Objects or partner field professional who
is responsible for successfully deploying Web Intelligence (WebI) against BI.

1.2 Assumptions
This document assumes that the reader is proficient in classic universe design and the QRA capabilities
offered in WebI XI 3.0.

It also assumes that the reader has had in-depth exposure to BI and the Business Explorer Suite (BEx).
More specifically it is expected that the reader is familiar with BEx Query design using the BEx Query
Designer.

Lack of knowledge in these areas will most likely result in serious challenges in successfully positioning
and deploying the solutions described in this document.

1.3 References
Available from http://help.sap.com, in the Business Objects area, under BusinessObjects XI 3.0 version:
Using SAP BW in Universe Designer
Designers Guide
BusinessObjects XI Integration for SAP User's Guide

Web Intelligence on SAP NetWeaver BI Intended audience 5


Field implementation guide
Available from http://service.sap.com/releasenotes, in the Business Objects area (login required):
BusinessObjects XI 3.0 Release Notes

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


BusinessObjects XI Integration for SAP Installation Guide

BusinessObjects XI 3.0 - Integration for SAP Solutions - Supported Platforms


SAP Library Business Intelligence: Modeling

Web Intelligence on SAP NetWeaver BI References 6


Field implementation guide
2 Useful concepts

2.1 SAP NetWeaver BI Modelling concepts


When creating an OLAP universe based on a BI data source, you can build the universe based directly on
an InfoCube/Multiprovider, or based on a BEx Query enabled on top of any InfoProvider. An
InfoProvider can be:

an InfoCube
a Multiprovider
an Operational Data Store (ODS)
an InfoSet
an InfoObject (Master Data)

2.1.1 BI InfoCubes as data sources


The following types of InfoCubes are supported as data sources for building OLAP universes:

Standard and Transactional InfoCubes: Data and metadata are physically stored in the same BI
system

Remote InfoCube: Data is physically stored on a remote system

Note: While fully supported, building and deploying universes on remote InfoCubes is not
recommended for ad-hoc query-, reporting-, and analysis scenarios. Such architecture is generally
not expected to meet query performance expectations with interactive queries.

MultiProvider

Note: Building and deploying a Business Objects universe on top of a MultiProvider is identical to
building and deploying a universe on top of an InfoCube. All the characteristics, hierarchies, key
figures, including time and unit, in the InfoCube are visible in the universe.

2.1.2 BEx Queries as data sources


SAP NetWeaver BI customers use BEx Queries to access data through SAP Business Explorer front-ends.

Note: In order to serve as a data source and become available through the OLAP interface to Business
Objects universes, BEx Queries must be released for OLE DB for OLAP. You allow external access to the
BEx Query in the BEx Query Designer, on the Extended tab of the Query Properties dialog box.

All InfoObjects in the BEx Query selected as rows, columns, and free characteristics are visible in the
universe. This includes characteristics, hierarchies, key figures, structures, and variables.

Both InfoSets and Operational Data Stores (ODS) can be exposed to universes via BEx Queries.

Web Intelligence on SAP NetWeaver BI SAP NetWeaver BI Modelling concepts 7


Field implementation guide
2.1.2.1 BEx Queries based on an ODS
ODS objects are often used to manage detailed transactional-level data before it is aggregated into
InfoCubes. Including ODS objects in the BI data store design is a way to minimize InfoCube size and
improve loading and querying performance. An ODS can be exposed to a Universe via a BEx Query.

Note: An ODS is usually a large, detailed relational structure. Accessing an ODS via the OLAP BAPI
interface does not deliver ideal query performance. Consider these alternatives to meet end-user
expectations for fast report delivery:

Create direct access to an ODS via BAPI calls (only available for Crystal Reports in XI 3.0)

2.1.2.2 BEx Queries based on an InfoSet


An InfoSet can be exposed to a universe via a BEx Query. InfoSets are sometimes defined in BI to report
off master data or to leverage specific JOIN types between InfoCubes.

Note: You can report off master data by basing the universes on InfoCubes, eliminating the requirement
to go through InfoSets and BEx Queries. The key difference between the two approaches is that master
data reported off InfoCubes limits data to valid transactions and does not allow you to leverage specific
join types.

2.1.2.3 BEx Queries as recommended data sources


BEx Queries are recommended as data sources for generating universes for the following reasons:

BEx Queries offer a flexible extension to the data modeling environment. InfoCubes require more
effort to change.

BEx Queries offer significant functionality to create customized data sources that meet end-user
requirements, such as Calculated Key figures, Restricted Key figures and SAP Variables.

In the OLAP BAPI interface, not all BI metadata features can be retrieved on an InfoCube level, as
summarized in the following table:

BI metadata feature SAP OLAP BAPI support level

Characteristics (incl. Time and Unit) InfoCube/BEx Query

Hierarchies InfoCube/BEx Query

Basic Key Figures InfoCube/BEx Query

Navigational Attributes BEx Query only

Display Attributes InfoCube/BEx Query

Calculated Key Figures / Formulas BEx Query only

Web Intelligence on SAP NetWeaver BI SAP NetWeaver BI Modelling concepts 8


Field implementation guide
Restricted Key Figures BEx Query only

Custom Structures BEx Query only

Variables BEx Query only

Although BEx Queries have advantages as data sources, you do not need a BEx Query for every report,
nor do you need a universe for every existing BEx Query. To minimize maintenance costs, focus the
implementation strategy on limiting the final number of BEx Queries and universes required to meet all
the ad-hoc query and reporting needs. Keep in mind the following points to reduce the number of
universes needed:

When Web Intelligence is the front-end tool, you are not restricted by the output format in the BEx
Query.

There is no direct impact on performance when working with OLAP universes created from large BEx
Queries. OLAP universe objects not inserted in the Web Intelligence query have no direct impact on
the query performance.

Note: Business Objects recommends having a few BEx Queries from a single one to a handful of them
for every InfoCube or MultiCube that is in scope for ad-hoc query and reporting. Then build a universe
on top of each of these BEx Queries.

2.1.2.4 Multilingual SAP NetWeaver BI universes


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

2.2 Mapping SAP NetWeaver BI concepts to Universe concepts


When you create a universe from either an InfoCube or a BEx Query, Designer maps BI OLAP structures
to equivalent classes and objects in the universe. Note that this section deals only with the default
universe created for an InfoCube or BEx Query. As explained in the section Customizing BI Universe
definition, it is possible and sometimes necessary to customize this structure.

All InfoObjects in the BEx Query set as rows, columns, and free characteristics are exposed to the
universe. This includes characteristics, hierarchies, key figures, structures, and variables.

Hierarchies are mapped, allowing Web Intelligence users to drill down according to BI hierarchies.

For InfoCubes, all the dimensions, characteristics, key figures, and hierarchies are mapped. The
following table shows the universe objects created for each BI object.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 9


Field implementation guide Universe concepts
The term Dimension is used differently between the SAP products and BusinessObjects products. For
SAP a Dimension is a grouping of logically related characteristics into a generic term. Up to 248
characteristics can be combined within one dimension.

On the BusinessObjects side the term Dimension is identical to what SAP defines as a characteristic.

BI object: Universe objects created:

Dimension Class

Characteristic Subclass with dimension and detail objects

If data source is a BEx Query: Subclass containing


dimension and detail objects for each hierarchy
level in the currently defined hierarchy
Characteristic with hierarchy If data source is an InfoCube: Subclasses containing
dimension and detail objects for each hierarchy
level for all hierarchies defined for the
characteristic

Structure based on Characteristics (BEx Queries Class with single dimension object for the structure
only)

Subclass with dimension and detail objects


Navigational attribute
(identical to characteristic)

Display Attribute Detail object for the dimension

Measure object in the class for the Key Figure


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

Measure and dimension objects (same as Key


Calculated Key Figure (BEx Queries only)
Figure)

Measure and dimension objects (same as Key


Restricted Key Figure (BEx Queries only)
Figure)

Pre-defined Filter in the Universe

Variables (BEx Queries only) In the class for the dimension to which the variable
applies, two dimension objects supporting the list
of values, one for caption, one for description.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 10


Field implementation guide Universe concepts
Universe parameters defining key date variable in
Key date variable (BEx Queries only)
the universe

Characteristics in the Filters section of the BEx Query are not mapped. However, the filtering applies to
the universe. If the filter has a fixed value, the filter is applied transparently when running the Web
Intelligence query. If the characteristic has a variable defined, the variable is mapped to a pre-defined
filter object in the Universe.

2.2.1 How BI characteristics are mapped and used in a universe


When no hierarchy is defined on the characteristic in the BEx Query or InfoCube, Designer creates a
class containing the characteristic as two dimension objects: Level 00 and Level 01. The Level 00
dimension represents the aggregation of the characteristic when all members are selected (the member
returned from BI is All members). The Level 01 dimension contains all members for the characteristic as
a flat list of values.

For each dimension object, Designer creates a detail object for the key, up to three detail objects for the
description (short, medium, and long descriptions), and a detail object for each display attribute.

Navigational attributes leveraged in the BEx Query are mapped in the parent object class in the same
way as characteristics are mapped.

Note: A large number of navigational attributes defined in the underlying InfoProvider negatively
impacts the overall performance (please refer back to SAP Best Practices for Data Modelling). Structures
defined in the BEx Query that are based on characteristics are included in the universe as single-
dimension objects with the elements of the structure as dimension members.

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


All key figures in the InfoCube or defined in the BEx Query are included in the universe under a single
object class called Key Figures.

Most key figures are defined in BI with either a currency or a unit characteristic. Based on the details of
the key figure, Designer creates up to three objects:
A measure object with the numeric value corresponding to the key figure without the unit.
A dimension object with character format that contains the unit or currency. For example,
'USD', '', 'km'.
A dimension object with character format that contains the key figure and the unit (formatted
value) based on user preferences configured on the SAP server. For example, '200 USD', '345 ',
'25 km'.

The Key Figures class includes the calculated key figures and restricted key figures defined in the BEx
Query. The original calculation and restrictions are applied to the query, but are not exposed in the
universe.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 11


Field implementation guide Universe concepts
Note: Having a large number of key figures in the BEx query will currently incur a significant
performance penalty when running queries using Universe data access. This is regardless of whether
the key figures are included in the Universe or used in the WebI query. It is therefore suggested to have
only those key figures intended to be used for reporting included in the BEx query definition. This
performance impact is due to time spent loading metadata for units, which is currently executed for all
measures in the query. A fix for this issue may become available in the future.

2.2.3 How BI hierarchies are mapped and used in a universe


Hierarchies are mapped to allow Web Intelligence users to drill down with BI hierarchies in the same
way as custom-made universe hierarchies.

BI hierarchies are slightly different than the classic definition of a hierarchy in a universe. In BI, the user
is able to leverage hierarchical functionality in multiple different ways.

2.2.3.1 Characteristic Hierarchies


A characteristic hierarchy is a hierarchical structure for one or more InfoObjects. A typical example
would be a hierarchical structure of cost centers or as shown below a hierarchical structure of the Sales
Representatives.

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

When a hierarchy is defined on a characteristic in the BEx Query, Designer creates one hierarchical
structure in the universe, with a subclass for each level in the hierarchy. The structure depends on the
current BEx Query definition:

If a hierarchy is defined in the BEx Query, Designer creates this hierarchy structure in the
universe with the maximum amount of hierarchy levels defined.
If a hierarchy variable is defined in the BEx Query that allows the user to choose a hierarchy at
run time, Designer creates a generic hierarchy in the universe. The structure has the highest
number of levels defined for any of the hierarchy structures available for the characteristic.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 12


Field implementation guide Universe concepts
When building a universe on top of an InfoCube, all hierarchies defined on the characteristic are
exposed in the resulting universe. Designer creates subclasses for each hierarchical structure,
each containing subclasses for the levels in that hierarchy.

In the universe, Level 00 of a hierarchy represents the top node of the structure. When multiple top
nodes exist for the hierarchical structure, the Level 00 dimension contains all top nodes as a list of
values. When the hierarchy attribute is set to not filter unassigned nodes, it is necessary to include Level
00 with the top node for unassigned members. Unassigned members are grouped at the lowest level of
the hierarchy.

Note: The Use Query Drill option in the Web Intelligence Document Properties dialog box significantly
improves drill down performance.

2.2.3.2 Display as hierarchy


A second option for the user is to leverage multiple characteristics and display them as a hierarchical
structure. This can be configured as part of the BEx query.

As shown below, the query contains three characteristics, but when executed in BEx it is shown in a
hierarchical display.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 13


Field implementation guide Universe concepts
Hence, the option to Display as Hierarchy comes the closest to the hierarchy definition in a universe,
but this is only a BEx query display setting and will not be reflected in a universe created on that query.

2.2.4 How BI variables are mapped and used in a universe

2.2.4.1 BI variables supported in universes


SAP variables can be interpreted as user prompts defined in the BEx Query. Variables can be mandatory
or optional, and can have default values.

Variables for characteristics are used to filter values for a characteristic. Variables are populated with
values when a query is executed. They can store characteristic values, hierarchies, hierarchy nodes,
texts, and formula elements.

BI variables apply to BEx Queries only.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 14


Field implementation guide Universe concepts
Note: Only BI variables defined as 'Ready for Input' are available as filter objects in the Universe. When
defining the variable in the BEx Query Designer without using the option Ready for input the variable
will still get processed by the BI query but will not be available as a filter in the universe.

The following types of BI variables are supported in universes:

Characteristic variables
Hierarchy variables
Hierarchy node variables
Currency variables
Formula variables
Text variables (as replacement path and authorization processed variables)
Key date variables

The following table shows a detailed list of the variable type User Entry / Default Value only and how
those are leveraged in a universe. User entry variables can be mandatory or optional, and can have
default values.

Variable Type Support Level

Single value prompt Supported

Multiple single value prompt Supported

Characteristic Interval prompt Supported

Selection option prompt Supported as interval prompt

Pre-calculated value set Supported

Text Not supported

Price, quota, and numeric values


Formula
supported

Hierarchy Supported

Hierarchy node Supported

Hierarchy Version Not Supported

Keydate Supported

Currency Supported

The following table shows universe support for other processing types of BI variables.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 15


Field implementation guide Universe concepts
Variable type Processing Type
User Entry/ Replacement Authorization Customer SAP exit
Default Value path exit

Characteristic Supported Supported Supported Supported Supported


Text Not Supported Supported N/A N/A N/A
Formula Supported Supported N/A Supported Supported
Hierarchy Supported N/A N/A Supported Supported
Hierarchy Supported N/A N/A Supported Supported
node

The Exclude operator is not supported. Other operators, such as Less than and Greater than, can only
be used with Selection option entry type. The selection option type is turned into an interval for Web
Intelligence prompting.

2.2.4.2 BI variable mapping to a universe


The user needs to know if a variable is mandatory or optional, and be able to ignore optional variables.
Optional variables are defined as optional filters in the universe, and become optional prompts in Web
Intelligence. Mandatory variables become mandatory prompts in Web Intelligence.

For characteristic variables, Designer creates a filter in the universe. For each filter, two dimension
objects are created as reference objects for the @Prompt function to display the expected list of values.
The list of values dimensions are hidden in the universe. They are necessary for the correct functioning
of the prompt so must not be deleted and must be moved or modified carefully.

Default values for variables are defined in the @Prompt function in the filter using the primary key,
persistent/not persistent, and default values parameters. The @Prompt function syntax can be seen in
the Properties page of the filter in the universe.

Example: WHERE clause generated for a BI variable


This example shows the WHERE clause generated for a BI variable on dimension object Customer2. The
syntax for the generated WHERE clause for a variable can be seen on the Properties page of the filter.

<FILTER KEY="[Z_VAR002]">
<CONDITION OPERATORCONDITION="Equal">
<CONSTANT TECH_NAME="@Prompt(
'Customer Variable Single Value Mandatory',
'A',
'Customer2\LovCustomer Variable Single Value
MandatoryBase',
mono,
primary_key)"/>
<CONDITION>
</FILTER>

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 16


Field implementation guide Universe concepts
The prompt text is generated from the BI variable name. You can edit the text to make it more
descriptive.

Customer2\LovCustomer Variable Single Value MandatoryBase is the name of the hidden universe
object that is used to build the list of values.

Note: If you rename the class or move the list of values object to another folder, you must update the
syntax in the filter key.

Note: To avoid conflict between BI variables and filters defined by Web Intelligence users, its important
to be careful with which objects you allow users to use in defining WebI conditions, as filtering the same
characteristics in two places can cause unexpected results.

2.2.4.3 Mandatory Filters


There are two types of mandatory filter:

Universe: A universe mandatory filter has no dependency on the class to which it belongs. A
universe mandatory filter is included in the query independently of the objects (dimensions,
measures, and details) that are included in the query.

BI variables are created as universe mandatory filters when generating OLAP universes on BI.

Class: Class mandatory filters appear only if an item of the class of the object is used in the query.

A class mandatory filter is triggered when users:

o Add an object (dimension, measure, or detail) to the Result pane of the Query Panel in Web
Intelligence.

o Add a universe pre-defined filter to the Filter pane of the Query Panel, even if no object that
belongs to the same class has been selected in the Result pane.

o Create a filter with an object (dimension, measure, or detail) that belongs to a class with a
mandatory filter.

A mandatory filter is hidden and cannot be selected in the Query Panel in Web Intelligence. In Designer,
when you set a filter as mandatory in the query, then it is hidden automatically and the Show Item(s)
command is disabled. If you uncheck the mandatory option, the filter is no longer hidden. The Hide
Item(s) command is enabled.

An end-user query can include more than one mandatory filter. By default, all mandatory filters are
joined in the query with the AND operator.

All sub-classes inherit the mandatory filters from the parent class. Note, however:

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 17


Field implementation guide Universe concepts
An object (dimension, measure, detail) that references another object with the @SELECT function
does not inherit the class mandatory filter of the referenced object.

A WHERE clause of an object that references another object WHERE clause with the @WHERE
function does not inherit the class mandatory filter of the referenced object.

A pre-defined filter that references another pre-defined filter or an object WHERE clause with the
@WHERE function does not inherit the class mandatory filter of the referenced object.

Example: Mandatory filter in an OLAP universe

Purpose of Filter Sample XML code

<FILTER KEY="[BCOMUSI]">
<CONDITION OPERATORCONDITION="InList">
Validate the code entered by a <CONSTANT TECH_NAME="@Prompt('CO_CODE
user in a prompt Char User MultiSingle Man Def', 'A','Company
code\Lov[BCOMUSI]Base', multi,primary_key)"/>
</CONDITION>
</FILTER>

2.2.4.4 BI variables and list of values


A BEx Query can contain many variables, meaning that many lists of values may have to be loaded.
Loading and refreshing lists of values can have a major impact on performance. The following options
are available for improving query performance for queries with variables:

Optional variables are generated as optional prompts. An optional prompt does not automatically
load the list of values at query run time.

The delegate search option on the list of values properties presents the user with an empty list of
values at query run time. The user enters search criteria to limit the number of values returned in
the list of values.

To activate the delegated search option for a list of values, edit the list of values properties on the
object properties page of the object to which the list of values applies.

Note: Delegated search is not supported for cascading lists of values.

2.2.4.5 BI key date variables in a universe


A key date variable in a BEx Query allows you to specify a date for time-dependent data. Key dates can
influence the data retrieved for a dimension, for example, a product description can change over time. A
key date can influence a hierarchy structure, for example, a specific cost center can be on Level 01 in
one year, and on Level 02 in a different year.

The key date variable is a special BI variable because the date value entered by the user is not contained
in any dimension of the BEx Query. The key date is a property of the query.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 18


Field implementation guide Universe concepts
In a BEx Query, the key date variable can be defined for two uses:

To specify the valid date for a specific hierarchy, impacting only that hierarchy.

To specify a date for the complete query. In this case, the key date that is set in a query influences
the following:

o time-dependent master data

o currency exchange rates

o the list of hierarchies

o time-dependent hierarchy structures

Note: In the universe, the use of a key date is limited to the whole universe. Therefore, the key date
generated in a universe impacts all other SAP variables and data.

BI supports multiple key date variables per BEx Query, but a universe as of now is only able to support a
single Key date variable.

Key date variables can be mandatory or optional, and can have a default value. If no default value is
defined and the user does not enter a value, the query uses the current system date of the BI system.

The key date variable properties of the query are mapped to five universe parameters, described in the
following table.

Parameter Description

KEYDATE_ENABLED Set to Yes if a key date is enabled on the


universe

KEYDATE_NAME Technical name of the key date variable

KEYDATE_CAPTION Caption for the key date variable presented


when prompting the user for a value

KEYDATE_DEFAULT_VALUE Default value for the key date, if it exists

KEYDATE_MANDATORY Set to Yes if a user must enter a value or use


the default

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

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 19


Field implementation guide Universe concepts
2.2.4.6 BI hierarchy and hierarchy node variables in a universe
A hierarchy variable is used to prompt the user for the hierarchy to be used in the query. Web
Intelligence users can create queries and reports to retrieve and display members from any hierarchy.

If the hierarchy variable is optional and the user leaves the prompt empty, no hierarchy is used and the
report will leverage the standard display of the characteristic.

A report can contain the largest number of hierarchy levels independent of the hierarchy that is
selected. Hierarchy levels that are not returned in the result set are empty in the report.

A hierarchy node variable is used to prompt the user for the node to be used as a filter for the report.

When a query contains both a hierarchy and hierarchy node variable, the Web Intelligence user must
first select a hierarchy in the list of available hierarchies. Next, the user selects the hierarchy node.

The list of hierarchy nodes will show hierarchy nodes for all available hierarchies regardless of which
hierarchy is selected. The user is responsible for selecting a node from the correct hierarchy. This has
been raised as a major concern and will be addressed in a future release.

Web Intelligence on SAP NetWeaver BI Mapping SAP NetWeaver BI concepts to 20


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

2.3.1 The OLAP BAPI as an interface to BI


The connectivity to BI is made through the SAP OLAP BAPI. This BAPI consists of two main parts:

The MDProvider interface


This interface is used mainly for fetching metadata. It consists of a number of RFC function modules
(BAPI_MDPROVIDER_*), which provides the ability to list and get details for things like:

Cubes

Queries

Hierarchies

Levels

Dimensions

Measures

Members

The MDDataSet interface


This interface is used for executing MDX statements against BEx Queries or InfoCubes in BI, and
returning the results. It consists of a number of RFC function modules (BAPI_MDDATASET_*).

Web Intelligence on SAP NetWeaver BI Under the hood BI OLAP Universe processing 21
Field implementation guide details
2.3.2 Process flow for creating an OLAP Universe
This image shows the process flow for creating an OLAP Universe on top of a BEx Query or cube. The
process flow also mentions the OLAP BAPI functions that are being used.
This function is called in the beginning to
retrieve the list of cubes available for the user
BAPI_MDPROVIDER_GET_CATALOGS (based on SAP Security). The returned list
contains the technical names and the
description of the cubes

Selected Cube is used as input parameter for the next step

This function is called to retrieve the list of


available SAP BW Queries based on the
selected SAP BW Cube. The returned list
BAPI_MDPROVIDER_GET_CUBES contains the description and technical names of
all queries for the selected cube that have been
configured to be available for external access
(release for ODBO)

Selected SAP BW Query / Cube is used as input paramter for the next step

This function is called for the selected SAP BW


Query (or cube in case of direct cube access)
BAPI_MDPROVIDER_GET_DIMENSION to retrieve the list of dimensions. The returned
list contains all dimensions that are used in
rows, columns and free characteristics.

This function is called for dimensions that are


part of the selected SAP BW Query (or cube in
BAPI_MDPROVIDER_GET_HIERARCHYS
case of direct cube access) to retrieve the list of
available hierarchies.

This function is called for all Hierarchies that


have been returned by the previous call to
BAPI_MDPROVIDER_GET_LEVELS
retrieve the available number of levels per
Hierarchy.

This function is called for the selected SAP BW


BAPI_MDPROVIDER_GET_VARIABLES Query and returns the list of variables that
require user interaction

Web Intelligence on SAP NetWeaver BI Under the hood BI OLAP Universe processing 22
Field implementation guide details
2.3.3 Process flow for viewing a Web Intelligence report

2.3.3.1 Overall flow


This image shows the process flow for viewing a Web Intelligence report using an OLAP Universe as its
data source. The process flow also mentions the OLAP BAPI functions that are being used.
This function is called for SAP BW Query (or
cube in case of direct cube access) that has
been used for the OLAP Universe to retrieve
BAPI_MDPROVIDER_GET_DIMENSION
the list of dimensions. The returned list contains
all dimensions that are used in rows, columns
and free characteristics in the SAP BW Query

This function is called for dimensions that are


BAPI_MDPROVIDER_GET_HIERARCHYS defined in the OLAP Universe to retrieve the list
of valid Hierarchies.

This function is called for all Hierarchies that


have been returned by the previous call to
BAPI_MDPROVIDER_GET_LEVELS
retrieve the available amount of levels per
Hierarchy.

This function is called for the selected SAP BW


BAPI_MDPROVIDER_GET_VARIABLES Query and returns the list of variables that
require user interaction

XML Query Definitionfor SAP Variables


Visible in the Logfile as XML definition
starting with "<DP Command" after the call
for Variables

This function is called for the variables to


BAPI_MDPROVIDER_GET_MEMBERS (for prompting) retrieve a list of values that can be displayed in
the prompting dialog

XML Query
Definitionfor report
Visible in the Logfile as XML definition
starting with "<DP Command"

This function is called for all dimensions /


BAPI_MDPROVIDER_GET_MEMBERS (for Dimension)
Levels that are part of the Query definition

MDX Statement

BAPI_MDDATASET_SELECT_DATA

BAPI_MDDATASET_GET_AXIS_DATA

BAPI_MDDATASET_GET_CELL_DATA
Web Intelligence on SAP NetWeaver BI Under the hood BI OLAP Universe processing 23
Field implementation guide details
2.3.3.2 Resolving of WebI query filters to member selection
When a filter is applied on a universe object which does not have a key field defined and mapped to the
appropriate member-unique name in BI, it is necessary to first resolve the textual caption to a member-
unique name before generating MDX for the query. This process involves making another call to
BAPI_MDPROVIDER_GET_MEMBERS, passing the relevant caption as a filter. Presently, this resolution
of caption to member-unique name is quite expensive, particularly for high cardinality dimensions. In
some cases, this resolution will take as long as the processing of the generated MDX query in its
entirety. For more details on avoiding this, see

Adding keys to objects used in an LOV for filtering.

Note: See Relevant SAP Notes for reference to some potential performance improvements in this area.

2.3.3.3 Processing of result set data for WebI MicroCube


The diagram above shows the flow which occurs up to the point when the BI system returns data to
WebI (by BAPI_MDDATASET_GET_CELLDATA). However, there is a substantial amount of work to be
done after this point, as the data returned by the BAPI is in a multidimensional format, and WebI
requires the data to be in a flat format in order to be loaded into the MicroCube. As a result, the data
must be flattened. This flattening process can be quite time-consuming and memory-intensive within
the WebI processing server, and depending on the structure of the data (hierarchy depths, etc.), may
necessitate changes to the universe and/or WebI query to minimize this.

Web Intelligence on SAP NetWeaver BI Under the hood BI OLAP Universe processing 24
Field implementation guide details
3 Security integration

3.1 Authentication
In order to connect to the BI system to retrieve data, it is necessary for the user to be authenticated
against the BI system. This can be accomplished:

By specifying and saving the BI user and password in the universe connection properties

By configuring the universe connection as an SSO connection.

In on-demand viewing cases, by configuring the universe to prompt the user for credentials at view-
time.

3.1.1 SAP login in Universe Designer


The Universe Designer supports SAP authentication. If logging in to the Universe Designer using SAP
authentication and for a connection with logon set to SSO, the designing user will be logged into BI with
the SAP credentials used to logon to the designer, where possible. If SAP credentials are not used when
logging into Universe Designer, it is not possible to design a universe configured for SSO.

Note: This requires the SAP Authentication to be configured in the CMC as a pre-requisite.

3.1.2 Universe connection settings

3.1.2.1 SAP login parameters


When defining the universe connection parameters, there are 2
alternative options to define the SAP login information:

1. With a direct access to a BI application server

2. With access through a SAP message server

Option #2 enables SAP load balancing capabilities. A valid SAP


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

3.1.2.2 Advanced connection parameters


When defining the connection a few advanced
parameters are available as indicated on the
picture beside:

Array fetch/bind size and login timeout parameters have


no effect on a connection to BI.

Web Intelligence on SAP NetWeaver BI Authentication 25


Field implementation guide
The connection life-time option can have a significant impact when working with BI. 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

Clearly, disconnecting and reconnecting between each of these transactions will lead to a significant
performance penalty.

However, it is important to note that the OLAP BAPI interface builds a metadata cache on the client side
every time a connection to BI is established. This cache is only emptied when the connection shuts
down.

When working in parallel to edit BEx Queries and map new universes to these queries, it is therefore
recommended to shut down the universe Designer (so that universe connections are also shut down and
the metadata cache is emptied) before building any new universes to take into changes that were just
made on the BEx Query side.

To minimize the risk of the metadata cache being desynchronized with BEx Query updates, the default
universe connection life-time can also be changed to decrease its value from 10 minutes down to 1
minute.

3.1.3 Single Sign-On


When the BOE user who is running a WebI report is defined as an SAP user on the BI system used in the
universe connection, SSO to the database may be possible.

The following criteria must be met for SSO to function:

Universe connection is configured to use SSO

BOE user connected is defined in BOE as an SAP user, or has an SAP user alias in BOE, on the BI
system the connection is configured against

One of the following is true:

o When viewing on-demand, user signed into BOE using his SAP credentials or with an SAP
Logon Ticket.

o When viewing on-demand or scheduling, SNC with server-side trust (see Secure Network
Communication environments) is configured between BI and the BOE server processing

Web Intelligence on SAP NetWeaver BI Authentication 26


Field implementation guide
the request. Note that SNC support in WebI was not delivered in the Titan RTM, but is
available as an LA fix or in Fix Pack 2 (FP2 was not yet released at the time of writing of
this paper).

3.1.4 Secure Network Communication environments


In order to more robustly and universally support Single Sign-on, it is possible to configure Server-Side
trust between the BOE processing servers and the BI system using Secure Network Communication
(SNC). As highlighted in the Single Sign-On section, using SNC is the only way to achieve SSO in cases
where the users authentication against BOE is done with an account on a system other than the BI
system used by the query, or in schedule-time cases. For details on configuring SNC, refer to the section
titled Configuring SAP Server-Side Trust in the guide: BusinessObjects XI Integration for SAP Installation
Guide

3.1.5 Scheduling
When scheduling a WebI document there is no option to enter credentials that will be used for
processing the query on the BI system. In order to successfully run the report, you must either:

Define hard-coded User-id and password in the universe connection at design time. In this case,
these credentials will be used for all scheduled instances, regardless of which user scheduled it.

Define the universe connection to use SSO at view time, and meet the SSO requirements (see
Single Sign-On).

3.2 BI authorizations for OLAP BAPI access


BI system or dialog accounts are fine to work with universes and WebI. However, this section provides a
list of SAP authorizations that, in our experience and in our test environment, are required to carry out
common tasks with universes for BI. Additional authorization objects or fields may be required,
depending upon your individual implementation.

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 BI role


Object class Object Fields Values

AAAB -Cross- S_RFC Authorization Check for RFC ACTVT - Activity Execute
application Access
Authorization RFC_NAME Name RSOB, RZX2,
Objects of RFC to be SYST
protected

RFC_TYPE - Type of FUGR


RFC to be protected

BC_A - Basis: S_CTS_ADMI - Administration Functions in Change and Transport TABL

Web Intelligence on SAP NetWeaver BI BI authorizations for OLAP BAPI access 27


Field implementation guide
Administration System

RS - Business S_RS_COMP - Business Explorer - ACTVT - Activity Create or


Information Components generate,
Warehouse Display,
Execute

RSINFOAREA - *
InfoArea

RSINFOCUBE - *
InfoCube

RSZCOMPID - ID of *
reporting
component

RSZCOMPPTP - Type All values


of reporting
component

S_RS_HIER -Administrator Workbench - ACTVT - Activity Display,


Hierarchy Analyze

RSHIENM - Hierarchy *
name

RSIOBJNM - *
InfoObject

RSVERSION - *
Hierarchy version

Web Intelligence on SAP NetWeaver BI BI authorizations for OLAP BAPI access 28


Field implementation guide
3.2.2 Creating/refreshing a WebI query/report
Object class Object Fields Values

AAAB S_RFC ACTVT - Activity Execute

Cross-application Authorization Check for RFC Access RFC_NAME Name RSOB, RZX2,
Authorization of RFC to be SYST
Objects protected

RFC_TYPE - Type of FUGR


RFC to be protected

BC_A S_CTS_ADMI TABL

Basis: Administration Administration Functions in Change and Transport System

RS S_RS_COMP ACTVT - Activity Create or


generate,
Business Information Business Explorer -Components Display,
Warehouse Execute

RSINFOAREA - *
InfoArea

RSINFOCUBE - *
InfoCube

RSZCOMPID ID of *
reporting component

RSZCOMPPTP - Type All values


of reporting
component

S_RS_COMP1 ACTVT - Activity Display,


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

RSINFOCUBE - All values


InfoCube

RSZOWNER RS *
Owner (Person
Responsible)

S_RS_HIER ACTVT - Activity Display,

Web Intelligence on SAP NetWeaver BI BI authorizations for OLAP BAPI access 29


Field implementation guide
Administrator Workbench - Hierarchy Analyze

RSHIENM - Hierarchy *
name

RSIOBJNM - *
InfoObject

RSVERSION - *
Hierarchy version

S_RS_ICUBE ACTVT - Activity Display

Administrator Workbench -InfoCube RSICUBEOBJ - All values


InfoCube subobject

RSINFOAREA - *
InfoArea

RSINFOCUBE - *
InfoCube

4 Lifecycle management
When making changes to the structure of an InfoCube or BEx Query, it is often necessary to
update the universe definition for any universes based on that InfoCube or Query. The Update
OLAP Universe Wizard (accessible via the menu View -> Refresh structure in the Universe
Designer) makes this process relatively simple for most cases. For details on lifecycle
management, see the section OLAP universe lifecycle management in the document Using SAP
BW in Universe Designer
.

5 Common scenarios and decisions


While each overall implementation and individual reporting requirement is unique, most have common
elements. The following section details several common scenarios you will come across and gives
guidance on optimizing Universe, WebI Query, and BEx Query design within each scenario.

5.1 Customizing BI Universe definition


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

5.1.1 Removing unnecessary L00 objects


As specified in the section How BI characteristics are mapped and used in a universe, when a
characteristic has no active hierarchy, the L00 node will be All members, and will not provide any

Web Intelligence on SAP NetWeaver BI Customizing BI Universe definition 30


Field implementation guide
reporting value. In this case, it is best to delete all L00 objects in order to reduce complexity for the
report designing users.

Even in cases where an active hierarchy does exist, the L00 objects may be unnecessary. In cases where
there is only one top-level root of the hierarchy, it may be desirable to remove the L00 object for a
hierarchy, unless it is necessary to report members which are not assigned in the hierarchy.

5.1.2 Removing unused or redundant detail objects


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

5.1.3 Optimizing detail object syntax


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

To modify the syntax:

1. Open the universe in Designer.


2. Double click the key detail object you want to modify.
3. In the Select text box on the "Definition" tab of the "Edit Properties" dialog box, change the
syntax to refer to the NAME attribute of the SAP characteristic.

For example, for the object L01 Customer Key, change the generated select syntax:
[Z_CUSTOM].[LEVEL01].[[2Z_CUSTOM]].[Value] to refer to the NAME attribute:
[Z_CUSTOM].[LEVEL01].[NAME]
4. Click OK to save the changes.
5. Follow the same steps for the name object. Change the syntax to refer to the DESCRIPTION
attribute of the SAP characteristic.

For example, for the object L01 Customer Medium Name, change the generated select syntax:
[Z_CUSTOM].[LEVEL01].[[1Z_CUSTOM]].[Value] to refer to the DESCRIPTION attribute:
[Z_CUSTOM].[LEVEL01].[DESCRIPTION]

5.1.4 Adding keys to objects used in an LOV for filtering


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

1. In the Universe Designer, double-click the object to be used.

2. Select the Keys tab.

3. Insert a key entry as follows:

Web Intelligence on SAP NetWeaver BI Customizing BI Universe definition 31


Field implementation guide
Character

Key Type: Primary Key

Select: [<characteristic>].[TECH_NAME], or [<characteristic>].[LEVEL<xx>].[TECH_NAME]

For Example:

5.2 Scheduling vs. on-demand reporting


One of the first factors to consider when designing a report is whether it is necessary to have the report
run on-demand, or if the reporting need would be just as well met by having users access a regularly
scheduled instance of the report. In general, if is possible to minimize the number of times a report is
run against the BI system, it is desirable to do so. So, it is recommended to use scheduling when
practical.

The primary benefits of scheduling rather than viewing on-demand are:

Vastly improved viewing response time for the user

Overall reduction in burden on the BI system versus having many ad-hoc queries run.

Scheduling is not viable for reports which meet one of the following criteria:

Report has a high level of interactivity, especially when the user will be prompted for values which
will filter a large portion of the results.

Report makes use of drill, to the point that orders of magnitude more data would be required to be
read into the scheduled instance than would have been read in the users combined initial view and
likely drill workflows.

Web Intelligence on SAP NetWeaver BI Scheduling vs. on-demand reporting 32


Field implementation guide
Different users have different views of the data returned by a query, either due to personalization or
security reasons.

Given the above factors, in some cases it will not be clear whether a single scheduled instance will result
in a lesser load on the various processing systems than many smaller on-demand viewing requests. In
some cases, experimentation will be required to determine the best approach.

Note that, regardless of whether scheduling or on-demand viewing is chosen for a given report, it is still
important to follow the recommendations laid out in the remainder of this document, in order to
minimize the hit on the BI system and WebI processing servers.

5.3 Hierarchies
5.3.1 Defining custom hierarchies in the Universe
Creating custom universe hierarchies in BI universes is fully supported and behaves the same was as
regular universe hierarchies.

5.3.2 Query Drill for hierarchies


Multiple hierarchies can be defined at the Characteristic level. They will be automatically exposed in the
universe. Universe Designer capabilities to define and maintain drill-down paths in WebI should be
leveraged to enable WebI users to drill down according to BI hierarchies as with any other custom
universe hierarchies. It is important to note that the Use Query Drill option that is available in WebI
Document Properties dialog helps to significantly improve the drill down performance. Activating this
option can make WebI behave more like BEx in terms of fetching limited result sets when drilling down.

Therefore it must be kept activated when there is an expectation to have drill down performance in
WebI as fast as within BEx. Of course, WebI user preferences (General Drill Options) also enables to
prompt users for applying query filters when drilling.

5.3.3 Hierarchies with linked nodes


Currently, using hierarchies which contain linked nodes can cause unexpected behaviour. Specifically, if
a node which is returned by the WebI query is a linked node, WebI may display that nodes parent as the
original parent node, rather than the parent who linked to that node. This issue is currently under
investigation.

5.4 Filtering
In all but the most basic cases, it is necessary to filter the data exposed by an InfoCube or BEx Query in
order to get the desired result. In most cases, there are several methods which may be employed to
filter the results. In many cases, the method applied will have a profound impact on the overall
performance of reports.

Generally, filtering requirements can be separated into two categories: Static filtering, which will apply
the same values each time the report is run, and Dynamic filtering, which will filter results based on user
or other input.

Web Intelligence on SAP NetWeaver BI Hierarchies 33


Field implementation guide
Filtering in the context of this section deals primarily with filtering based on filtering based on
characteristic member values and not filtering based on key figure values.

5.4.1 Static filtering of characteristic values

5.4.1.1 Static filtering with WebI Query filters


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

Use Inclusive member filters rather than exclusive ones


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

Filter on indexed values


In order to avoid the need to resolve member captions to member-unique names when viewing (see
Resolving of WebI query filters to member selection), ensure that any characteristics which are filtered in
WebI are filtered on indexed values. In order to ensure this, two things are required:

1. The object which is being filtered must have a key associated with it. That key must be the
technical name of the underlying characteristic in BI. See

2. Adding keys to objects used in an LOV for filtering for details.

3. The value(s) for the filter must be selected from the LOV, rather than being typed in manually.

If both of the above criteria are not met, the value entered or selected will have to be resolved to the
member-unique name each time the report is run, causing needless overhead. The degree to which this
is important varies depending on the cardinality of the characteristic: low-cardinality characteristics will
not incur a severe penalty in doing member caption lookups. In any case, doing these lookups will
always incur some overhead.

5.4.1.2 Static filtering with BEx Query restrictions


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

Note: It is not necessary to update your Universe after making this change to an existing BEx Query.

Web Intelligence on SAP NetWeaver BI Filtering 34


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

5.4.2.1 Dynamic filtering with BEx query variables


As detailed in the section How BI variables are mapped and used in a universe, it is possible to define
variables within a BEx Query and these will be exposed as universe prompts. There is a performance
incentive to using this approach, as BI has some internal optimizations for handling variable-based
restrictions.

Using variables rather than WebI filters also has the potential advantage of requiring less maintenance
of prompt definitions, in cases where multiple reports source the same universe, and share some of the
same prompted filtering requirements. Of course, in cases where different WebI reports have very
similar data requirements but slightly differing prompting/filtering requirements, it may be preferable
from a maintainability perspective to use a base query with no variables and implement the prompted
filtering in the WebI queries instead.

To replace existing WebI filters with BEx Query variables:

Replace WebI Equal to filters with Single value BEx Query variables.

Replace WebI InList filters with Multi value BEx Query variables.

Replace WebI Between filters with Range BEx Query variables.

Note: It is necessary to update your universe after making this change to a BEx Query.

5.4.2.2 Dynamic filtering with WebI filters


When filtering on high cardinality characteristics, in order to avoid the need to resolve member captions
to member-unique names when viewing (see Resolving of WebI query filters to member selection),
ensure that any characteristics which are filtered in WebI are filtered on indexed values. In order to
ensure this, two things are required:

1. The object which is being filtered must have a key associated with it. That key must be the
technical name of the underlying characteristic in BI. See

2. Adding keys to objects used in an LOV for filtering for details.

3. The value(s) for the filter must be selected from the LOV, rather than being typed in manually.

4. The prompt must be configured to Select only from list in the prompt options dialog.

If all of the above criteria are not met, the value entered or selected will have to be resolved to the
member-unique name before the report is run, causing needless overhead. The degree to which this is
important varies depending on the cardinality of the characteristic: low-cardinality characteristics will

Web Intelligence on SAP NetWeaver BI Filtering 35


Field implementation guide
not incur a severe penalty in doing member caption lookups. In any case, doing these lookups will
always incur some overhead.

Note: There is one case when the above recommendation to always use technical names as keys for
filtering is invalid. When working with multiple WebI queries in a single document, WebI will share the
prompt for filters in different queries which share the same prompt name. In the case where this
sharing is desired and the underlying characteristic being filtered is not from the same InfoObject for
both queries, it is essential to not have a key specified for the Universe object being filtered, as doing so
will result in the technical name for the first object being used, which will not be a valid identifier for the
other object (based on a different underlying InfoObject) being filtered. In the case where this sharing is
not desired, it is necessary to simply name the two prompts differently.

5.4.3 Large LOVs for prompting


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

Delegated search is enabled in the Properties tab of the object properties dialog in the Universe
Designer.

5.4.4 Impact of different meta data types on overall performance

5.5 Reports with high data volume


The OLAP BAPI interface is not suitable to be used for queries which return a high volume of data in a
single request. This is due both to internal limitations within the OLAP processor and to the flattening
process which occurs before the data can be consumed by WebI. The volume of data returned can be
measured by the number of cells returned. In general, it is desirable to reduce this number to the
minimum required for the reporting requirement. This can be done by reducing the number of columns
or rows returned in the request.

5.5.1 Reducing the size of rows by optimizing WebI queries

5.5.1.1 Remove unused fields from the query


While this may seem simple and not obviously necessary, it can have a profound impact. During the
process of WebI query and report creation, it is possible that fields may have been added in the query
panel which are not actually used in the report. It is very important to review the query definition
before publishing a document, and remove any fields from the query definition which are not actively
used or desired to be made available during analysis. WebI will not optimize the query at run-time to
remove those fields which are not required.

Web Intelligence on SAP NetWeaver BI Reports with high data volume 36


Field implementation guide
It may also be desirable to customize the universe definition to remove any dimension or detail objects
which are found to be redundant, avoiding the possibility of a user inserting multiple versions of the
same thing into a report.

5.5.1.2 Refactor queries to extract more constant master data


When creating reports which contain a lot of rows of data and display a lot of master data columns
(typically WebI Detail objects / BI characteristic properties) which does not change per-row, it is worth
considering refactoring a single query into multiple queries to separate the more constant master data
from detail records. Note that it is important to weigh the inherent cost of making additional queries
against the savings realized by removing static master data from the mass result set. This approach
should only be used when the number of unique master data values to be retrieved is at least an order
of magnitude greater than the number of detail rows, and the number of master data fields is relatively
large.

Following is an example to illustrate this case:

The above screenshot shows a query definition with Customer, Order Date, Order ID, plus a couple of
measures. Note that we are including 7 Detail objects from the Customer dimension.

Below is the report in which you can see that we have many detail rows for a single Customer (City
Cyclists).

Web Intelligence on SAP NetWeaver BI Reports with high data volume 37


Field implementation guide
Although the customer detail fields are only displayed once in the report, they are in fact fetched and
replicated once per row in the MicroCube. For each row in the resultset, the number of cells returned
will be 15:

2 for Order Date (index and value)

2 for Order ID (index and value)

1 for Delivered Value

1 for Order Quantity

9 for Customer (value, index, 7 detail cells)

If we assume there are 1000 rows returned per customer, then the number of cells in the result set is
15,000 in this case.

Now, assume that we refactor this query into a master data query and a detail query as follows:

Master data query:

Web Intelligence on SAP NetWeaver BI Reports with high data volume 38


Field implementation guide
Notice that there is a Key Figure from the Detail query included in the Master Data query. This is to
ensure that only master data entries with corresponding data are returned by the Master Data query.
This is more important when your Master Data query contains more than one characteristic (see
Creating queries for Master Data reporting).

Detail Query:

The result in the Data pane of the WebI report panel is:

Web Intelligence on SAP NetWeaver BI Reports with high data volume 39


Field implementation guide
Notice that the two L01 Customer dimension object have been merged under a single L01 Customer
object. To configure merged dimensions, right-click a dimension and select Edit Merged Dimension
(shown below).

At this point, a WebI report can be designed in the same way as the original example, but the resulting
number of cells returned per detail row will be 8:

2 for Order Date (index and value)

2 for Order ID (index and value)

1 for Delivered Value

1 for Order Quantity

2 for Customer (value, index)

Web Intelligence on SAP NetWeaver BI Reports with high data volume 40


Field implementation guide
The number of master data cells returned will be 9:

9 for Customer (value, index, 7 detail cells)

If we assume there are 1000 rows returned per customer, then the total number of cells in all the result
sets is now 8,000 (detail data) plus 9 (master data), a reduction of nearly 7,000 cells when compared to
the original design.

While this is a somewhat simplistic example, the concept is extensible to more complex scenarios
involving reporting off master data and a high number of rows of data.

5.5.2 Reducing the number of rows per request by using guided navigation
Another approach to reducing the number of cells returned per request, and indeed the total number of
cells, is to employ more guided navigation techniques in reporting, rather than presenting the user with
both high-level aggregates and details up front. This technique is appropriate when the total set of data
exposed by a report is vast, and the user is likely to be interested in all of the highly aggregated data but
only specific details. There are two main methods to achieving this: Using Drill in the report, and using
report linking.

5.5.2.1 Using Drill


Drill can be used within your WebI report as long as you have a hierarchy defined. It is possible to use
either BI hierarchies or custom hierarchies defined in the Universe for drill. In order to have only the
data for the current drill context fetched, rather than the entire dataset being fetched up-front, ensure
that Use query drill is checked in the WebI document properties.

As the query used to process the drill is essentially the same as any other filter request, it is important to
use ensure that objects to be used for drill also have an index defined when drilling, as specified in the
section Static filtering with WebI Query filters.

5.5.2.2 Using Report Linking


As another alternative to using drill, you may choose to use report linking. In this case, you would define
an initial report which contained only the highly aggregated levels of data which the user will use to
decide where more information is desired. Report linking is much more flexible in that you may define
links at any level desired, and reports linked to do not have to maintain the same formatting (or indeed,
have much data in common at all with the source report). All that is required is a relationship between
the data in the source context and the data in the target.

It is important to follow the same techniques when linking to a report as are followed in the other
dynamic filtering cases specified in the section Dynamic filtering with WebI filters, in order to avoid
unnecessary member caption resolution in processing the query for the target report.

5.6 Creating queries for Master Data reporting


In order to create performant Master Data queries for reporting in WebI, it is necessary to understand
what each type of Master Data query will request from the BI system. Following are three high-level
types of Master Data queries:

Web Intelligence on SAP NetWeaver BI Creating queries for Master Data reporting 41
Field implementation guide
5.6.1 Query containing a single level of a single characteristic
In this case, master data values will be read directly using OLAP BAPI calls, without executing any MDX
(and so without using the OLAP processor). This will result in all members being returned, whether or
not there are any corresponding entries in any fact tables for them. The performance of such a query
will be good, but may result in retrieving members which are not relevant.

5.6.2 Query containing multiple levels of a single characteristic


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

5.6.3 Query containing multiple characteristics


In this case, values will be read by creating an MDX statement including several characteristics and all
measures. The reason for this is that if no measures are included, the cross join of the two
characteristics will result in a Cartesian product, which delivers no value and is quite expensive.
Unfortunately, including all measures adds a lot of unnecessary calculation and memory overhead, and
can easily push the resultset over the million cell limit if there are many measures.

As a result, it is recommended to add at least one measure to the WebI query. Note that the result in
this case will include only members which have data for at least one of the measures included in the
query. So it is important to include a sufficient set of measures to ensure that all desired members are
included, but no more measures than that.

5.7 Leveraging structures in a BEx query


The BEx Query Designer allows you to build custom structures as part of your BEx query. You can think
of a structure as a characteristic. However, structural components can be complex objects (selections,
formulas).

A classic example of a structure would be a structure comparing the actual and planned amounts of a
key figure.

As shown below you can identify a structure which shows the Actual Amount and the Planned Amount
of the key figure Amount. The two elements of the structure are selections where the key figure
Amount is restricted to the type Actual or Planned.

Web Intelligence on SAP NetWeaver BI Leveraging structures in a BEx query 42


Field implementation guide
The additional two items in the structure are formulas which calculate the variance between the two
amounts and the variance as a percentage value.

5.7.1 Queries with multiple structures


One BEx query can contain up to two structures. In the case where the user creates a query which
contains two structures, the user created a query that creates a very well defined resultset which will
based on the definition result in a grid layout.

The query in the above screenshot contains two structures:

The first structure is a grouping of countries into specified groups: USA, Europe, and Asia Pacific.
The second structure contains three keyfigures.
In addition, the query contains three additional characteristics in the free characteristic area.

For reporting purposes the usage of a custom structure can help to provide the right information for the
report at the correct level.

As a concrete example lets assue the original query returns the following resultset

Calendar
Country Region Month Sales Amount Costs
USA NY 01 100 50

Web Intelligence on SAP NetWeaver BI Leveraging structures in a BEx query 43


Field implementation guide
USA WA 02 200 50
Canada BC 02 300 50
Canada AB 04 200 50
Germany 04 100 50
France 02 200 50

By now creating a query with two structures you could create the following resultset:

Sales
Sales Area Q1 Q2
North America 600 200
Europe 200 100

In this case North America is a representation of USA and Canada, Europe is a representation of
Germany and France; the Sales amount have been aggregated for the first and second quarter.

Depending on the actual requirements for the reporting landscape this capability can become very
helpful because of multiple reasons:

A structure will leverage the underlying SAP backend to perform the calculation and aggregation

A structure can be shared across multiple queries, which reduces the amount of required
maintenance

By using a structure in the underlying source every user will receive an identical definition of the
summarized and combined values

When using a query with multiple structures, the resulting WebI query will be representative of this grid
layout.

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

6.1 Performance impact of data modelling


6.1.1 Line item dimension and high cardinality
When compared to a fact table, dimensions ideally have a small cardinality. However, there is an
exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in
which case almost every entry in the fact table is assigned to a different document. This means that the
dimension (or the associated dimension table) has almost as many entries as the fact table itself. We

Web Intelligence on SAP NetWeaver BI Performance impact of data modelling 44


Field implementation guide
refer here to a degenerated dimension. You can use the indicators line item and high cardinality to
execute the following optimizations:
...

Line item:

This means the dimension contains precisely one characteristic. This means that the system
does not create a dimension table. Instead, the SID table of the characteristic takes on the role
of dimension table. Removing the dimension table has the following advantages:

When loading transaction data, no IDs are generated for the entries in the dimension table.
This number range operation can compromise performance precisely in the case where a
degenerated dimension is involved.

A table- having a very large cardinality- is removed from the star schema. As a result, the
SQL-based queries are simpler. In many cases, the database optimizer can choose better
execution plans.

Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot


subsequently include additional characteristics. This is only possible with normal dimensions.

High cardinality:

This means that the dimension is to have a large number of instances (that is, a high cardinality).
This information is used to carry out optimizations on a physical level in depending on the
database platform. Different index types are used than is normally the case. A general rule is
that a dimension has a high cardinality when the number of dimension entries is at least 20% of
the fact table entries. If you are unsure, do not select a dimension having high cardinality.

A simple way to retrieve the necessary information is to leverage the program


SAP_INFOCUBE_DESIGNS.

A very generic rule is that the dimension table should not take more than 10% of the fact table.

Sample screenshot from SAP_INFOCUBE_DESIGNS:

Web Intelligence on SAP NetWeaver BI Performance impact of data modelling 45


Field implementation guide
6.1.2 Navigational Attributes
Characteristic attributes can be converted into navigational attributes. They can be selected in the
query in exactly the same way as the characteristics for an InfoCube. In this case, a new edge/dimension
is added to the InfoCube. During the data selection for the query, the data manager connects the
InfoProvider and the master data table (join) in order to fill the Query.

From a pure performance point of view, you should model an object on a characteristic rather than on a
navigational attribute, because:

In the enhanced star schema of an InfoCube, navigational attributes lie one join further out than
characteristics. This means that a query with a navigational attribute has to run an additional join
(compared with a query with the same object as a characteristic) in order to arrive at the values.
This is also true for DataStore objects.

For the same reason, in some situations, restrictions for particular values in the navigational
attribute (values that have been defined in the query) are not taken into account by the database
optimizer when it creates run schedules. This can result in inefficient run schedules, particularly if
the restrictions are very selective. In most cases, you can solve this problem by indexing the
navigational attribute in the corresponding master data tables (see below).

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

Web Intelligence on SAP NetWeaver BI Performance impact of data modelling 46


Field implementation guide
6.2 Overall reporting performance
6.2.1 Query monitor
The Query monitor is a tool which allows administration, testing and monitoring of SAP BI Queries. The
tool can be used to generate, test and configure properties (SAP documentation for the Query monitor :
http://help.sap.com/saphelp_nw70/helpdata/EN/a0/2a183d30805c59e10000000a114084/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 BI query with
regard to the read mode, the cache mode, the selection of structure elements, the optimization mode
and the calculation accuracy. You can switch off the default Parallel Processing for queries on a
MultiProvider

The read mode determines how the OLAP processor gets data during navigation. You can set the mode
in Customizing for an InfoProvider and in the Query Monitor for a query.

The following types are supported:

Query to be read when you navigate or expand hierarchies (H)

The amount of data transferred from the database to the OLAP processor is the smallest in this
mode. However, it has the highest number of read processes.

In the following mode Query to read data during navigation, the data for the fully expanded
hierarchy is requested for a hierarchy drilldown. In the Query to be read when you navigate or
expand hierarchies mode, the data across the hierarchy is aggregated and transferred to the
OLAP processor on the hierarchy level that is the lowest in the start list. When expanding a
hierarchy node, the children of this node are then read.

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.

Web Intelligence on SAP NetWeaver BI Overall reporting performance 47


Field implementation guide
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 smalles This mode should
navigate or expand fast because only amount of data is be used to
hierarchies required data is being selected for leverage
being selected the first call hierarchy
aggregates

6.2.1.2 Performance Information in the query monitor


As part of the Query Monitor you are able to retrieve some performance information by using the
Performance Info button.

Web Intelligence on SAP NetWeaver BI Overall reporting performance 48


Field implementation guide
The system displays performance-relevant information for the query that do not correspond to the
system recommendations ( ). The information refers to the following areas:

Query definition:

Query cannot use aggregates (corresponds to specifications in Technical Information under


OLAP-Relevant Data) and is related to the read mode X or A.

Query cannot use the cache (corresponds to specifications in Technical Information under OLAP-
relevant Data).

InfoProvider:

InfoProvider is a MultiProvider

Database statistics need to be checked

Database indexes need to be checked

Especially the last set of information on the InfoProvider could help in regards to increase the
performance when it might be necessary to verify the Database statistics (could lead to new
aggregates) and the Database indexing.

6.2.1.3 Debugging options in the query monitor


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

Web Intelligence on SAP NetWeaver BI Overall reporting performance 49


Field implementation guide
The option to Display Statistics Data in the Others area is very helpful because it will show you in a
very simple way where the time is being spend during the process of a BI Query.

Below an example of the display after the execution of a BI Query:

Web Intelligence on SAP NetWeaver BI Overall reporting performance 50


Field implementation guide
The numbers shown will also show up in transaction ST03 but in case you only need the information for
one particular case this might be much easier.

Especially the information QDBSEL (database selected records) and QDBTRANS (transferred number
of records) is helpful in evaluating the need for aggregated data.

The measurements starting with QTIMExx are showing where the time was spend during the process.

6.2.2 Transaction ST03


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

Navigate to the BW System Load area and you can retrieve the data based on cube or query level.

Web Intelligence on SAP NetWeaver BI Overall reporting performance 51


Field implementation guide
A high ratio on database selected records and Select. / Transfer. Is an indication for a need of
further aggregated data.

6.2.3 Leveraging Aggregates

6.3 Relevant SAP Notes


The following is a list of some SAP notes which are particularly relevant to addressing issues in using
WebI against BI. This is not an exhaustive list. For other notes, it is recommended to check the release
notes and/or supported platforms list.

Notes 1162416 and 1162349 for improving performance of caption resolution

Note 1170323 and 1230303 for improving performance when working with BI hierarchies.

Web Intelligence on SAP NetWeaver BI Relevant SAP Notes 52


Field implementation guide
Note 1161911 for general OLAP BAPI performance

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

7.1 Tracing and troubleshooting the Web Intelligence connectivity


To be able to trace the SAP connectivity for Web Intelligence the necessary registry entries need to be
configured.

The entries can be found in the following part of the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\MDA\Log.

The
image shows that underneath the Log entry, each module of the OLAP connectivity can be configured
for tracing.

For the SAP connectivity, the relevant registry values are:

HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\MDA\Log\Modules\SAPMODULE


o Verbosity (highest value is 10 decimal).
o MDX Query Log (full path to the logfile).
HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\MDA\Log

o LogFile (full path to the logfile).

These traces are instrumental when troubleshooting or merely seeking to understand what is happening
between the lowest level of the Business Objects XI 3.0 stack and the BI system. However, at the highest
verbosity levels the axis and member data is written to the log, potentially incurring a significant
runtime penalty.

The recommendation is to use the following trace levels:

0 for production systems

Web Intelligence on SAP NetWeaver BI Tracing and troubleshooting the Web 53


Field implementation guide Intelligence connectivity
5 during general development and UAT

10 only when troubleshooting

These settings will generate two log files:

An MDA log file that includes all steps that have been performed on the SAP server side.

A MDX log file that includes all executed MDX statements.

Note: After setting the registry value the corresponding services from BusinessObjects Enterprise
need to be restarted (Web Intelligence services, Connection Server)

Web Intelligence on SAP NetWeaver BI Tracing and troubleshooting the Web 54


Field implementation guide Intelligence connectivity
7.2 Additional troubleshooting tools
This section covers additional tools and techniques used to troubleshoot BI connectivity:

OLAP BAPI functions

The OLAP trace tool RSRTRACE

The MDX Test editor (transaction MDXTEST)

7.2.1 Using OLAP BAPI functions


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

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 55


Field implementation guide
Process flow for creating an OLAP Universe or Process flow for viewing a Web Intelligence report, it may
be desirable, in combination with analyzing the log files, to verify the results of some of the BAPI
functions from within the SAP GUI.

The following are two outlines showing how to use the OLAP BAPI functions. Note that the values
specified for the parameters are to be replaced with values relevant to your troubleshooting task.

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 56


Field implementation guide
To call the BAPI function BAPI_MDPROVIDER_GET_CUBES

1. Start the SAP Logon pad.

2. Log onto the SAP system.

3. Start transaction SE37 (Function Builder).

4. Enter the function name BAPI_MDPROVIDER_GET_CUBES into the field Function module.

5. Select the menu Function Module > Test > Single Test (an alternative is pressing F8).

Note: In the given scenario the BAPI function allows you to specify input values.

6. Enter the input parameters.

7. Select the menu Function modules > Execute (F8).

8. Click on the icon next to the number of entries for your resultset.

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 57


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

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 58


Field implementation guide
To call the BAPI function BAPI_MDPROVIDER_GET_MEMBERS

1. Start transaction SE37 (Function Builder).

2. Enter the function name into the field Function module.

3. Select the menu Function Module > Test > Single Test (an alternative is pressing F8).

Note: In the given scenario the BAPI function allows you to specify input values.

CAT_NAM The technical name of the Catalog, which is the technical name of the cube. For
example: Z_BOBJ

CUBE_NAM The technical name of the query in the syntax CUBE/QUERY. For Example:
Z_BOBJ/UBI_TRAIN_QUERY_SIMPLE

DIM_UNAM The member unique name of the dimension.For example: [Z_COUNTRY]

HRY_UNAM The unique name of the hierarchy.

LVL_UNAM The unique name of the level.

LVL_NUMBER The numeric level number.

START_ROW The numeric value for a starting row.

END_ROW The numeric value for a row.

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 59


Field implementation guide
4. Enter the input parameters.

5. Select the menu Function modules > Execute (F8).

6. Click on the icon next to the number of entries for your resultset.

Note: You can click Single Entry to view all values for one row.

7.2.2 Using the OLAP trace tool (RSRTRACE)


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

To activate the OLAP trace

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 60


Field implementation guide
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.

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 61


Field implementation guide
Note: A list of logs is displayed and the administrator is able to view them.

5. Double-click the log entry.

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

7.2.3 MDX Testeditor


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

To start the MDX Testeditor:

1. Log onto the SAP server.

2. Start transaction MDXTEST (MDX Testeditor).

Note: In the MDX Testeditor the phrase CATALOG refers to the BI cube and the phrase CUBE refers to
the BEx query.

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 62


Field implementation guide
3. Select the BI cube from the list box CATALOG.

Note: The entry InfoProvider refers to the option to connect directly to cubes without the usage of a BEx
query.

4. Select the BEx query from the list box CUBE.

Note: The screen shows all available elements of the select BEx query.

5. Click Generated Test Sequence.

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 63


Field implementation guide
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.

Web Intelligence on SAP NetWeaver BI Additional troubleshooting tools 64


Field implementation guide
7.3 Troubleshooting scenarios
The following is a list of potential problem scenarios that and some recommendations on identifying the
issue.

7.3.1 Scenario 1: Dimensions are missing in the SAP OLAP Universe


In the following scenario we will assume that the user was able to create an OLAP Universe based on top
of the BEx Query but the Universe is missing one or more dimensions.

In this case you should use the following steps to identify the issue:

Identify the technical name of the query. You can easily identify the technical name of the cube and
query in the BEx Query Designer or in the log file.

Start transaction SE37 and execute function BAPI_MDPROVIDER_GET_DIMENSIONS.

Do all dimensions of the BEx Query show up in the result set?

Does the result set match the Universe?

In case you receive less dimensions than expected (keep in mind that dimensions from the Filter
area of the BEx Query will not show up in the OLAP Universe) in the BAPI Function you should switch
on the traces for the SOFA.log Logfile as the next step and send the log file and a screenshot of the
query to TechSupport.

In case you receive error messages in the BAPI Function it indicates an error that should get
transferred to SAP TechSupport. Please work with BusinessObjects TechSupport to open a case with
SAPs TechSupport in the customers name.

7.3.2 Scenario 2: SAP Variables are not showing up in Web Intelligence


In this scenario we will assume that the user was able to create the OLAP Universe but the user is
missing a prompt for a SAP Variable.

As a first step open the Query in the SAP BEX Analyzer and verify for which items the user is getting
prompted and compare it with Web Intelligence.

Make sure the dimension for the prompt is actually used in the Query Panel for Web Intelligence
(Web Intelligence will always prompt the user for mandatory SAP variables but the user will only get
prompted for optional SAP Variables in case the dimension is part of the Web Intelligence query).

Open the Universe in the Universe Designer and verify if the LOV definition shows up in the Universe
itself

In case you still are not getting prompted and SAP BEx Analyzer is prompting the user, start
transaction SE37 and execute the function BAPI_MDPROVIDER_GET_VARIABLES.

Switch on logging and create a new Universe based on the query and examine the log file.

Web Intelligence on SAP NetWeaver BI Troubleshooting scenarios 65


Field implementation guide
7.3.3 Scenario 3: Values are missing in the List of Values for prompting
In this scenario we will assume that the List of values shown in Web Intelligence does not match the List
of Values shown in SAP Business Explorer Web Intelligence is missing some members.

as a first step create a new query without the SAP Variable and generate a Web Intelligence report
for the dimension that is using the SAP Variable to see if the value shows up without using an SAP
Variable

Switch on logging and execute the report with the SAP Variable and search the log file for the value
that should be part of the List of values.

Open the Logfile and search for <DPCOMMANDS. There is an XML definition for each prompt and
one for the report. After the XML Definition for the prompt the values are loaded and shown in the
log file.

You can also use the function BAPI_MDPROVIDER_GET_MEMBERS to verify the List of values.

In case you want to verify a single missing value you can also use the function
BAPI_MDPROVIDER_GET_MEMBERS and provide as much input values as possible.

Example:

In this example the function is called for the BEx Query Z_BOBJ/QRY_SIMPLE_TEMPLATE, dimension
[Z_COUNTRY] and the member [Z_COUNTRY].[000000000000000000000000000008] for this dimension.

This would verify if the member exists in the SAP system for the selected dimension.

7.3.4 Scenario 4: Data is missing when executing the report


In this case we assume that the Universe is correct and that the user can see all SAP Variables correct,
but that the report when executed is not providing any data.

Web Intelligence on SAP NetWeaver BI Troubleshooting scenarios 66


Field implementation guide
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 Sofa log file and search for the wording
MDDataSetBW.SelectData

You should see above that line an MDX Statement

Use this MDX Statement and run the MDX Statement in transaction MDXTEST. Make sure the MDX
statement makes sense. What is meant by that?

Open the sofa.log logfile 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.

Web Intelligence on SAP NetWeaver BI Troubleshooting scenarios 67


Field implementation guide
So in this case the MDX Statement should at least include Z_CUSTOM, Z_CITY, Z_COUNTRY and 4 Key
figures, for example:

SELECT NON EMPTY {[Measures].MEMBERS} DIMENSION


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

Web Intelligence on SAP NetWeaver BI Troubleshooting scenarios 68


Field implementation guide