Exclude query to use BW Accelerator (BWA)

What's in a name :
High Performance Analytics(HPA) became Business Intelligence Accelerator(BIA) which became Business Warehouse Accelerator(BWA) which will, eventually, become Open Database Analytics(ODA).

Anyway: After you've enabled a cube to be indexed/loaded to the BWA, all queries belonging to that cube will be executed via the BWA. You're able to exclude a particular query, belonging to a "BWA-cube", to be ran via the BWA.
Find the query which shouldn't use the BWA via SE16 and table RSRREPDIR.
Within table RSRREPDIR, set field NOHPA (=Do Not Use HPA Index) to 'X' and save the change. From now onwards, the particular query will not use the BWA eventhough the cube it "runs" on is BWA enabled.

Debug startroutine in BI 7.0

Within BI 3.x it was quite easy to debug your startroutine. Pressing the sequence F7 -> F6 -> F5 brought you directly to the startroutine (code). Within BI 7.0 the "F7->F6->F5" trick doesn't work anymore.
To debug a startroutine in BI 7.0, the following steps need to be executed:

1) Go to Display Generated Program within the transformation

2) Jump all the way down to find some startroutine coding you recognize :-) and place a break-point.

3) Find the load you want to debug within the DTP monitor

4) Press the debugging button

5) Execute the debugging request and the execution will stop at the break-point which has been created/set at step 2.


Big thanks go out to Freek Geldof who provided the necessary information!

ADAPT: Application Design for Analytical Processing Technologie

I had the pleasure to attend a training at SAP Netherlands in which the ADAPT modeling methodology was explained. As I've become very enthusiastic about this modeling "tool", I'd recommend you all to read the following white paper, written by the Symmetry Corporation.

Hierarchy on navigational attribute decreased query performance

A multiprovider, based upon 5 different infoproviders and 2 infoobjects, was causing a performance drain whenever a query was executed.
Every query, based upon this multiprovider, contained a hierarchy on a navigational attribute of an infoobject.
Eg. Infoobject A --> navigational attribute B --> Hierarchy C.
To make sure that the hierarchy was displayed correctly, also infoobject B was added to the multiprovider, eventhough this had no added value (as no "fact" data was to be displayed which "belongs" to infoobject B)
Infoobject B (IOB in the picture below) is a navigational attribute of 0MATERIAL

Infoobject B (IOB) has been added to the multiprovider and was identified (assigned) via the checkbox.
After the checkbox was "un-ticked" (as seen in the picture above; red arrow) and thus infoobject B was no longer part of the identification, the query performance increased.
Conclusion: Know what you're doing when inserting infoobjects in a multiprovider as mis-usage can drastically decrease performance!

Making an added function module (to a function group) visible in SE80

After creating an (additional) function module within a function group, it wasn't visible within SE80 after it was transported to another BW system.
When displaying the function group, via transaction SE80 --> Function Group, the newly created function module WAS NOT visible, even though the import/transport ended without errors.
The trick, to make all function modules visible within the function group, is to update the navigation index as shown in the screen-grab below: