Professional Documents
Culture Documents
0 on SAP
NetWeaver BI
Version 1.0
2008-10-02
Contents
Contents .......................................................................................................................................... 2
1 Introduction ............................................................................................................................. 5
4 Lifecycle management........................................................................................................... 31
5.3 Hierarchies..................................................................................................................... 34
5.5.2 Reducing the number of rows per request by using guided navigation ............... 42
6 BI Performance tuning........................................................................................................... 46
7 Troubleshooting .................................................................................................................... 55
7.3.1 Scenario 1: Dimensions are missing in the SAP OLAP Universe ............................ 65
7.3.2 Scenario 2: SAP Variables are not showing up in Web Intelligence ...................... 66
7.3.3 Scenario 3: Values are missing in the List of Values for prompting ...................... 66
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:
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.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.
• an InfoCube
• a Multiprovider
• an Operational Data Store (ODS)
• an InfoSet
• an InfoObject (Master Data)
• 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: 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.
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)
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.
• 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:
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.
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.
On the BusinessObjects side the term “Dimension” is identical to what SAP defines as a
characteristic.
Dimension Class
Structure based on Characteristics (BEx Queries Class with single dimension object for the structure
only)
Variables (BEx Queries only) In the class for the dimension to which the variable
applies, two dimension objects supporting the list
of values (value help): one for caption, one for
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.
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.
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'.
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.
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.
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:
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.
As shown below, the query contains three characteristics, but when executed in BEx it is shown
in a hierarchical display.
Variables for characteristics are used to filter values for a characteristic. Variables are populated
with values when a query is executed. They can store characteristic values, hierarchies,
hierarchy nodes, texts, and formula elements.
Note: Only 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.
• 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.
Hierarchy Supported
Keydate Supported
Currency Supported
Note: The Exclude operator is not supported. Other operators, such as Less than and Greater
than, can only be used with Selection option entry type. The selection option type is turned into
an interval for Web Intelligence prompting.
Note: For Text variables of type Replacement path, only those which have a static value which
will not change between design time and view time will produce the results the user is likely to
expect.
For characteristic variables, Designer creates a filter in the universe. For each filter, two
dimension objects are created as reference objects for the @Prompt function to display the
expected list of values (value help). The list of values dimensions are hidden in the universe.
They are necessary for the correct functioning of the prompt so must not be deleted and must
be moved or modified carefully.
Default values for variables are defined in the @Prompt function in the filter using the primary
key, persistent/not persistent, and default values parameters. The @Prompt function syntax can
be seen in the Properties page of the filter in the universe.
<FILTER KEY="[Z_VAR002]">
The prompt text is generated from the BI variable name. You can edit the text to make it more
descriptive.
Note: If you rename the class or move the list of values object to another folder, you must
update the syntax in the filter key.
Note: To avoid conflict between BI variables and filters defined by Web Intelligence users, it’s
important to be careful with which objects you allow users to use in defining WebI conditions,
as filtering the same characteristics in two places can cause unexpected results.
• 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.
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.
A mandatory filter is hidden and cannot be selected in the Query Panel in Web Intelligence. In
Designer, when you set a filter as mandatory in the query, then it is hidden automatically and
the Show Item(s) command is disabled. If you uncheck the mandatory option, the filter is no
longer hidden. The Hide Item(s) command is enabled.
An end-user query can include more than one mandatory filter. By default, all mandatory filters
are joined in the query with the AND operator.
All sub-classes inherit the mandatory filters from the parent class. Note, however:
• An object (dimension, measure, detail) that references another object with the @SELECT
function does not inherit the class mandatory filter of the referenced object.
• A WHERE clause of an object that references another object WHERE clause with the
@WHERE function does not inherit the class mandatory filter of the referenced object.
• A pre-defined filter that references another pre-defined filter or an object WHERE clause
with the @WHERE function does not inherit the class mandatory filter of the referenced
object.
<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>
• 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.
The key date variable is a special BI variable because the date value entered by the user is not
contained in any dimension of the BEx Query. The key date is a property of the query.
In a BEx Query, the key date variable can be defined for two uses:
• To specify the valid date for a specific hierarchy, impacting only that hierarchy.
• To specify a date for the complete query. In this case, the key date that is set in a query
influences the following:
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
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.
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.
Note: The OLAP BAPI interfaces are based on MDX and so use MDX-like terms to describe the
various constructs and concepts used. In some cases, this will differ from the representation
within BEx and other tools.
• Cubes
• Queries
• Hierarchies
• Levels
• Dimensions
• Measures
• Members
Web Intelligence XI 3.0 on SAP NetWeaver BI Under the hood – BI OLAP Universe 21
Field implementation guide processing details
Confidential and Proprietary – Business Objects/SAP internal use only
2.3.2 APIs used in creating an OLAP Universe
The table below shows the functions within the OLAP BAPI which are used during the process of
creating an OLAP Universe on BI. The order within the table also roughly indicates the
processing flow.
Web Intelligence XI 3.0 on SAP NetWeaver BI Under the hood – BI OLAP Universe 22
Field implementation guide processing details
Confidential and Proprietary – Business Objects/SAP internal use only
2.3.3 Process flow for viewing a Web Intelligence report
The approximate process flow for viewing a Web Intelligence report based on BI is:
Web Intelligence XI 3.0 on SAP NetWeaver BI Under the hood – BI OLAP Universe 23
Field implementation guide processing details
Confidential and Proprietary – Business Objects/SAP internal use only
Note: With the exception of BAPI_MDPROVIDER_GET_MEMBERS and the BAPI_MDDATASET_*
functions, all of the below are used simply to verify the cube/query definition matches what is
expected.
Note: See Relevant SAP Notes for reference to some potential performance improvements in
this area.
Web Intelligence XI 3.0 on SAP NetWeaver BI Under the hood – BI OLAP Universe 24
Field implementation guide processing details
Confidential and Proprietary – Business Objects/SAP internal use only
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.
Note: This requires the SAP Authentication to be configured in the CMC as a pre-requisite.
Examples of individual “transactions” which are executed within a single workflow are:
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.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).
From each authorization object, you must create an authorization and define the appropriate
field values. You then apply the appropriate authorizations to the profiles (or roles) of your SAP
users.
Web Intelligence XI 3.0 on SAP NetWeaver BI BI authorizations for OLAP BAPI access 27
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
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
RSINFOAREA - *
InfoArea
RSINFOCUBE - *
InfoCube
RSZCOMPID - ID of *
reporting
component
RSHIENM - Hierarchy *
name
RSIOBJNM - *
InfoObject
RSVERSION - *
Hierarchy version
Web Intelligence XI 3.0 on SAP NetWeaver BI BI authorizations for OLAP BAPI access 28
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
3.2.2 Creating/refreshing a WebI query/report
Object class Object Fields Values
Cross-application Authorization Check for RFC Access RFC_NAME – Name RSOB, RZX2,
Authorization of RFC to be SYST
Objects protected
RSINFOAREA - *
InfoArea
RSINFOCUBE - *
InfoCube
RSZCOMPID – ID of *
reporting component
RSZOWNER – RS *
Owner (Person
Responsible)
Web Intelligence XI 3.0 on SAP NetWeaver BI BI authorizations for OLAP BAPI access 29
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
RSIOBJNM - *
InfoObject
RSVERSION - *
Hierarchy version
RSINFOAREA - *
InfoArea
RSINFOCUBE - *
InfoCube
Web Intelligence XI 3.0 on SAP NetWeaver BI BI authorizations for OLAP BAPI access 30
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
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
.
Web Intelligence XI 3.0 on SAP NetWeaver BI BI authorizations for OLAP BAPI access 31
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
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.
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.
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:
Scheduling is not viable for reports which meet one of the following criteria:
• Report has a high level of interactivity, especially when the user will be prompted for values
which will filter a large portion of the results.
• Report makes use of drill, to the point that orders of magnitude more data would be
required to be read into the scheduled instance than would have been read in the user’s
combined initial view and likely drill workflows.
• Different users have different views of the data returned by a query, either due to
personalization or security reasons.
Given the above factors, in some cases it will not be clear whether a single scheduled instance
will result in a lesser load on the various processing systems than many smaller on-demand
viewing requests. In some cases, experimentation will be required to determine the best
approach.
Note that, regardless of whether scheduling or on-demand viewing is chosen for a given report,
it is still important to follow the recommendations laid out in the remainder of this document, in
order to minimize the hit on the BI system and WebI processing servers.
5.3 Hierarchies
5.3.1 Defining custom hierarchies in the Universe
Creating custom universe hierarchies in BI universes is fully supported and behaves the same
was as regular universe hierarchies.
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.4 Filtering
In all but the most basic cases, it is necessary to filter the data exposed by an InfoCube or BEx
Query in order to get the desired result. In most cases, there are several methods which may be
employed to filter the results. In many cases, the method applied will have a profound impact
on the overall performance of reports.
Generally, filtering requirements can be separated into two categories: Static filtering, which
will apply the same values each time the report is run, and Dynamic filtering, which will filter
results based on user or other input.
Filtering in the context of this section deals primarily with filtering based on filtering based on
characteristic member values and not filtering based on key figure values.
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.
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.
Note: It is not necessary to update your Universe after making this change to an existing BEx
Query.
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.
• 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.
1. The object which is being filtered must have a key associated with it. That key must be
the “technical name” of the underlying characteristic in BI. See
2. Adding keys to objects used in an LOV for filtering for details.
3. The value(s) for the filter must be selected from the LOV, rather than being typed in
manually.
4. The prompt must be configured to “Select only from list” in the prompt options dialog.
If all of the above criteria are not met, the value entered or selected will have to be resolved to
the member-unique name before the report is run, causing needless overhead. The degree to
which this is important varies depending on the cardinality of the characteristic: low-cardinality
characteristics will not incur a severe penalty in doing member caption lookups. In any case,
doing these lookups will always incur some overhead.
Note: There is one case when the above recommendation to always use technical names as
keys for filtering is invalid. When working with multiple WebI queries in a single document,
WebI will share the prompt for filters in different queries which share the same prompt name.
In the case where this sharing is desired and the underlying characteristic being filtered is not
from the same InfoObject for both queries, it is essential to not have a key specified for the
Universe object being filtered, as doing so will result in the technical name for the first object
being used, which will not be a valid identifier for the other object (based on a different
underlying InfoObject) being filtered. In the case where this sharing is not desired, it is
necessary to simply name the two prompts differently.
Delegated search is enabled in the Properties tab of the object properties dialog in the Universe
Designer.
Web Intelligence XI 3.0 on SAP NetWeaver BI Reports with high data volume 37
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
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.
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.
Web Intelligence XI 3.0 on SAP NetWeaver BI Reports with high data volume 38
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
The above screenshot shows a query definition with Customer, Order Date, Order ID, plus a
couple of measures. Note that we are including 7 Detail objects from the Customer dimension.
Below is the report in which you can see that we have many detail rows for a single Customer
(City Cyclists).
Although the customer detail fields are only displayed once in the report, they are in fact
fetched and replicated once per row in the MicroCube. For each row in the resultset, the
number of cells returned will be 15:
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:
Web Intelligence XI 3.0 on SAP NetWeaver BI Reports with high data volume 39
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
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 XI 3.0 on SAP NetWeaver BI Reports with high data volume 40
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
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:
Web Intelligence XI 3.0 on SAP NetWeaver BI Reports with high data volume 41
Field implementation guide
Confidential and Proprietary – Business Objects/SAP internal use only
• 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.
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.
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.
Web Intelligence XI 3.0 on SAP NetWeaver BI Creating queries for Master Data 42
Field implementation guide reporting
Confidential and Proprietary – Business Objects/SAP internal use only
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.
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.
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.
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.
As a concrete example – lets assue the original query returns the following resultset
Calendar
Country Region Month Sales Amount Costs
USA NY 01 100 50
USA WA 02 200 50
Canada BC 02 300 50
Canada AB 04 200 50
Germany 04 100 50
France 02 200 50
By now creating a query with two structures you could create the following resultset:
Sales
Sales Area Q1 Q2
North America 600 200
Europe 200 100
In this case North America is a representation of USA and Canada, Europe is a representation of
Germany and France; the Sales amount have been aggregated for the first and second quarter.
Depending on the actual requirements for the reporting landscape this capability can become
very helpful because of multiple reasons:
A structure will leverage the underlying SAP backend to perform the calculation and
aggregation
A structure can be shared across multiple queries, which reduces the amount of
required maintenance
By using a structure in the underlying source every user will receive an identical
definition of the summarized and combined values
When using a query with multiple structures, the resulting WebI query will be representative of
this grid layout.
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.
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 very generic rule is that the dimension table should not take more than 10% of the
fact table.
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).
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 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.
The OLAP processor only requests data that is needed for each navigational status of the
query in the Business Explorer. The data that is needed is read for each step in the
navigation.
In contrast to the Query to be read when you navigate or expand hierarchies mode,
presentation hierarchies are always imported completely on a leaf level here.
The OLAP processor can read data from the main memory when the nodes are
expanded.
When accessing the database, the best aggregate table is used and, if possible, data is
aggregated in the database.
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 all data Fast query First call will be Should be used
navigation after slower for smaller
the first call Limitation in the InfoCubes only
because all the use of aggregates Should only used
data is being More memory in for queries with
cached the OLAP cache few free
required characteristics
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:
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.
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.
A high ratio on “database selected records” and “Select. / Transfer.” Is an indication for a need
of further aggregated data.
Note 1170323 and 1230303 for improving performance when working with BI hierarchies.
The image shows that underneath the Log entry, each module of the OLAP connectivity can be
configured for tracing.
• 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.
Web Intelligence XI 3.0 on SAP NetWeaver BI Tracing and troubleshooting the Web 55
Field implementation guide Intelligence connectivity
Confidential and Proprietary – Business Objects/SAP internal use only
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)
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.
Note: In the given scenario the BAPI function allows you to specify input values.
8. Click on the icon next to the number of entries for your resultset.
Note: In the given scenario the BAPI function allows you to specify input values.
• CAT_NAM The technical name of the Catalog, which is the technical name of the
cube. For example: Z_BOBJ
• CUBE_NAM The technical name of the query in the syntax CUBE/QUERY. For
Example: Z_BOBJ/UBI_TRAIN_QUERY_SIMPLE
• DIM_UNAM The member unique name of the dimension.For example: [Z_COUNTRY]
• HRY_UNAM The unique name of the hierarchy.
• LVL_UNAM The unique name of the level.
• LVL_NUMBER The numeric level number.
• START_ROW The numeric value for a starting row.
• END_ROW The numeric value for a row.
4. Enter the input parameters.
Note: You can click Single Entry to view all values for one row.
Note: The option User logs shows the logs that belong to the current user.
Note: A list of logs is displayed and the administrator is able to view them.
Note: In the MDX Testeditor the phrase CATALOG refers to the BI cube and the phrase CUBE
refers to the BEx query.
Note: The entry InfoProvider refers to the option to connect directly to cubes without the usage
of a BEx query.
Note: The screen shows all available elements of the select BEx query.
Note: The MDX Testeditor generates a MDX test sequence. The test sequence includes all
measures (key figures) and one characteristic (dimension).
Note: The partial results of the MDX Statement are displayed in the bottom pane of the MDX
Testeditor.
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.
• 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
• As a first step open the Query in the SAP BEX Analyzer and verify for which items the user is
getting prompted and compare it with Web Intelligence.
• Make sure the dimension for the prompt is actually used in the Query Panel for Web
Intelligence (Web Intelligence will always prompt the user for mandatory SAP variables but
the user will only get prompted for optional SAP Variables in case the dimension is part of
the Web Intelligence query).
• Open the Universe in the Universe Designer and verify if the LOV definition shows up in the
Universe itself
• In case you still are not getting prompted and SAP BEx Analyzer is prompting the user, start
transaction SE37 and execute the function BAPI_MDPROVIDER_GET_VARIABLES.
• Switch on logging and create a new Universe based on the query and examine the log file.
7.3.3 Scenario 3: Values are missing in the List of Values for prompting
In this scenario we will assume that the List of values shown in Web Intelligence does not match
the List of Values shown in SAP Business Explorer – Web Intelligence is missing some members.
• as a first step create a new query without the SAP Variable and generate a Web Intelligence
report for the dimension that is using the SAP Variable to see if the value shows up without
using an SAP Variable
• Switch on logging and execute the report with the SAP Variable and search the log file for
the value that should be part of the List of values.
• Open the Logfile and search for “<DPCOMMANDS”. There is an XML definition for each
prompt and one for the report. After the XML Definition for the prompt the values are
loaded and shown in the log file.
• You can also use the function BAPI_MDPROVIDER_GET_MEMBERS to verify the List of
values.
• In case you want to verify a single missing value you can also use the function
BAPI_MDPROVIDER_GET_MEMBERS and provide as much input values as possible.
Example:
This would verify if the member exists in the SAP system for the selected dimension.
• As an initial step run the query inside the SAP BEx Analyzer with identical user credentials
and identical SAP Variable values to see if data exists and if data gets returned for the
selected parameter values.
• If that is the case activate logging and execute the report again.
• When the report has been finished open the MDA log file and search for the wording
“MDDataSetBW.SelectData”
• You should see above that line an MDX Statement
• Use this MDX Statement and run the MDX Statement in transaction MDXTEST. Make sure
the MDX statement “makes sense”. What is meant by that?
• Open the MDA log and search for the text “<DPCOMMANDS”. In case the report makes use
of SAP Variables you will see this multiple times (once for each prompt and once for the
report).
<DPCOMMANDS>
<DPCOMMAND>
<DP>
<QUERY>
<QUERYRESULT>
The items in “QUERYOBECT” should be the items you selected in the query panel for your
report.
In case you made use of filters or SAP Variables you should find items in the QUERYCONDITION
area as well.
So in this case the MDX Statement should at least include Z_CUSTOM, Z_CITY, Z_COUNTRY and
4 Key figures, for example: