Skip to Content

Using SE37 to verify Netweaver meta-data used by Voyager

Voyager consumes data from Netweaver using the OLAP BAPI interface. Sometimes a useful trouble shooting tool is to verify the results the OLAP BAPI delivers with what can be seen in Voyager. The same OLAP BAPI API calls that Voyager makes can also be accessed through the SAP transaction SE37.

Invoking SE37

The first step is to start the SE37 transaction. This can be done through launching the SAP GUI and connecting to the Netweaver system where your BI data resides. This should be the same Netweaver system that you specify when creating a Voyager connection.

Once the SAP GUI is up and running, SE37 can be invoked by typing SE37 into the text box as shown on the following screen shot and pressing enter.

The screen now presented should have a text box to enter the name of the BAPI function that is to be used.


To get a list of all the OLAP BAPI functions it is possible to use the star wild card so therefore type in BAPI_MDPROVIDER_* and click on the button indicated in the screen shot below.

This gives the following list.

Explanations of these functions can also be found in the Netweaver help at the following link:

A note on terminology

Users who are only familiar with Netweaver BI and the Business Explorer products can often be confused when confronted with how meta-data is mapped to a product like Voyager.


The main confusion centers around the use of the term ‘hierarchy’. In the traditional Netweaver world not every dimension/characteristic has a hierarchy defined for it. However Voyager and the OLAP BAPI, because they are influenced heavily by the ODBO model for OLAP data developed by Microsoft every dimension has at least one hierarchy defined for it. This means, for example, that if you run the OLAP BAPI function to get a list of hierarchies for a dimension that doesn’t have any hierarchies defined, you will still get back a single ‘default’ hierarchy which consists of a single ‘All’ member on level 0 and all the members from the characteristic on level 1. When the word ‘hierarchy’ is used in the remainder of this article it will refer to the a hierarchy as considered by the OLAP BAPI/ODBO rather than the classic Netweaver understanding.


If the term ‘cube’ is said to someone familiar with Netweaver this usually refers to the InfoCube. When the term is used within Voyager or in the context of the OLAP BAPI interface it not only refers to the InfoCube but also to a query that was created with the BEx Query Designer. When the term is used in the remainder of this document it will use the Voyager/OLAP BAPI definition.

More information on the mapping between Netweaver meta-data and the OLAP BAPI/ODBO world can be found at the following link:

Example 1: Getting a list of hierarchies

The following is an example of getting a list of hierarchies in for a particular cube.

The function used to get a list of hierarchies from the OLAP BAPI is BAPI_MDPROVIDER_GET_HIERARCHYS (notice the incorrect spelling of ‘HIERARCHYS’). This can be invoked in SE37 by typing the function name in and choosing the execute option (highlighted on the following screen shot).

The next screen will require the entry of some parameters to specify which hierarchies should be lists. The following screen shot shows an example.

Here the catalogue name and cube name have been specified. Running the function with these parameters will return all the hierarchies for the cube Z_BOBJ/QRY_MULTI_HIERARCHY.

To execute the function the button indicated on the above screen shot is pressed. The number of results returned is then indicated slightly further down the screen as indicated on the following screen shot.

To view the hierarchies the grey and blue icon next to the number of results needs to be clicked as indicated by the red arrow above. The results then look as follows.

Scrolling to the right reveals more interesting information such as the hierarchy’s caption in the HRY_CAP column and the hierarchies cardinality, i.e. the number of members on the hierarchy, in the HRY_CARDINALITY column. The following screen shot shows an example.

Now this can be verified against what Voyager is displaying. Here is a screen shot from Voyager.

Example 2: Getting a list of levels for a particular hierarchy

This second example gets the meta-data for the levels of a particular hierarchy.

The function to execute to get a list of levels is called BAPI_MDPROVIDER_GET_LEVELS. In this example a particular hierarchy is specified so only levels from that particular hierarchy will be returned.

The following screen shot shows some of the results returned including the level’s caption and cardinality.

Example 3: checking the number of members

The observant will have spotted that the Country hierarchy reportedly had a cardinality of 73. However the two levels that make up the Country hierarchy also reportedly have cardinalities of 73. This information is clearly not consistent as if both the levels on the Country hierarchy have 73 members then the entire hierarchy would have 73 + 73 = 146 members.

There is a way to check how many members are on the hierarchy by executing the BAPI_MDPROVIDER_GET_MEMBERS function. For example the following screen shot shows the function configured to get all member for the Country hierarchy.

The number of members can quickly be verified by looking at the numbers of entries returned. For example, the below screen shot demonstrates that there are indeed 73 members on this hierarchy.

Having a look at the members that this function has returned can also give some interesting information. For example the screen shot below shows the first few member’s captions and the number of children.

Notice that the first member ‘All Country’ claims to have 73 children, though there was a total of 73 members on the hierarchy.

It’s possible to explicitly check how many children this member has. The following screen shot shows the parameters needed to retrieve just this members children and the results.

In order to get the children of the member, the members unique name has been specified and the value of TREEOP that corresponds to ‘get children’. Notice that the check box by ‘Uppercase/Lowercase’ has to be ticked to allow the entry of lower case ‘l’s in the word ‘All’ and the value for TREEOP must be two characters. For information on other possible values for TREEOP see the following link:

Most importantly the number of members returned is 72 meaning that this member has 72 children, not 73 as claimed.


Voyager makes use of the cardinality and child member counts to know the size of such things as levels and hierarchies. It is much faster for large hierarchies to read the cardinality or child number rather than execute a calls to the BAPI_MDPROVIDER_GET_MEMBERS function. However these numbers are often inaccurate as in the examples above, but the majority of the time they are inaccurate in a consistent and predictable way so Voyager knows how to compensate. Occasionally the numbers can be inaccurate in an unpredictable way and this can cause Voyager to throw an error “java.lang.IlligalStateException: Failed to estimate the member count of member results set”.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.