SAP BusinessObjects Web Intelligence XI 3.x and SAP NetWeaver Business Warehouse

Transcription

1 SAP BusinessObjects Web Intelligence XI 3.x and SAP NetWeaver Business Warehouse February 2009

2 Table of Contents 1 Introduction Intended audience Assumptions References Useful concepts BW modelling concepts Mapping BW concepts to universe concepts BW OLAP universe processing details...20 Note: All those BAPI calls are as well traced within the SOFA/MDA logs (see Tracing and troubleshooting the Web Intelligence connectivity for more details) Security integration Authentication BW authorizations for OLAP BAPI access Lifecycle management Common scenarios and decisions Customizing BW universe definition Scheduling vs. on-demand reporting Hierarchies Filtering Reports with high data volume Creating queries for Master Data reporting Leveraging structures in a BEx query BW Performance tuning Performance impact of data modelling Overall reporting performance Relevant SAP Notes Troubleshooting Tracing and troubleshooting the Web Intelligence activity Tracing and troubleshooting the OLAP driver connectivity (ODA) Additional troubleshooting tools Troubleshooting scenarios...69 Page 2

3 1 Introduction This document aims to provide guidance for a successful deployment of SAP BusinessObjects Web Intelligence (WebI) XI 3.x as a front-end to SAP NetWeaver Business Warehouse1 (BW). It is intended to guide the reader through the high-level concepts relevant to such an implementation, and to highlight the best practices to consider in the course of such a deployment. The focus is on the factors which are unique to using Web Intelligence with BW, as opposed to general guidance on deploying WebI. A primary focus of this document is a set of practices and steps which may be taken to maximize the performance of Web Intelligence reports against BW. In this context, maximizing performance refers to a balance of minimizing: The processing required (both in Web Intelligence and BW) The memory footprint required (both in Web Intelligence and BW) The report viewing user s perceived response time In order to properly explain and rationalize these practices, it is also necessary to provide a lot of insight into the processing flow. As a result, there is a lot of such information in the beginning of this guide. Upon reading this document, it is expected that the reader will have the basic knowledge required to successfully deploy Web Intelligence for query, reporting, and analysis off BW. 1.1 Intended audience The intended audience of this document is with SAP BusinessObjects customer or partner personnel who are in charge of deploying Web Intelligence as a front-end to BW. 1.2 Assumptions This document assumes that the reader is comfortable with basic SAP BusinessObjects universe design and query, reporting, and analysis capabilities in Web Intelligence XI 3.x. It also assumes that the reader has had in-depth exposure to BW and the SAP Business Explorer (BEx) Suite. More specifically it is expected that the reader is familiar with BEx Query design using the BEx Query Designer. 1 : SAP NetWeaver Business Warehouse (BW) is the new name for SAP NetWeaver Business Intelligence (BI). Best practices documented in this guide apply to all versions of BW superior to 3.5. Page 3

4 1.3 References Available from SAP BusinessObjects area: Using SAP BW in universe Designer Designer s Guide BusinessObjects XI Integration for SAP User's Guide Available from SAP BusinessObjects area (login required): BusinessObjects XI 3 Release Notes Available from (login required): BusinessObjects XI 3 for SAP - Supported Platforms Available from (login required): BusinessObjects XI Integration for SAP Solutions Installation and Administration Guide 2 Useful concepts 2.1 BW modelling concepts When creating an SAP BusinessObjects universe based on a BW data source, you can build the universe based directly on an InfoCube/Multiprovider, or based on a BEx Query enabled on top of any InfoProvider. An InfoProvider can be: an InfoCube a Multiprovider an Data Store Object (DSO) an InfoSet an InfoObject (Master Data) Note: Once the universe has been created, it can be exported to the Central Management System (CMS) as any other universe, and is then available to Web Intelligence users to run queries and create reports BW InfoCubes as data sources The following types of InfoCubes are supported as data sources for building universes: Page 4

5 Standard and Transactional InfoCubes: data and metadata are physically stored in the same BW system Remote InfoCube: data is physically stored on a remote system Note: While fully supported, building and deploying universes on remote InfoCubes is not recommended for ad-hoc query, reporting, and analysis scenarios. Such architecture is generally not expected to meet query performance expectations with interactive queries. MultiProvider Note: Building and deploying a universe on top of a MultiProvider is identical to building and deploying a universe on top of an InfoCube. All the characteristics, hierarchies, key figures, including time and unit, in the InfoCube are visible in the universe BEx Queries as data sources BW customers use BEx Queries to access data through the BEx front-ends. Note: In order to serve as a data source and become available through the SAP OLAP BAPI interface to universes, BEx Queries must be released for OLE DB for OLAP (ODBO). You allow external access to the BEx Query in the BEx Query Designer, on the Extended tab of the Query Properties dialog box. All InfoObjects in the BEx Query selected as rows, columns, and free characteristics are visible in the universe. This includes characteristics, hierarchies, key figures, structures, and variables. Both InfoSets and Operational Data Stores (DSO) can be exposed to universes via BEx Queries BEx Queries based on a DSO Data Store Objects (DSO) are often used to manage detailed transactional-level data before it is aggregated into InfoCubes. To include DSO in the BW data store design is a way to minimize InfoCube size and improve loading and querying performance. DSO can be exposed to a universe via a BEx Query. Note: DSOs are usually large and detailed relational structures. Accessing DSO via the SAP OLAP BAPI interface might not deliver the expected query performance. Direct access to DSO via BAPI calls in Crystal Reports XI 3.x is an alternative to consider in order to meet end-user expectations for fast report delivery. Direct access to DSO is also now supported via Data Federator driver (this solution is for BusinessObjects Enterprise XI 3.1 and FixPack1.1). Using Data Federator connection on DSO, a relational universe is automatically generated that satisifies both performance and class universe behavior. This is the recommended usage for Web Intelligence. Page 5

6 BEx Queries based on an InfoSet An InfoSet can be exposed to a universe via a BEx Query. InfoSets are sometimes defined in BW to report off master data or to leverage specific JOIN types between InfoCubes. Note: You can report off master data by basing the universes on InfoCubes, eliminating the requirement to go through InfoSets and BEx Queries. The key difference between the 2 approaches is that master data reported off InfoCubes limits data to valid transactions and does not allow you to leverage specific join types BEx Queries as recommended data sources BEx Queries are recommended as data sources for generating universes for the following reasons: BEx Queries offer a flexible extension to the data modeling environment. InfoCubes require more effort to change BEx Queries offer significant functionality to create customized data sources that meet end-user requirements, such as Calculated Key Figures, Restricted Key Figures, Structures and SAP Variables In the OLAP BAPI interface, not all BW metadata features can be retrieved on an InfoCube level, as summarized in the following table: BW metadata feature OLAP BAPI availability Characteristics (incl. Time and Unit) InfoCube/BEx Query Hierarchies InfoCube/BEx Query Basic Key Figures InfoCube/BEx Query Navigational Attributes BEx Query only Display Attributes InfoCube/BEx Query Calculated Key Figures / Formulas BEx Query only Restricted Key Figures BEx Query only Custom Structures BEx Query only Variables BEx Query only Although BEx Queries have advantages as data sources, you do not need a BEx Query for every report, nor do you need a universe for every existing BEx Query. To minimize maintenance costs, focus the implementation strategy on limiting the final number of BEx Queries and universes required to meet all the ad-hoc query and reporting needs. Keep in mind the following points to reduce the number of universes needed: Page 6

7 When Web Intelligence is the front-end tool, you are not restricted by the output format in the BEx Query There is no direct impact on performance when working with OLAP universes created from large BEx Queries. OLAP universe objects not included in the Web Intelligence query have no direct impact on the query performance. Note: SAP recommends having a few BEx Queries from a single one to a handful of them for every InfoCube or MultiCube that is in scope for ad-hoc query and reporting. Then build a universe on top of each of these BEx Queries Multilingual BW universes The result-set language is dependent on Unicode support in BW. If the SAP system does not contain the data in the desired language, the data is not available in Web Intelligence in this language. Web Intelligence reverts to displaying technical names instead of descriptions when the descriptions are not translated in BW. 2.2 Mapping BW concepts to universe concepts When you create a universe from either an InfoCube or a BEx Query, the Universe Designer product maps BW OLAP structures to equivalent classes and objects in the universe. A SAP OLAP universe is based on a single Query or InfoCube different solutions must be considered to use a single universe to join multiple Queries or InfoCubes2. Note that this section deals only with the default universe created for an InfoCube or BEx Query. As explained in the section Customizing BW universe definition, it is possible and sometimes highly recommended to customize this structure. Note: The universe creation process is automatic once you have selected the connection. The universe structure appears in the Universe pane. There is no table schema in the Structure pane. Only one OLAP Universe is generated per cube, infoquery or infocube. OLAP Universes do not support multiple cubes in the same Universe. All InfoObjects in the BEx Query set as rows, columns, and free characteristics are exposed to the universe. This includes characteristics, hierarchies, key figures, structures, and variables. Hierarchies are mapped, allowing Web Intelligence users to drill down according to BW hierarchies. For InfoCubes, all the dimensions, characteristics, key figures, and hierarchies are mapped. The following table shows the universe objects created for each BW object. The term Dimension is used differently between BW/BEx and universes/webi. For BW/BEx a Dimension is a grouping of logically or technically related characteristics into a generic term. Up to 248 characteristics can be combined within one dimension. On the universe/web Intelligence side the term Dimension is identical to a characteristic in BW/BEx. 2 : SAP BusinessObjects Data Federator can be implemented to federate multiple BW and non-sap data sources in a single universe. Please refer to the Data Federator product documentation for more information on these capabilities. Page 7

8 BW objects Universe/Web Intelligence objects created Dimension Class Characteristic Subclass with dimension and detail objects Characteristic with hierarchy Structure based on Characteristics (BEx Queries only) If data source is a BEx Query: Subclass containing dimension and detail objects for each hierarchy level in the currently defined hierarchy If data source is an InfoCube: Subclasses containing dimension and detail objects for each hierarchy level for all hierarchies defined for the characteristic Class with single dimension object for the structure Navigational attribute Subclass with dimension and detail objects (identical to characteristic) Display Attribute Detail object for the dimension Key Figure Measure object in the class for the Key Figure structure with dimension objects for units/currency, numeric value and formatted value (based on User preferences) Calculated Key Figure (BEx Queries only) Measure and dimension objects (same as Key Figure) Restricted Key Figure (BEx Queries only) Measure and dimension objects (same as Key Figure) Pre-defined Filter in the universe Variables (BEx Queries only) Key date variable (BEx Queries only) In the class for the dimension to which the variable applies, 2 dimension objects supporting the list of values (value help): one for caption, one for description. 5 Universe parameters defining key date variable in the universe Characteristics in the Filters section of the BEx Query are not mapped. However, the filtering applies to the universe. If the filter has a fixed value, the filter is applied transparently when running all Web Intelligence queries based on this universe. If the characteristic has a variable defined, the variable is mapped to a pre-defined filter object in the universe. Page 8

9 2.2.1 How BW characteristics are mapped and used in a universe When no hierarchy is defined on the characteristic in the BEx Query or InfoCube, the Universe Designer creates a class containing the characteristic as 2 dimension objects: Level 00 and Level 01. The Level 00 dimension represents the aggregation of the characteristic when all members are selected (the member returned from BW is All members). The Level 01 dimension contains all members for the characteristic as a flat list of values. For each dimension object, the Universe Designer creates a detail object for the key, up to 3 detail objects for the description (short, medium, and long descriptions), and a detail object for each display attribute. Navigational attributes applied in the BEx Query are mapped in the parent object class in the same way as characteristics are mapped. Note: A large number of navigational attributes defined in the underlying InfoProvider may impact the overall performance (please refer back to SAP best practices for data modelling). In fact, navigational attributes are used as dimensions in MDX query. Thus leads to lot of Crossjoin operators (in the MDX statements) and might return thousands of useless rows. Note: Structures defined in the BEx Query that are based on characteristics are included in the universe as single-dimension objects with the elements of the structure as dimension members How BW key figures are mapped and used in a universe All key figures in the InfoCube or defined in the BEx Query are included in the universe under a single object class called Key Figures. Most key figures are defined in BW with either a currency or a unit characteristic. Based on the details of the key figure, the Universe Designer creates up to 3 objects: A measure object with the numeric value corresponding to the key figure without the unit A dimension object with character format that contains the unit or currency. For example, 'USD' or ' '. A dimension object with character format that contains the key figure and the unit (formatted value) based on user preferences configured on the SAP server. For example, '200 USD' or '345 '. The Key Figures class includes the calculated key figures and restricted key figures defined in the BEx Query. The original calculation and restrictions are applied to the query, but are not exposed in the universe. A sub-class having named the key figure name is created for each key figure defined in BW with either a currency or a unit characteristic. Other key figures are created under the key figures class, see figure below: Page 9

10 Note: Having a large number of key figures in the BEx query may incur a significant performance penalty when running queries using universe data access. This is regardless of whether the key figures are included in the universe or used in the Web Intelligence query. It is therefore suggested to have only those key figures intended to be used for reporting included in the BEx query definition. This performance impact is due to time spent loading metadata for units, which is currently executed for all measures in the query. A correction for this issue may become available in the future. Please consult SAP customer support for information on availability How BW hierarchies are mapped and used in a universe Hierarchies are mapped to allow Web Intelligence users to drill down according to BW hierarchies in the same way as classic universe hierarchies. BW hierarchies are slightly different than the classic definition of a hierarchy in a universe, though. In BW, the user is able to leverage hierarchical functionality in multiple different ways 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. Page 10

11 In the given example the hierarchy itself is based on a single characteristic. When a hierarchy is defined on a characteristic in the BEx Query, the Universe Designer creates a hierarchical structure in the universe, with a subclass for each level in the hierarchy. The structure depends on the current BEx Query definition: If a hierarchy is defined in the BEx Query, the Universe Designer creates this hierarchy structure in the universe with the maximum amount of hierarchy levels defined If a hierarchy variable is defined in the BEx Query that allows the user to choose a hierarchy at run time, the Universe Designer creates a generic hierarchy in the universe. The structure has the highest number of levels defined for any of the hierarchy structures available for the characteristic When building a universe on top of an InfoCube, all hierarchies defined on the characteristic are exposed in the resulting universe. The Universe Designer creates subclasses for each hierarchical structure, each containing subclasses for the levels in that hierarchy. In the universe, Level 00 of a hierarchy represents the top node of the structure. When multiple top nodes exist for the hierarchical structure, the Level 00 dimension contains all top nodes as a list of values. When the hierarchy attribute is set to not filter unassigned nodes, it is necessary to include Level 00 with the top node for unassigned members. Unassigned members are grouped at the lowest level of the hierarchy. Note: The Use Query Drill option in the Web Intelligence Document Properties dialog box may significantly improve drill-down performance. Note: If you have a dimension object with Level 00 and Level 01, its definition in the universe is [<Object_Name>].[LEVEL00] and [<Object_Name>].[LEVEL01]. After applying a hierarchy on this object in the BEx query, running the Refresh Structure feature in Designer will list the elements that are added and the ones that are removed. You might be surprised to see that the object (where you Page 11

12 applied a hierarchy) is part of the removed elements list and then of the added elements list. The object name does not change while its own definition does change. Indeed its definition will be similar to [<HIERARCHY_OBJECT_NAME>].[LEVEL00] (for the L00 Object) and [<HIERARCHY_OBJECT_NAME>].[LEVEL01] (for the L01 Object). A new feature that will be added in SP2 removes this limitation and takes into account the original characteristic. That means that universe object is not hidden/deleted when the BEx query definition changes are: Characteristic to hierarchy X Hierarchy X to hierarchy Y Hierarchy X to Characteristic Characteristic to Hierarchy variable Hierarchy X to Hierarchy variable Hierarchy variable to hierarchy X Hierarchy variable to Characteristic Only objects corresponding to new levels or deleted levels can be added or deleted Display as hierarchy A second option for the user is to leverage multiple characteristics and display them as a hierarchical structure. This can be configured as part of the BEx query. As shown below, the BEx Query contains 3 characteristics, but when executed in BEx it is shown in a hierarchical display. Page 12

13 Hence, the option to Display as Hierarchy comes the closest to the hierarchy definition in a universe, this BEx Query display setting will not be reflected in a universe created on that query, though How BW variables are mapped and used in a universe BW variables supported in universes SAP variables can be interpreted as user prompts defined in the BEx Query. Variables can be mandatory or optional, and can have default values. Page 13

14 Variables for characteristics are used to filter values for a characteristic. Variables are populated with values when a query is executed. They can store characteristic values, hierarchies, hierarchy nodes, texts, and formula elements. Note: Only BW variables defined as 'Ready for Input' are available as filter objects in the universe. When defining the variable in the BEx Query Designer without using the option Ready for input the variable will not be available as a filter in the universe. The following types of BW variables are supported in universes: Characteristic variables Hierarchy variables Hierarchy node variables Currency variables Formula variables Text variables (as replacement path and authorization processed variables) Key date variables The following table shows a detailed list of the variable type User Entry / Default Value only and how those are leveraged in a universe. User entry variables can be mandatory or optional, and can have default values. Variable Type Characteristic Support Level Single value prompt Supported Multiple single value prompt Supported Interval prompt Supported Selection option prompt Supported as interval prompt Pre-calculated value set Supported Text Not supported Formula Price, quota, and numeric values supported Hierarchy Supported Hierarchy node Supported Hierarchy Version Not Supported Keydate Supported Currency Supported Page 14

15 The following table shows universe support for other processing types of BW variables. Note: SAP BW only supports ONE Keydate variable per InfoQuery so that means only ONE Keydate variable per Universe is supported. Variable type Processing Type User Entry/ Default Value Replacement Authorization Customer path exit SAP exit Characteristic Supported Supported Supported Supported Supported Text Not Supported Supported N/A N/A N/A Formula Supported Supported N/A Supported Supported Hierarchy Supported N/A N/A Supported Supported Hierarchy node Supported N/A N/A Supported Supported Note: The Exclude operator is not supported but can be replaced by Not equal or Not in : this is not a recommended solution for performance reasons. Other operators, such as Less Than and Greater Than, can only be used with Selection Option entry type. The Selection Option type is turned into an interval for Web Intelligence prompting. Note: For Text variables of type Replacement Path, only those which have a static value which will not change between design time and view time will produce the results the user is likely to expect BW variable mapping to a universe The user needs to know if a variable is mandatory or optional, and be able to ignore optional variables. Optional variables are defined as optional filters in the universe, and become optional prompts in WebI. Mandatory variables become mandatory prompts in Web Intelligence. For characteristic variables, the Universe Designer creates a filter in the universe. For each filter, 2 dimension objects are created as reference objects for function to display the expected list of values (value help). The list of values dimensions are hidden in the universe. They are necessary for the correct functioning of the prompt so must not be deleted and must be moved or modified carefully. Note: If those objects are removed by mistake, either the user creates them manually or executes the Refresh Structure feature but this last solution is not advised as the IDs of every object will be regenerated and existing reports based on this universe might need to be recreated. Default values for variables are defined in function in the filter using the primary key, persistent/not persistent, and default values parameters. function syntax can be seen in the Properties page of the filter in the universe. Page 15

16 Example: WHERE clause generated for a BW variable This example shows the WHERE clause generated for a BW variable on dimension object Customer2. The syntax for the generated WHERE clause for a variable can be seen on the Properties page of the filter. <FILTER KEY="[Z_VAR002]"> <CONDITION OPERATORCONDITION="Equal"> <CONSTANT TECH_NAME="@Prompt( 'Customer Variable Single Value Mandatory', 'A', 'Customer2\LovCustomer Variable Single Value MandatoryBase', mono, primary_key)"/> <CONDITION> </FILTER> The prompt text is generated from the BW variable name. You can edit the text to make it more descriptive. Customer2\LovCustomer Variable Single Value MandatoryBase is the name of the hidden universe object that is used to build the list of values. Note: If you rename the class or move the list of values object to another folder, it is not necessary to update the filter syntax because it will be automatically updated by the changes you have made on the class or list of values. Note: To avoid conflict between BW variables and filters defined by Web Intelligence users, it s important to be careful with which objects you allow users to use in defining Web Intelligence conditions, as filtering the same characteristics in 2 places can cause unexpected results Mandatory Filters There are 2 types of mandatory filter: Universe: a universe mandatory filter has no dependency on the class to which it belongs. A universe mandatory filter is included in the query independently of the objects (dimensions, measures, and details) that are included in the query. BW variables are created as universe mandatory filters when generating OLAP universes on BW. Class: a class mandatory filter appears only if an item of the class or subclass of the object is used in the query. A class mandatory filter is triggered when users: o Add an object (dimension, measure, or detail) to the Result pane of the Query Panel in WebI. Page 16

17 o Add a universe pre-defined filter to the Filter pane of the Query Panel, even if no object that belongs to the same class has been selected in the Result pane o Create a filter with an object (dimension, measure, or detail) that belongs to a class with a mandatory filter. A class mandatory filter can reference list of values coming from objects that belong to other classes. For instance you can create a class mandatory filter that prompts the user to select a period when an object from the product class is selected. A mandatory filter is hidden and cannot be selected in the Query Panel in WebI. In the Universe Designer, when you set a filter as mandatory in the query, then it is hidden automatically and the Show Item(s) command is disabled. If you uncheck the mandatory option, the filter is no longer hidden. The Hide Item(s) command is then enabled. An end-user query can include more than one mandatory filter. By default, all mandatory filters are joined in the query with the AND operator. All sub-classes inherit the mandatory filters from the parent class. Note, however: An object (dimension, measure, detail) that references another object with 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 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 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 Validate the code entered by a user in a prompt <FILTER KEY="[BCOMUSI]"> <CONDITION OPERATORCONDITION="InList"> <CONSTANT TECH_NAME="@Prompt('CO_CODE Char User MultiSingle Man Def', 'A','Company code\lov[bcomusi]base', multi,primary_key)"/> </CONDITION> </FILTER> Note: In the case of an optional filter, the <OPTIONAL> tag is added before the <FILTER KEY> tag. Example: <OPTIONAL> <FILTER KEY="[BCOMUSI]"> <CONDITION OPERATORCONDITION="InList"> Page 17

18 <CONSTANT Char User MultiSingle Man Def', 'A','Company code\lov[bcomusi]base', multi,primary_key)"/> </CONDITION> </FILTER> </OPTIONAL> BW variables and list of values A BEx Query can contain many variables, meaning that many lists of values may have to be loaded. Loading and refreshing lists of values can have a major impact on performance. The following options are available for improving query performance for queries with variables: Optional variables are generated as optional prompts. An optional prompt does not automatically load the list of values at query run time The delegate search option on the list of values properties presents the user with an empty list of values at query run time. The user enters search criteria to limit the number of values returned in the list of values. To activate the delegated search option for a list of values, edit the list of values properties on the object properties page of the object to which the list of values applies. Note: Delegated search is not supported for cascading lists of values BW key date variables in a universe A key date variable in a BEx Query allows you to specify a date for time-dependent data. Key dates can influence the data retrieved for a dimension, for example, a product description can change over time. A key date can influence a hierarchy structure, for example, a specific cost center can be on Level 01 in one year, and on Level 02 in a different year. The key date variable is a special BW variable because the date value entered by the user is not contained in any dimension of the BEx Query. The key date is a property of the query. In a BEx Query, the key date variable can be defined for 2 uses: To specify the valid date for a specific hierarchy, impacting only that hierarchy To specify a date for the complete query. In this case, the key date that is set in a query influences the following: o Time-dependent master data o Currency exchange rates o The list of hierarchies o Time-dependent hierarchy structures Note: In the universe, the use of a key date is limited to the whole universe. Therefore, the key date generated in a universe impacts all other SAP variables and data. BW supports multiple key date variables per BEx Query, but a universe as of now is only able to support a single Key date variable. Page 18

19 Key date variables can be mandatory or optional, and can have a default value. If no default value is defined and the user does not enter a value, the query uses the current system date of the BW system. The key date variable properties of the query are mapped to 5 universe parameters, described in the following table. Parameter Description KEYDATE_ENABLED Set to Yes if a key date is enabled on the universe KEYDATE_NAME Technical name of the key date variable KEYDATE_CAPTION Caption for the key date variable presented when prompting the user for a value KEYDATE_DEFAULT_VALUE Default value for the key date, if it exists KEYDATE_MANDATORY Set to Yes if a user must enter a value or use the default At query run time, Web Intelligence is able to handle different key dates for multiple queries based on a single universe, which allows the user to create a very simple comparison of different set of data. The user can modify the key date behaviour as part of the Key date properties BW hierarchy and hierarchy node variables in a universe A hierarchy variable is used to prompt the user for the hierarchy to be used in the query. Web Intelligence users can create queries and reports to retrieve and display members from any hierarchy. If the hierarchy variable is optional and the user leaves the prompt empty, no hierarchy is used and the report will leverage the standard display of the characteristic. A report can contain the largest number of hierarchy levels independent of the hierarchy that is selected. Hierarchy levels that are not returned in the result set are empty in the report. A hierarchy node variable is used to prompt the user for the node to be used as a filter for the report. When a query contains a hierarchy and hierarchy node variable, the Web Intelligence user must first select a hierarchy in the list of available hierarchies. Next, the user selects the hierarchy node. The list of hierarchy nodes will show hierarchy nodes for all available hierarchies regardless of which hierarchy is selected. The user is expected for selecting a node from the correct hierarchy. This behaviour might be improved in future releases. Note: The hierarchy node variable is used to browse and pick one or more values of a specific hierarchy. Page 19

20 2.3 BW OLAP universe processing details In order to understand how to optimize universe and Web Intelligence query design for BW reports, it is necessary to understand some of the processing that occurs while running a report based on a BW OLAP universe. The previous sections have explained logically how SAP constructs are represented in a universe. This section will go into the details of what this means when designing and using an OLAP universe for BW The OLAP BAPI as an interface to BW The connectivity to BW is made through the SAP OLAP BAPI. Note: The OLAP BAPI interface is based on MDX and so uses MDX-like terms to describe the various constructs and concepts used. In some cases, this will differ from the representation in BEx. This OLAP BAPI consists of 2 main parts: The MDProvider interface This interface is used mainly for fetching metadata. It consists of a number of RFC function modules (BAPI_MDPROVIDER_*), which provides the ability to list and get details for things like: Cubes Queries Hierarchies Levels Dimensions Measures Members The MDDataSet interface This interface is used for executing MDX statements against BEx Queries or InfoCubes in BW, and returning the results. It consists of a number of RFC function modules (BAPI_MDDATASET_*). Page 20

21 2.3.2 APIs used in creating an OLAP universe for BW The table below shows the functions within the OLAP BAPI which are used during the process of creating an OLAP universe on BW. The order within the table also indicates the processing flow. BAPI function called Purpose BAPI_MDPROVIDER_GET_CATALOGS Retrieves the list of BW cubes BAPI_MDPROVIDER_GET_CUBES Retrieves the list of BEx queries based on the selected cube BAPI_MDPROVIDER_GET_DIMENSIONS Retrieves the list of characteristics based on the selected BEx query or cube BAPI_MDPROVIDER_GET_HIERARCHYS Retrieves the list of hierarchies based on the list of available characteristics BAPI_MDPROVIDER_GET_LEVELS Retrieves the number of levels per hierarchy. Uses the result of BAPI_MDPROVIDER_GET_HIERARCHYS as input BAPI_MDPROVIDER_GET_MEASURES Retrieves the key figures for the selected query or cube BAPI_MDPROVIDER_GET_PROPERTIES Retrieves the list of display attributes for each characteristic BAPI_IOBJ_GETDETAIL Retrieves data type information for the list of key figures and characteristics BAPI_MDPROVIDER_GET_VARIABLES Retrieves the list of variables for the selected BEx query Note: All those BAPI calls are as well traced within the SOFA/MDA logs (see Tracing and troubleshooting the Web Intelligence connectivity for more details) Process flow for viewing a Web Intelligence report The approximate process flow for viewing a Web Intelligence report off BW is: 1. Process LOVs (value help) for any prompts done through BAPI_MDPROVIDER_GET_MEMBERS calls 2. Execute Report Query done by executing MDX through BAPI_MDDATASET_SELECT_DATA Page 21

22 APIs used The table below shows the functions within the OLAP BAPI which are used during the process of viewing a Web Intelligence report based on an OLAP universe on BW. The order within the table also indicates the order the calls are made in. BAPI function Purpose BAPI_MDPROVIDER_GET_CUBES Called to verify the selected BEx query or cube BAPI_MDPROVIDER_GET_VARIABLES Called to retrieve the list of variables for the selected query BAPI_MDPROVIDER_GET_DIMENSIONS Called for each referenced dimension to verify the dimension BAPI_MDPROVIDER_GET_HIERARCHYS Called for each referenced dimension to retrieve the hierarchies BAPI_MDPROVIDER_GET_LEVELS Called for each referenced dimension to retrieve the levels of the hierarchies BAPI_MDPROVIDER_GET_PROPERTIES Called for each referenced dimension to retrieve the display attributes BAPI_MDPROVIDER_GET_MEMBERS Called for each referenced dimension to retrieve the list of values (used for LOV) BAPI_MDDATASET_SELECT_DATA Called to execute MDX statement for main query BAPI_MDDATASET_GET_AXIS_DATA Called to retrieve axis data for executed MDX BAPI_MDDATASET_GET_CELL_DATA Called to retrieve cell data for executed MDX Note: With the exception of BAPI_MDPROVIDER_GET_MEMBERS and the BAPI_MDDATASET_* functions, all of the functions below are used simply to verify that the cube/query definition matches what is expected Resolving of Web Intelligence query filters to member selection When a filter is applied on a universe object which does not have a key field defined and mapped to the appropriate member-unique name in BW, it is necessary to first resolve the textual caption to a member-unique name before generating MDX for the query. This process involves making another call to BAPI_MDPROVIDER_GET_MEMBERS, passing the relevant caption as a filter. This resolution of caption to member-unique name may take some times, particularly for high cardinality dimensions. In some cases, this resolution may take as long as the processing of the generated MDX query in its entirety. For more details on avoiding this, see. Page 22

23 Note: See the section on Relevant SAP Notes for reference to some potential performance improvements in this area Processing of result set data for Web Intelligence MicroCube The table above shows the flow which occurs up to the point when the BW system returns data to Web Intelligence (by BAPI_MDDATASET_GET_CELLDATA). However, there is a substantial amount of work to be done after this point, as the data returned by the BAPI is in a multidimensional format, and Web Intelligence requires the data to be in a flat format in order to be loaded into the MicroCube. As a result, the data must be flattened. This flattening process may be time-consuming and memoryintensive within the Web Intelligence processing server, and depending on the structure of the data (hierarchy depths, etc.), may necessitate tuning the universe and/or Web Intelligence queries to optimize. We have released a fix pack (BOE XI 3.1 FP 1.2) that removes the bottlenecks mentioned above: XI 3.1 without FP 1.2 workflows: Read data from BW (relation warehouse): row set Transform row set into dataset and pass it to SAP OLAP engine SAP OLAP engine pass it to ODA ODA transform the data set into a row set and pass it to Web Intelligence XI 3.1 with FP 1.2 workflows: Read data from BW (relation warehouse): row set SAP BW pass the row set to ODA ODA pass the row ser to Web Intelligence No useless transformation is applied. 3 Security integration 3.1 Authentication In order to connect to the BW system to retrieve data, it is necessary for the user to be authenticated against the BW system. This can be accomplished: By specifying and saving the BW user and password in the universe connection properties Page 23

24 By configuring the universe connection as an SSO connection In on-demand viewing cases, by configuring the universe to prompt the user for credentials at view-time. Note: Select Use BusinessObjects credential mapping to use the user's BusinessObjects Enterprise login credentials for the connection. If you then use this Authentication type, proceed as follows: - Create and save a new user in the Central Management Console (CMC), - Edit the properties of this newly created user (still in the CMC) and make sure to check the option box "Enable Data Source Credentials for BusinessObjects Universes", - Fill the SAP credentials (username and password) to use for the user that is created in the first step. - Save the modifications and assign the needed rights to this user - Run Designer and create a new connection towards a SAP datasource - Use Authentication Mode "Use BusinessObjects Credential mapping" - A list of cubes and queries should be then proposed SAP login in the Universe Designer The Universe Designer supports SAP authentication. If logging in to the Universe Designer using SAP authentication and for a connection with logon set to SSO, the designing user will be logged into BW with the SAP credentials used to logon to the Universe Designer, where possible. If SAP credentials are not used when logging into the Universe Designer, it is not possible to design a universe configured for SSO. Note: This requires the SAP Authentication to be configured in the SAP BusinessObjects Enterprise (BOE) Central Management Console (CMC) as a pre-requisite Universe connection settings SAP login parameters When defining the universe connection parameters, there are 2 alternative options to define the SAP login information: With a direct access to a BW application server 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 Advanced connection parameters When defining the connection a few advanced parameters are available as indicated on the picture beside: Array fetch/bind size and login timeout parameters have no effect on a connection to BW. Page 24

25 The connection life-time option can have a significant impact when working with BW. It is strongly recommended to keep the connection life-time to the default option and to not disconnect after each transaction as this would significantly slow down the universe building process and also impact key end-user workflows such as working with hierarchical list of values. Examples of individual transactions which are executed within a single workflow are: Retrieving the list of dimensions Retrieving the list of hierarchies Retrieving the list of hierarchy levels To disconnect and reconnect in-between every transaction might lead to a performance overhead. However, it is important to note that the OLAP BAPI interface builds a metadata cache on the client side every time a connection to BW is established. This cache is only emptied when the connection shuts down. When working in parallel to edit BEx Queries and map new universes to these queries, it is therefore recommended to close the Universe Designer so that universe connections are also shut down and the metadata cache is emptied before building any new universes to take into changes that were just made on the BEx Query side. To minimize the risk of the metadata cache being desynchronized with BEx Query updates, the default universe connection life-time can also be changed to decrease its value from 10 minutes down to 1 minute Single Sign-On (SSO) When the user who is running a Web Intelligence report is defined as an SAP user on the BW system used in the universe connection, SSO to the database may be possible. The following criteria must be met for SSO: Universe connection is configured to use SSO Web Intelligence user connected is defined in BOE as an SAP user, or has an SAP user alias in BOE, on the BW system the connection is configured against One of the following is true: o When viewing on-demand, user signed into BOE using his SAP credentials or with an SAP Logon Ticket. o When viewing on-demand or scheduling, SNC with server-side trust (see Secure Network Communication environments) is configured between BW and the BOE server processing the request. Note that SNC support in Web Intelligence is available since the Fix Pack 2 of the version XI Secure Network Communication environments It is possible to configure Server-Side trust between the BOE processing servers and the BW system using Secure Network Communication (SNC). As highlighted in the Single Sign-On section, using Page 25

26 SNC is the way to achieve SSO in cases where the user s authentication against BOE is done with an account on a system other than the BW system used by the query, or in schedule-time cases. For details on configuring SNC, please refer to the section titled Configuring SAP Server-Side Trust in the guide: BusinessObjects XI Integration for SAP Solutions Installation and Administration Guide Scheduling When scheduling a Web Intelligence document there is no option to enter credentials that will be used for processing the query on the BW system. In order to successfully run the report, you must either: Define hard-coded user-id and password in the universe connection at design time. In this case, these credentials will be used for all scheduled instances, regardless of which user scheduled it. Define the universe connection to use SSO at view time, and meet the SSO requirements (see Single Sign-On). 3.2 BW authorizations for OLAP BAPI access BW system or dialog accounts are fine to work with universes and WebI. However, this section provides a list of SAP authorizations that are required to carry out common tasks with universes for BW. Additional authorization objects or fields may be required, depending upon your individual implementation. For more information on Authorizations for Data Warehousing in BW, follow this link. From each authorization object, you must create an authorization and define the appropriate field values. You then apply the appropriate authorizations to the profiles (or roles) of your SAP users. Page 26

27 3.2.1 Creating a new universe from a query or a cube in a BW role Object class Object Fields Values AAAB Crossapplication Authorization Objects S_RFC Authorization Check for RFC Access ACTVT - Activity Execute RFC_NAME Name of RFC to be protected RSOB, RZX2, SYST RFC_TYPE - Type of RFC to be protected FUGR RS Business Information Warehouse S_RS_COMP ACTVT - Activity - Business Explorer -Components RSINFOAREA - InfoArea * RSINFOCUBE - InfoCube * RSZCOMPID - ID of reporting component * RSZCOMPPTP - Type of reporting component All values S_RS_HIER - ACTVT - Activity Administrator Workbench - RSHIENM - Hierarchy name Hierarchy RSIOBJNM - InfoObject RSVERSION - Hierarchy version Create or generate, Display, Execute Display, Analyze * * * Page 27

28 3.2.2 Creating/refreshing a Web Intelligence query/report Object class Object Fields Values AAAB - S_RFC ACTVT - Activity Execute Crossapplication Authorization Objects Authorization Check for RFC Access RFC_NAME Name of RFC to be protected RSOB, RZX2, SYST RFC_TYPE - Type of RFC to be protected FUGR RS - S_RS_COMP ACTVT - Activity Business Information Warehouse Business Explorer -Components Create or generate, Display, Execute RSINFOAREA - InfoArea * RSINFOCUBE - InfoCube * RSZCOMPID ID of reporting component * RSZCOMPPTP - Type of reporting component All values S_RS_COMP1 ACTVT - Activity Business Explorer Components: Enhancements to the Owner S_RS_HIER Administrator Workbench Hierarchy S_RS_ICUBE Administrator Workbench -InfoCube Display, Execute RSINFOAREA - InfoArea * RSINFOCUBE - InfoCube All values RSZOWNER RS Owner (Person Responsible) * ACTVT - Activity Display, Analyze RSHIENM - Hierarchy name * RSIOBJNM - InfoObject * RSVERSION - Hierarchy version * ACTVT - Activity Display RSICUBEOBJ - InfoCube subobject All values RSINFOAREA - InfoArea * RSINFOCUBE - InfoCube * Page 28

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

30 5 Common scenarios and decisions While every implementation and individual reporting requirement is unique, most have common elements. The following section details several common scenarios you will come across and gives guidance on optimizing universe, Web Intelligence query, and BEx Query design for each scenario. 5.1 Customizing BW universe definition While the default universe generated for a BW query or cube is usable, it contains a lot of elements which might not be required for most reporting needs, and other elements which may require some tuning based on the detailed requirements Removing unnecessary L00 objects As specified in the section How BW characteristics are mapped and used in a universe, when a characteristic has no active hierarchy, the L00 node will be All members, and will not provide any reporting value. In this case, it is best to delete all L00 objects in order to simplify the report design experience. Even in cases where an active hierarchy does exist, the L00 objects may be unnecessary. In cases where there is only one top-level root of the hierarchy, it may be desirable to remove the L00 object for a hierarchy, unless it is necessary to report members which are not assigned in the hierarchy Removing unused or redundant detail objects It is recommended to remove or hide any detail objects from the universe which are redundant or unlikely to add value to reporting, in order to prevent report designing users from including them unnecessarily in queries Optimizing detail object syntax For queries on BW universes that include only the key and medium name detail objects of a dimension, it is possible to modify the generated syntax of the objects to improve query performance, due to some internal details of the OLAP BAPI interface. Page 30

31 To modify the syntax: 1. Open the universe in the Universe Designer 2. Double click the key detail object you want to modify 3. In the Select text box on the "Definition" tab of the "Edit Properties" dialog box, change the syntax to refer to the NAME attribute of the SAP characteristic For example, for the object L01 Customer Key, change the generated select syntax: [Z_CUSTOM].[LEVEL01].[[2Z_CUSTOM]].[Value] to refer to the NAME attribute: [Z_CUSTOM].[LEVEL01].[NAME] 4. Click OK to save the changes 5. Follow the same steps for the name object. Change the syntax to refer to the DESCRIPTION attribute of the SAP characteristic For example, for the object L01 Customer Medium Name, change the generated select syntax: [Z_CUSTOM].[LEVEL01].[[1Z_CUSTOM]].[Value] to refer to the DESCRIPTION attribute: [Z_CUSTOM].[LEVEL01].[DESCRIPTION] Adding keys to objects used in an LOV for filtering As indicated in the sections below on filtering, it is sometimes important that objects which have an LOV associated with them should always have a key which points to the underlying technical name for the characteristic values represented by the objects. By default, all Dimension objects automatically created when generating a BW universe have this defined. In cases where customization has been done or where detail objects are used in this way, this will have to be done manually as follows: 1. In the universe Designer, double-click the object to be used. 2. Select the Keys tab. 3. Insert a key entry as follows: Character Key Type: Primary Key Select: [<characteristic>].[tech_name], or [<characteristic>].[level<xx>].[tech_name] Page 31

32 For Example: Note: All objects based on OLAP Universes are generated with Index Awareness. Index Awareness brings 3 major improvments for OLAP Objects: Better performance (as the Index Awareness refers to the OLAP Object Unique Name: [<characteristic>].[tech_name], or [<characteristic>].[level<xx>].[tech_name]) Cascading LOVs in tree mode are displayed correctly Remove inconsistency in case of duplicate values for the concerned Object. You have to take into account that if you want to set a prompt that allows manual entry then the index awareness option becomes disabled. 5.2 Scheduling vs. on-demand reporting One of the first factors to consider when designing a report is whether it is necessary to have the report run on-demand or if the reporting need can be met by having users access scheduled instances of the report. In general, if is possible to minimize the number of times a report is run against the BW system, it is desirable to do so. So, it is recommended to use scheduling when practical. The primary benefits of scheduling rather than viewing on-demand are: Vastly improved viewing response time for the user Overall reduction in burden on the BW system versus having many ad-hoc queries run. Page 32

33 Scheduling is not viable for reports which meet one of the following criteria: Report has a high level of interactivity, especially when the user will be prompted for values which will filter a large portion of the results Report makes use of drill, to the point that orders of magnitude more data would be required to be read into the scheduled instance than would have been read in the user s combined initial view and likely drill workflows Different users have different views of the data returned by a query, either due to personalization or security reasons. Given the above factors, in some cases it will not be clear whether a single scheduled instance will result in a lesser load on the various processing systems than many smaller on-demand viewing requests. In some cases, experimentation will be required to determine the best approach. Note that, regardless of whether scheduling or on-demand viewing is chosen for a given report, it is still important to follow the recommendations laid out in the reminder of this document, in order to minimize the load on the BW system and Web Intelligence processing servers Hierarchies Defining custom hierarchies in the universe Creating custom universe hierarchies in BW universes is fully supported and behaves the same way as classic universe hierarchies. Universe hierarchies behave as drill paths and are similar to a set of characteristics with option Display as hierarchy set on (see paragraph Display as hierarchy ) Query Drill for hierarchies Multiple hierarchies can be defined at the Characteristic level. They will be automatically exposed in the universe. The Universe Designer capabilities to define and maintain drill-down paths in Web Intelligence should be leveraged to enable Web Intelligence users to drill down according to BW hierarchies as with any other custom universe hierarchies. It is important to note that the Use Query Drill option that is available in Web Intelligence Document Properties dialog helps to significantly improve the drill down performance. Activating this option can make Web Intelligence behave more like BEx in terms of fetching limited result sets when drilling down. Therefore it must be kept activated to have drill down performance in Web Intelligence as fast as within BEx. Of course, Web Intelligence user preferences (General Drill Options) also enables to prompt users for applying query filters when drilling. By default, Web Intelligence documents built on top of OLAP universes have the Use Query Drill option activated. Page 33

34 Use Query Drill option is incompatible with Scope of Analysis option. When Use Query Drill option is activated, Scope of Analysis option (available in the Query Panel) is grayed out, and vice versa Hierarchies with linked nodes Currently, using hierarchies which contain linked nodes may cause unexpected behaviour. Specifically, if a node which is returned by the Web Intelligence query is a linked node, Web Intelligence may display that node s parent as the original parent node, rather than the parent who linked to that node. A correction for this issue may become available in the future. Please consult SAP customer support for information on availability. 5.4 Filtering In all but the most basic cases, it is necessary to filter the data exposed by an InfoCube or BEx Query in order to get the desired result. There are several methods which may be employed to filter the results. The method applied may have an impact on the overall performance of the reports. Generally, filtering requirements can be separated into 2 categories: static filtering, which will apply the same values each time the report is run, and dynamic filtering, which will filter results based on user or other input. Filtering in the context of this section deals primarily with filtering based on characteristic member values and not filtering based on key figure values Static filtering of characteristic values Static filtering with Web Intelligence is only available for Characteristics and Hierarchies that used as of mandatory or free characteristics in the BEx query Static filtering with Web Intelligence Query filters Defining filters in the Web Intelligence query panel rather than in the underlying BW query provides a lot of flexibility and allows a single BW query and single universe to be reused for many Web Intelligence reports. By following a few simple guidelines, it is possible to implement quite wellperforming queries using static Web Intelligence filters. Use Inclusive member filters rather than exclusive ones. Avoid using Not Equal To, Not In, Not between, etc. in the filter pane of the Web Intelligence query panel. Due to the need to resolve filters to member-sets, these types of filters may impact the performance. When practical (typically in cases where the set of members selected is relatively small), Page 34

35 replace these types of filters with the inclusive equivalent. If this is not possible, consider doing the filtering in the BW query (see Static filtering with BEx Query restrictions). Filter on indexed values. In order to avoid the need to resolve member captions to member-unique names when viewing (see Resolving of Web Intelligence query filters to member selection), ensure that any characteristics which are filtered in Web Intelligence are filtered on indexed values. In order to ensure this, 2 things are required: 1. The object which is being filtered must have a key associated with it. That key must be the technical name of the underlying characteristic in BW. See for details 2. The value(s) for the filter must be selected from the LOV, rather than being typed in manually. If both of the above criteria are not met, the value entered or selected will have to be resolved to the member-unique name each time the report is run, causing needless overhead. The degree to which this is important varies depending on the cardinality of the characteristic: low-cardinality characteristics will not incur a severe penalty in doing member caption lookups. In any case, doing these lookups will always incur some overhead Static filtering with BEx Query restrictions When the suggestions in Static filtering with Web Intelligence Query filters cannot be practically followed, it may be necessary to consider altering or duplicating the relevant BEx query to impose the restriction. This has the advantage of always producing the best-performing report, but the disadvantage of added maintenance overhead and the need for potentially more BEx queries and universes to be defined if the filtered values needed are not the same for all consumers of the existing BEx query. Note: It is not necessary to update your universe after making this change to an existing BEx Query Dynamic filtering of characteristic values When filtering based on user selection of value(s), there are 2 basic approaches possible: defining the filter and prompt within the Web Intelligence query panel, or utilizing BEx Query variables. Dynamic filtering with Web Intelligence is only available for Characteristics and Hierarchies that used as of mandatory or free characteristics in the BEx query Dynamic filtering with BEx query variables As detailed in the section How BW variables are mapped and used in a universe, it is possible to define variables within a BEx Query and these will be exposed as universe prompts. There is a performance incentive to using this approach, as BW has some internal optimizations for handling variable-based restrictions. Page 35

36 Using variables rather than Web Intelligence filters also has the potential advantage of requiring less maintenance of prompt definitions, in cases where multiple reports source the same universe, and share some of the same prompted filtering requirements. Of course, in cases where different Web Intelligence reports have very similar data requirements but slightly differing prompting/filtering requirements, it may be preferable from a maintainability perspective to use a base query with no variables and implement the prompted filtering in the Web Intelligence queries instead. To replace existing Web Intelligence filters with BEx Query variables: Replace Web Intelligence Equal to filters with Single value BEx Query variables Replace Web Intelligence InList filters with Multi value BEx Query variables Replace Web Intelligence Between filters with Range BEx Query variables. Note: It is necessary to update your universe after making this change to a BEx Query Dynamic filtering with Web Intelligence filters When filtering on high cardinality characteristics, in order to avoid the need to resolve member captions to member-unique names when viewing (see Resolving of Web Intelligence query filters to member selection), ensure that any characteristics which are filtered in Web Intelligence are filtered on indexed values. In order to ensure this, 2 things are required: 1. The object which is being filtered must have a key associated with it. That key must be the technical name of the underlying characteristic in BW. See for details 2. The value(s) for the filter must be selected from the LOV, rather than being typed in manually 3. The prompt must be configured to Select only from list in the prompt options dialog. If all of the above criteria are not met, the value entered or selected will have to be resolved to the member-unique name before the report is run, causing needless overhead. The degree to which this is important varies depending on the cardinality of the characteristic: low-cardinality characteristics will not incur a severe penalty in doing member caption lookups. In any case, doing these lookups will always incur some overhead. Note: There is one case when the above recommendation to always use technical names as keys for filtering is invalid. When working with multiple Web Intelligence queries in a single document, Web Intelligence will share the prompt for filters in different queries which share the same prompt name. In the case where this sharing is desired and the underlying characteristic being filtered is not from the same InfoObject for both queries, it is essential to not have a key specified for the universe object being filtered, as doing so will result in the technical name for the first object being used, which will not be a valid identifier for the other object (based on a different underlying InfoObject) being filtered. In the case where this sharing is not desired, it is necessary to simply name the 2 prompts differently 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 Page 36

37 user with an initial list to choose from, it may be desirable to enable delegated search for the characteristic in the LOV. This will force the user to enter a pattern to match before any LOV values are returned, and will only request the member set from BW which matches the user s specified pattern. Delegated search is enabled in the Properties tab of the object properties dialog in the universe Designer. 5.5 Reports with high data volume The OLAP BAPI interface is not designed to run queries which return a high volume of data in a single request3. This is due both to internal design within the OLAP processor and to the flattening process which occurs before the data can be consumed by WebI. The volume of data returned can be measured by the number of cells returned. In general, it is desirable to reduce this number to the minimum required for the reporting requirement. This can be done by reducing the number of columns or rows returned in the request Reducing the size of rows by optimizing Web Intelligence queries Remove unused fields from the query While this may seem simple and not obviously necessary, it can have an important impact. During the process of Web Intelligence query and report creation, it is possible that fields may have been added in the query panel which are not actually used in the report. It is very important to review the query definition before publishing a document, and remove any fields from the query definition which are not actively used or desired to be made available during analysis. Web Intelligence will not optimize the query at run-time to remove those fields which are not required. It may also be desirable to customize the universe definition to remove any dimension or detail objects which are found to be redundant, avoiding the possibility of a user inserting multiple versions of the same thing into a report Refactor queries to extract more constant master data When creating reports which contain a lot of rows of data and display a lot of master data columns (typically Web Intelligence Detail objects / BW characteristic properties) which does not change perrow, it is worth considering splitting a single query into multiple queries to separate the more constant master data from detail records. Note that it is important to weigh the inherent cost of making additional queries against the savings realized by removing static master data from the mass result set. This approach should only be used when the number of unique master data values to be retrieved is at least an order of magnitude greater than the number of detail rows, and the number of master data fields is relatively large. 3 : SAP BusinessObjects Data Federator can be implemented to address requirements for running queries which return large result sets. Please refer to the Data Federator product documentation for more information on these capabilities. Page 37

38 Following is an example to illustrate this case: The above screenshot shows a query definition with Customer, Order Date, Order ID, plus a couple of measures. Please note that we are including 7 Detail objects from the Customer dimension. Below is the report in which you can see that we have many detail rows for a single Customer (City Cyclists): Although the customer detail fields are only displayed once in the report, they are in fact fetched and replicated once per row in the MicroCube. For each row in the result set, the number of cells returned will be 15: 2 for Order Date (index and value) 2 for Order ID (index and value) 1 for Delivered Value 1 for Order Quantity 9 for Customer (value, index, 7 detail cells) Page 38

39 If we assume there are 1000 rows returned per customer, then the number of cells in the result set is 15,000 in this case. Now, we split this query into a master data query and a detail query as follows: Master data query: Notice that there is a Key Figure from the Detail query included in the Master Data query. This is to ensure that only master data entries with corresponding data are returned by the Master Data query. This is more important when your Master Data query contains more than one characteristic (see Creating queries for Master Data reporting). Detail Query: Page 39

40 The result in the Data pane of the Web Intelligence report panel is: Notice that the 2 L01 Customer dimension object have been merged under a single L01 Customer object. To configure merged dimensions, right-click a dimension and select Edit Merged Dimension (shown below): At this point, a Web Intelligence report can be designed in the same way as the original example, but the resulting number of cells returned per detail row will be 8: 2 for Order Date (index and value) 2 for Order ID (index and value) 1 for Delivered Value 1 for Order Quantity Page 40

41 2 for Customer (value, index) The number of master data cells returned will be 9: 9 for Customer (value, index, 7 detail cells) If we assume there are 1000 rows returned per customer, then the total number of cells in all the result sets is now 8,000 (detail data) plus 9 (master data), a reduction of nearly 7,000 cells when compared to the original design. While this is a somewhat simplistic example, the concept is extensible to more complex scenarios involving reporting off master data and a high number of rows of data Reducing the number of rows per request by using guided navigation Another approach to reducing the number of cells returned per request, and indeed the total number of cells, is to employ more guided navigation techniques in reporting, rather than presenting the user with both high-level aggregates and details up front. This technique is appropriate when the total set of data exposed by a report is vast, and the user is likely to be interested in all of the highly aggregated data but only specific details. There are 2 main methods to achieving this: using drill-down in the report, and using report linking Using Drill Drill can be used within your Web Intelligence report as long as you have a hierarchy defined. It is possible to use either BW hierarchies or custom hierarchies defined in the universe for drill. In order to have only the data for the current drill context fetched, rather than the entire dataset being fetched upfront, ensure that Use query drill is checked in the Web Intelligence document properties. As the query used to process the drill is essentially the same as any other filter request, it is important to use ensure that objects to be used for drill also have an index defined when drilling, as specified in the section Static filtering with Web Intelligence Query filters Using Report Linking As another alternative to using drill, you may choose to use report linking. In this case, you would define an initial report which contained only the highly aggregated levels of data which the user will use to decide where more information is desired. Report linking is much more flexible in that you may define links at any level desired, and reports linked to do not have to maintain the same formatting (or indeed, have much data in common at all with the source report). All that is required is a relationship between the data in the source context and the data in the target. It is important to follow the same techniques when linking to a report as are followed in the other dynamic filtering cases specified in the section Dynamic filtering with Web Intelligence filters, in order to avoid unnecessary member caption resolution in processing the query for the target report. Page 41

42 5.6 Creating queries for Master Data reporting In order to create appropriate Master Data queries for reporting in WebI, it is necessary to understand what each type of Master Data query will request from the BW system. Following are 3 high-level types of Master Data queries: 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 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 Query containing multiple characteristics In this case, values will be read by creating an MDX statement including several characteristics and all measures. The reason for this is that if no measures are included, the cross join of the 2 characteristics will result in a Cartesian product, which delivers no value and is quite expensive. Unfortunately, including all measures adds a lot of unnecessary calculation and memory overhead, and can easily push the result set over the million cell limit if there are many measures. Note: One million cell limitations had been removed in BusinessObjects Enterprise XI 3.1 Fix Pack 1.2 and also need to be used with SAP Netweaver BI 7.0 EhP1. As a result, it is recommended to add at least one measure to the Web Intelligence query. Note that the result in this case will include only members which have data for at least one of the measures included in the query. So it is important to include a sufficient set of measures to ensure that all desired members are included, but no more measures than that. Note: If you want to retrieve all members from all characteristics, you can create a calculated measure in the universe that will ensure you to retrieve all members. This solution has to be used very cautiously as it will also retrieve a Cartesian product. You can create an object in a universe having the following definition: <EXPRESSION>1</EXPRESSION> Page 42

43 5.7 Leveraging structures in a BEx query The BEx Query Designer allows you to build custom structures as part of your BEx query. You can think of a structure as a characteristic. However, structural components can be complex objects (selections, formulas ). A classic example of a structure would be a structure comparing the actual and planned amounts of a key figure. As shown below you can identify a structure which shows the Actual Amount and the Planned Amount of the key figure Amount. The 2 elements of the structure are selections where the key figure Amount is restricted to the type Actual or Planned: The additional 2 items in the structure are formulas which calculate the variance between the 2 amounts and the variance as a percentage value. Page 43

44 5.7.1 Queries with multiple structures One BEx query can contain up to 2 structures. In the case where the user creates a query which contains 2 structures, the user created a query that creates a very well defined result set which will based on the definition result in a grid layout. The query in the above screenshot contains 2 structures: The first structure is a grouping of countries into specified groups: USA, Europe, and Asia Pacific The second structure contains 3 key figures In addition, the query contains 3 additional characteristics in the free characteristic area. For reporting purposes the usage of a custom structure can help to provide the right information for the report at the right level. Page 44

45 As a concrete example let s assume the original query returns the following result set: Country Region Calendar Month Sales Amount Costs USA NY USA WA Canada BC Canada AB Germany France Now, by creating a query with 2 structures you could create the following result set: Sales Sales Area Q1 Q2 North America Europe In this case North America is a representation of USA and Canada, Europe is a representation of Germany and France, and the Sales figures have been aggregated for the first and second quarter. Depending on the actual requirements for the reporting landscape this capability can become very helpful for multiple reasons: A structure will leverage the underlying SAP backend to perform the calculation and aggregation A structure can be shared across multiple queries, which reduces the amount of required maintenance By using a structure in the underlying source every user will receive an identical definition of the summarized and combined values. When using a query with multiple structures, the resulting Web Intelligence query will be representative of this grid layout. 6 BW Performance tuning This section deals with some aspects of performance tuning within the BW system itself, which have a significant effect on reporting performance. This is intended mainly to highlight some of the key areas. Page 45

46 For details on all aspects of tuning BW performance for reporting, refer to the appropriate BW documentation. 6.1 Performance impact of data modelling Line item dimension and high cardinality When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in which case almost every entry in the fact table is assigned to a different document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension. You can use the indicators line item and high cardinality to execute the following optimizations: Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages: When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved A table with a very large cardinality is removed from the star schema. As a result, the SQLbased queries are simpler. In many cases, the database optimizer can choose better execution plans. Nevertheless, it also has a disadvantage: a dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with regular dimensions. High cardinality: This means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality. A simple way to retrieve the necessary information is to leverage the program SAP_INFOCUBE_DESIGNS (run the SE38 transaction in the SAP Frontend, then type and execute the SAP_INFOCUBE_DESIGNS program). A very generic rule is that the dimension table should not take more than 10% of the fact table. Page 46

47 Sample screenshot from SAP_INFOCUBE_DESIGNS: Navigational Attributes Characteristic attributes can be converted into navigational attributes. They can be selected in the query in exactly the same way as the characteristics for an InfoCube. In this case, a new edge/dimension is added to the InfoCube. During the data selection for the query, the data manager connects the InfoProvider and the master data table ( join ) in order to fill the Query. From a pure performance point of view, you should model an object on a characteristic rather than on a navigational attribute: In the enhanced star schema of an InfoCube, navigational attributes lay one join further out than characteristics. This means that a query with a navigational attribute has to run an additional join (compared with a query with the same object as a characteristic) in order to arrive at the values. This is also true for Data Store Objects. For the same reason, in some situations, restrictions for particular values in the navigational attribute (values that have been defined in the query) are not taken into account by the database optimizer when it creates run schedules. This can result in inefficient run schedules, particularly if the restrictions are very selective. In most cases, you can solve this problem by indexing the navigational attribute in the corresponding master data tables (see below). If a navigational attribute is used in an aggregate, the aggregate has to be adjusted using a change run as soon as new values are loaded for the navigational attribute (when master data for the characteristic belonging to the navigational attribute is loaded). This change run is usually one of the processes critical to the system performance of a productive BW system. This is why avoiding using navigational attributes, or not using navigational attributes in aggregates, you can improve the performance of this process. On the other hand, not using navigational attributes in Page 47

48 aggregates can lead to poor query response times. The data modeler needs to find the right balance Overall reporting performance Query monitor The Query monitor is a tool which allows administration, testing and monitoring of SAP BW Queries. The tool can be used to generate, test and configure properties (SAP documentation for the Query monitor: The Query monitor can be started using the transaction RSRT Read Mode In the Query Properties dialog box for the query monitor you can make settings for a BW query with regard to the read mode, the cache mode, the selection of structure elements, the optimization mode and the calculation accuracy. You can switch off the default Parallel Processing for queries on a MultiProvider The read mode determines how the OLAP processor gets data during navigation. You can set the mode in Customizing for an InfoProvider and in the Query Monitor for a query. The following types are supported: Query to be read when you navigate or expand hierarchies (H) The amount of data transferred from the database to the OLAP processor is the smallest in this mode. However, it has the highest number of read processes. In the following mode Query to read data during navigation, the data for the fully expanded hierarchy is requested for a hierarchy drilldown. In the Query to be read when you navigate or expand hierarchies mode, the data across the hierarchy is aggregated and transferred to the OLAP processor on the hierarchy level that is the lowest in the start list. When expanding a hierarchy node, the children of this node are then read. You can improve the performance of queries with large presentation hierarchies by creating aggregates on a middle hierarchy level that is greater or the same as the hierarchy start level. Query to read data during navigation (X) The OLAP processor only requests data that is needed for each navigational status of the query in the Business Explorer. The data that is needed is read for each step in the navigation. In contrast to the Query to be read when you navigate or expand hierarchies mode, presentation hierarchies are always imported completely on a leaf level here. Page 48

49 The OLAP processor can read data from the main memory when the nodes are expanded. When accessing the database, the best aggregate table is used and, if possible, data is aggregated in the database. Query to read all data at once (A) There is only one read process in this mode. When you execute the query in the Business Explorer, all data in the main memory area of the OLAP processor that is needed for all possible navigational steps of this query is read. During navigation, all new navigational states are aggregated and calculated from the data from the main memory. Read Mode Advantages Disadvantages Recommendation Read all data Fast query navigation after the first call because all the data is being cached First call will be slower Limitation in the use of aggregates Should be used for smaller InfoCubes only More memory in the OLAP cache required Should only used for queries with few free characteristics First call will be fast because only required data is being selected Requires additional call for further navigation steps Should be used for small hierarchies Good usage of aggregates Good response for small hierarchies Should be used with larger quantities of results First call will be fast because only required data is being selected The smallest amount of data is being selected for the first call This mode should be used to leverage hierarchy aggregates Read data during navigation Read data when navigate or expand hierarchies 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. Page 49

50 The system displays performance-relevant information for the query that does not correspond to the system recommendations ( ). The information refers to the following areas: Query definition: Query cannot use aggregates (corresponds to specifications in Technical Information under OLAP-Relevant Data) and is related to the read mode X or A. Query cannot use the cache (corresponds to specifications in Technical Information under OLAP-relevant Data). InfoProvider: InfoProvider is a MultiProvider Database statistics need to be checked Database indexes need to be checked Especially the last set of information on the InfoProvider could help in regards to increase the performance when it might be necessary to verify the Database statistics (could lead to new aggregates) and the database indexing. Page 50

51 Debugging options in the query monitor As part of the Query Monitor you have the option to activate the debugging for the query and you can select from a large set of options. The option to Display Statistics Data in the Others area is very helpful because it will show you in a very simple way where the time is being spend during the process of a BW Query. Page 51

52 Below an example of the display after the execution of a BW Query: The numbers shown will also show up in transaction ST03 but in case you only need the information for one particular case this might be much easier. Especially the information QDBSEL (database selected records) and QDBTRANS (transferred number of records) is helpful in evaluating the need for aggregated data. The measurements starting with QTIMExx are showing where the time was spent during the process. Page 52

53 6.2.2 Transaction ST03 The Workload monitor (transaction ST03) allows you to quickly identify the statistics around query performance from the BW System. Switch to the Expert Mode of the tool to get all available functionality. Navigate to the BW System Load area and you can retrieve the data based on cube or query level. Page 53

54 A high ratio on database selected records and Select./Transf. is an indication for a need of further aggregated data. 6.3 Relevant SAP Notes The following is a list of some SAP notes which are particularly relevant to addressing issues in using Web Intelligence against BW. This is not an exhaustive list. For other notes, it is recommended to check the release notes and/or supported platforms list. Notes and for improving performance of caption resolution Note and for improving performance when working with BW hierarchies. Note for general OLAP BAPI performance In order to take advantage of the performance improvement that is part of the FixPack 1.2 for BusinessObjects Enterprise XI 3.1, the following SAP Notes are mandatory (on top of SAP NetWeaver BI 7.01 SP2): v4, v6, v1, v1, v1, v1, v3, , , You need to install as well the following dependent SAP Note (still on top of SAP BI 7.01 SP2) : fixes the memory leak issue in rfclib. Page 54

55 7 Troubleshooting In this section, you will learn about the tools that are available to you to troubleshoot and trace the SAP connectivity for WebI. 7.1 Tracing and troubleshooting the Web Intelligence activity Activating Web Intelligence traces allow having access to the XML generated query. This is the best way to: Copy filters definition to be reused in universes Understand prompts and variables resolution Debug To activate Web Intelligence traces, you have to register 3 environment variables. BO_TRACE_CONFIGDIR = %MyPath% BO_TRACE_CONFIGFILE = %MyPath%\bo_trace.ini BO_TRACE_LOGDIR = %MyPath% The 3 environment variables reference a file BO_trace.ini stored in %MyPath% This file contains the following information: Active = true; Keep = true; Importance = '<<'; Size = ; When the traces are activated, Web Intelligence and Universe Designer write logs in %MyPath%. Here is a screenshot of possible log files name: Page 55

56 Only files having name like WebIRichClient.trace.log and having the latest modification date are relevant for debugging the generated XML. You have to pay attention that you can find several files and only file ending by _trace.log is worthwhile (do not open file ending by jtrace.log ). An XML string enclosed by <DPCOMMANDS> and </DPCOMMANDS> tags contains the XML query. This XML is then sent to the OLAP driver (ODA) that will translate it in MDX statement. Once you have opened a file, search for the string </DPCOMMANDS>. Here is a sample query with an SAP variable before prompt resolution: <DPCOMMANDS> <DPCOMMAND> <DP> <QUERY> <QUERYRESULT> <QUERYOBJECT KEY="[0CALYEAR].[LEVEL01]" /> <QUERYOBJECT KEY="[Measures].[D4ZE950PAZX9G2YWNEWFTM30F]" /> <QUERYOBJECT KEY="[Measures].[A1]" /> <QUERYOBJECT KEY="[Measures].[A1].[UNIT]" /> <QUERYOBJECT KEY="[Measures].[A1].[FORMATTEDVALUE]" /> <QUERYOBJECT KEY="[Measures].[B2]" /> <QUERYOBJECT KEY="[Measures].[B2].[UNIT]" /> <QUERYOBJECT KEY="[Measures].[B2].[FORMATTEDVALUE]" /> <QUERYOBJECT KEY="[Measures].[D4]" /> <QUERYOBJECT KEY="[Measures].[D4].[UNIT]" /> <QUERYOBJECT KEY="[Measures].[D4].[FORMATTEDVALUE]" /> </QUERYRESULT> <QUERYSCOPE /> <QUERYCONDITION> <WHERE> <FILTER KEY="[0D_DISCH]"><CONDITION OPERATORCONDITION="Between"><CONSTANT TECH_NAME="[0D_DIS_CHAN].[10]"/><CONSTANT TECH_NAME="[0D_DIS_CHAN].[10]"/></CONDITION></FILTER> </WHERE> Page 56

57 </QUERYCONDITION> </QUERY> </DP> </DPCOMMAND> </DPCOMMANDS> Here is the same sample after prompt resolution: <DPCOMMANDS> <DPCOMMAND> <DP> <QUERY> <QUERYRESULT> <QUERYOBJECT KEY="[0CALYEAR].[LEVEL01]" /> <QUERYOBJECT KEY="[Measures].[D4ZE950PAZX9G2YWNEWFTM30F]" /> <QUERYOBJECT KEY="[Measures].[A1]" /> <QUERYOBJECT KEY="[Measures].[A1].[UNIT]" /> <QUERYOBJECT KEY="[Measures].[A1].[FORMATTEDVALUE]" /> <QUERYOBJECT KEY="[Measures].[B2]" /> <QUERYOBJECT KEY="[Measures].[B2].[UNIT]" /> <QUERYOBJECT KEY="[Measures].[B2].[FORMATTEDVALUE]" /> <QUERYOBJECT KEY="[Measures].[D4]" /> <QUERYOBJECT KEY="[Measures].[D4].[UNIT]" /> <QUERYOBJECT KEY="[Measures].[D4].[FORMATTEDVALUE]" /> </QUERYRESULT> <QUERYSCOPE /> <QUERYCONDITION> <WHERE> <FILTER KEY="[0D_DISCH]"><CONDITION OPERATORCONDITION="Between"><CONSTANT TECH_NAME="[0D_DIS_CHAN].[10]"/><CONSTANT TECH_NAME="[0D_DIS_CHAN].[10]"/></CONDITION></FILTER> </WHERE> </QUERYCONDITION> </QUERY> </DP> </DPCOMMAND> </DPCOMMANDS> Page 57

58 7.2 Tracing and troubleshooting the OLAP driver connectivity (ODA) To be able to trace the SAP connectivity for Web Intelligence the necessary registry entries need to be configured. The entries can be found in the following part of the registry: HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Suite 12.x\MDA\Log. The image shows that underneath the Log entry, each module of the OLAP connectivity can be configured for tracing. For the SAP connectivity, the relevant registry values are: HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Suite 12.x\MDA\Log\Modules\SAPMODULE o o Verbosity (highest value is 10 decimal) MDX Query Log (full path to the log file) HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Suite 12.x\MDA\Log o LogFile (full path to the log file) These traces are instrumental when troubleshooting or merely seeking to understand what is happening between the lowest level of SAP BusinessObjects XI 3.x software and the BW system. However, at the highest verbosity levels the axis and member data is written to the log, potentially incurring a significant runtime penalty. The recommendation is to use the following trace levels: Page 58

59 0 for production systems 5 during general development and UAT 10 only when troubleshooting These settings will generate 2 log files: An MDA log file that includes all steps that have been performed on the SAP server side A MDX log file that includes all executed MDX statements. Note: After setting the registry value the corresponding services from BusinessObjects Enterprise need to be restarted (Web Intelligence services, Connection Server). Note: To stop recording the MDA logs (known as SOFA logs) and MDX logs, the services from BusinessObjects Enterprise need to be stopped. Then the registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Suite 12.x\MDA\Log\Modules can be removed. At last, the services from BusinessObjects Enterprise need to be restarted (Web Intelligence services, Connection Server). 7.3 Additional troubleshooting tools This section covers additional tools and techniques used to troubleshoot BW connectivity: OLAP BAPI functions The OLAP trace tool RSRTRACE The MDX Test editor (transaction MDXTEST) Using OLAP BAPI functions The connectivity for BW is based on OLAP BAPI functions from SAP. These BAPI functions can be executed using transaction SE37 (Function builder). Each of the BAPI functions is different and accepts a different set of input parameters and will provide a different result set. When getting unexpected results from the flow outlined in APIs used in creating an OLAP universe or, it may be desirable, in combination with analyzing the log files, to verify the results of some of the BAPI functions from within the SAP GUI. The following are 2 outlines showing how to use the OLAP BAPI functions. Note that the values specified for the parameters are to be replaced with values relevant to your troubleshooting task. Page 59

60 To call the BAPI function BAPI_MDPROVIDER_GET_CUBES Start the SAP Logon pad Log onto the SAP system Start transaction SE37 (Function Builder) Enter the function name BAPI_MDPROVIDER_GET_CUBES into the field Function module 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) Page 60

61 8. Click on the icon next to the number of entries for your result set Note: You can export the result set via the menu System > List > Save > Local file. Page 61

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

63 END_ROW The numeric value for a row 4. Enter the input parameters 5. Select the menu Function modules > Execute (F8) Page 63

64 6. Click on the icon next to the number of entries for your result set Note: You can click Single Entry to view all values for one row Using the OLAP trace tool (RSRTRACE) The OLAP trace tool allows you to trace all OLAP related functions on the BW server. The benefit of the tool is that the actual trace is stored on the BW server and in this way the steps can be recalled. Page 64

65 To activate the OLAP trace 1. Start the SAP Logon pad 2. Log onto the SAP system 3. Start transaction RSRTRACE 4. Enter the user name into the field User 5. Click Activate User 6. Perform the tasks that have to be traced Page 65

66 To view the results of an OLAP trace 1. Start transaction RSRTRACE 2. Click All Logs Note: The option User logs shows the logs that belong to the current user. Note: A list of logs is displayed and the administrator is able to view them. 5. Double-click the log entry Note: All used functions are listed and can now be entered via the ABAP debugger MDX Testeditor By using the MDX Testeditor the user can test BEx queries by entering an MDX statement. You may use this to simply test that the query you are reporting off has data, or to validate the results returned by the MDX generated as a result of a Web Intelligence query. The example below uses a function of the MDX Testeditor to generate a sample MDX statement for a query. For details on retrieving the MDX generated as a result of a Web Intelligence query, see the section Tracing and troubleshooting the Web Intelligence activity or Using the OLAP trace tool (RSRTRACE). To start the MDX Testeditor: 1. Log onto the SAP server 2. Start transaction MDXTEST (MDX Testeditor) Page 66

67 Note: In the MDX Testeditor the phrase CATALOG refers to the BW cube and the phrase CUBE refers to the BEx query. 3. Select the BW cube from the list box CATALOG Note: The entry InfoProvider refers to the option to connect directly to cubes without the usage of a BEx query. 4. Select the BEx query from the list box CUBE Page 67

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

69 6. Click Run Query Multidim. to execute the MDX Statement Note: The partial results of the MDX Statement are displayed in the bottom pane of the MDX Testeditor. 7.4 Troubleshooting scenarios The following is a list of potential problem scenarios that and some recommendations on identifying the issue 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? Page 69

70 In case you receive less dimensions than expected (keep in mind that dimensions from the Filter area of the BEx Query will not show up in the OLAP universe) in the BAPI Function you should switch on the traces for the MDA.log (seetracing and troubleshooting the OLAP driver connectivity (ODA)) and Web Intelligence traces WebIRichClient.trace.log (see Tracing and troubleshooting the Web Intelligence activity) and send the log files and a screenshot of the query to SAP Customer Support In case you receive error messages in the BAPI Function it indicates an error that should get transferred to SAP Customer Support Scenario 2: SAP Variables are not showing up in WebI In this scenario we will assume that the user was able to create the OLAP universe but the user is missing a prompt for a SAP Variable. As a first step open the Query in the SAP BEX Analyzer and verify for which items the user is getting prompted and compare it with WebI Open the universe in the universe Designer and verify if the LOV definition shows up in the universe itself In case you still are not getting prompted and SAP BEx Analyzer is prompting the user, start transaction SE37 and execute the function BAPI_MDPROVIDER_GET_VARIABLES Switch on logging and create a new universe based on the query and examine the log file Scenario 3: Values are missing in the List of Values for prompting In this scenario we will assume that the List of values shown in Web Intelligence does not match the List of Values shown in SAP Business Explorer Web Intelligence is missing some members. as a first step create a new query without the SAP Variable and generate a Web Intelligence report for the dimension that is using the SAP Variable to see if the value shows up without using an SAP Variable Switch on logging and execute the report with the SAP Variable and search the log file for the value that should be part of the List of values Open the Logfile and search for <DPCOMMANDS (see Tracing and troubleshooting the Web Intelligence activity). There is an XML definition for each prompt and one for the report. After the XML Definition for the prompt the values are loaded and shown in the log file You can also use the function BAPI_MDPROVIDER_GET_MEMBERS to verify the List of values In case you want to verify a single missing value you can also use the function BAPI_MDPROVIDER_GET_MEMBERS and provide as much input values as possible. Page 70

71 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].[ ] for this dimension. This would verify if the member exists in the SAP system for the selected dimension Scenario 4: Data is missing when executing the report In this case we assume that the universe is correct and that the user can see all SAP Variables correct, but that the report when executed is not providing any data. As an initial step run the query inside the SAP BEx Analyzer with identical user credentials and identical SAP Variable values to see if data exists and if data gets returned for the selected parameter values If that is the case activate logging and execute the report again When the report has been finished open the MDA log file (seetracing and troubleshooting the OLAP driver connectivity (ODA)) and search for the wording MDDataSetBW.SelectData You should see above that line an MDX Statement Use this MDX Statement and run the MDX Statement in transaction MDXTEST. Make sure the MDX statement makes sense. What is meant by that? Open the MDA log and search for the text <DPCOMMANDS. In case the report makes use of SAP Variables you will see this multiple times (once for each prompt and once for the report). Page 71