Best Practice Document for Creating BEx Query and Workbook Version 1[1].0

Volvo Information Technology 1

Best practice document for creating BEx query and workbook

Volvo Information Technology 2

The reason for the concern…

The main attribute to major concern is performance of the system. Since BW is analytical system it’s expected to have reports with good response and correct data.

It has also been observed that the performance reduces over the time. There are various reasons for this. It is possible to eliminate all this with proper approach.

Volvo Information Technology 3

Query Design –Multi-Dimensional Navigation

Volvo Information Technology 4

Query Design – Inclusion / Exclusion

Volvo Information Technology 5

Query Design – Multiprovider

Volvo Information Technology 6

Query Design – Others

Volvo Information Technology 7

Query Performance – Infocube compression

Volvo Information Technology 8

Query Performance - Authorization

Volvo Information Technology 9

Reporting performance – Web reports perform better than BEx…

Volvo Information Technology 10

Query Performance – Front End / Network

Volvo Information Technology 11

Query Performance – Frontend performance and Network

The following factors primarily determine the time needed to transfer data from the application server to the front end.

• The bandwidth of the network, that is, the maximum quantity of data transferred per time unit

• The number of protocol roundtrips

• The latency period of a protocol roundtrips, that is, the time it takes to transfer an information package from the sender to the recipient and back again.

• The quantity of data being transferred.

(The communication between the SAP BEx front end with the application server is based on the DIAG protocol developed by SAP for communication between the SAPGUI and the application server. During the connection between the application server and frontend with the protocol, the dialog step generates several communication steps called round trips. The roundtrips transfers data from Synchronous RFS from the application level to GUI.)

Volvo Information Technology 12

Query Performance – High frontend runtime

What can I do if a query has a high frontend runtime?

Check if a very high number of cells and formattings are transferred to the Frontend ( use "All data" to get value "No. of Cells") which cause high network and frontend (processing) runtime.

Check if frontend PC are within the recommendation (RAM, CPU Mhz)

Check if the bandwidth for WAN connection is sufficient

Volvo Information Technology 13

Query Performance – Aggregates can improve query performance considerably

Volvo Information Technology 14

SAP Note 852700 - Performance issues with Excel Calculations in the Analyzer

In BEx Analyzer workbooks, if there are a lot of excel formulae on the result set of the embedded queries, and the excel calculation mode is set to automatic, then the refresh of the queries in the workbook takes a long time.

It’s recommended to set the calculation mode from 'Automatic' to 'Manual'.

Workbook Performance – Excel Calculations

Volvo Information Technology 15

SEM – BCS Reporting Performance

You are using SEM-BCS and are searching for the Best Practices for optimizing the performance of BW reporting…

Note 842537 - BW reporting for SEM-BCS - status and enhancements

A) Fundamentals for reporting with SEM-BCSThe virtual InfoProvider is a central component of reporting consolidated data - it interprets the master data and Customizing of the consolidation at the moment you call the report and it reads the data records from the transactional InfoCube according to BCS selection logic. This procedure enables you to call, at any time, a consolidated report in real-time that is based on the most current master data and flow data and as a result the system cannot take full advantage of the most powerful "performance arm" of BW, that is, the creation of aggregates, for the virtual InfoProvider.

You can indeed improve the runtime by "Reporting InfoCube" below. This InfoCube can be optimized with all BW technology regarding performance

B) Conceptual enhancements - Configure the Delta Load Multiprovider Scenario In application scenarios with high data volumes, this reduces considerably the number of data records to be read using the virtual InfoProvider.

C) New functions for the High Performance in BI 7x – BI Accelerator For SEM-BCS, this new technology provides new optimization potential for the selection of data from the precalculated Reporting InfoCube

Note 842537

Volvo Information Technology 16

Query Performance – Other points

• For all calculations that have to be performed before aggregation (like currency conversion), consider if it could be done during data load.

• Use tight restrictions on time characteristics; ideally request only current values.

•Turn off formatting and results rows to minimize Frontend time whenever possible.

•If "Display as hierarchy" is being used, look for other options to remove it to increase performance.

•Turn off warning messages on queries.

•Leverage characteristics or navigational attributes rather than hierarchies. Using a hierarchy requires reading temporary hierarchy tables and creates additional overhead compared to characteristics and navigational attributes. Therefore, characteristics or navigational attributes result in significantly better query performance than hierarchies, especially as the size of the hierarchy (e.g., the number of nodes and levels) and the complexity of the selection criteria increase.

• If hierarchies are used, minimize the number of nodes to include in the query results. Including all nodes in the query results (even the ones that are not needed or blank) slows down the query processing. The “not assigned” nodes in the hierarchy should be filtered out, and you should use a variable to reduce the number of hierarchy nodes selected.

Volvo Information Technology 17

Query optimization

Z0_CFD

Before Generation After Generation

Why use Query Optimization?When working with this mass generation, a few observations have been made. In general, it have been seen anywhere between a 5% and a 250% increase in performance. Every time a query is run, the flag OPT_OCCURS marks the query “not-optimized”. This does not actually mean the performance has degenerated. In actuality, tests show that queries generally run ok for 2 to 5 days before re-generation is needed. This is due to how quickly your model changes. This means that if your data grows a lot, aggregates change, stats change, etc… The optimization changes the code of the query to optimize it on how the system currently looks. If this changes frequently, optimization may need to occur more often. If it changes in-frequently, then scheduling this every few weeks may not be a bad idea. The enhancement allows you to only regenerate queries that have been run since being last optimized. To do this, you would copy program RSR_GEN_DIRECT_ALL_QUERIES to a Z Program, and then add the 2 lines of code below. If you wanted, you could also enhance this program to add the query technical name as an input field. That way, you could choose individual queries that you wanted to generate.

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3075

Volvo Information Technology 18

Query Performance – Database Indices

Indices speed up data retrieval for a given selection tremendously by avoiding full table scans. For querying data, the necessary indices must be available and up-to-date. In ORACLE, fact tables can be indexed either by bitmap indices or by B-tree indices

Volvo Information Technology 19

Analysis and Repair of BW Objects (RSRV)