How to sort out many RKF/CKF created on top of infoprov?

Global calculated or restricted key figures (CKF/RKF) created on top of infoprovider are a very common things developed in BW systems. Using global objects like this enables sharing the objects between different queries leveraging their functionality. Normally the SAP BW developers use them very often. They can be accessible from BEx Query Designer (QD) on left panel where other global objects like structures are visible.

Problem becomes when there are too many objects. It can be very difficult to navigate within the KFs in case there are hundreds or thousands (yes I’ve seen that too) of them. To solve this SAP is providing functionality where the RKF/CKF can be categorized within the hierarchy. The function is available in tcode RSZTREE (ABAP report RSZ_COMPONENT_TREE). It enables hierarchical display of the KFs. The KFs can be grouped into nodes of the hierarchy. The final structure can be also then visible in the BEx QD so it is available to developer while dealing with the BEx queries.

The hierarchy can be created and maintained with the tcode mentioned. The hierarchy of the RKF/CKF can be transported together with inforprovider involved. Tables where the hierarchy data is stored are RSZCOMPTREE and RSZCOMPTREETXT.

The tcode is available as of SAP NetWeaver BW 7.30 SP08.

More information:

1648317 - Hierarchical display of RKF/CKF in Query Designer

Hierarchical display of calculated and restricted KF in BEx QD

AfO: Texts of BW query not displayed is proper language

Some users of Analysis for MS Excel (AfO) can experience following situation. Texts of BW query like columns/rows names are just showing some technical names (sometimes in German) and not texts that are supposed to be shown in there. The strange texts can appear also in Display panel.

Issue is occurring because different logon language was used for the AfO logon. For example it can be a language of OS – Windows. This happens for users who’s Windows language is different from the languages that are installed in particular BW backend system on which they run the BW’s BEx queries. Also in case there is a Single Sign On in place and users are going directly to system w/o providing credentials they can’t really chose logon language.

Solution here is to activate option to enter the logon language. This can be achieved in AfO’s settings. Under Advanced settings tab there is an option to force a pop-up screen for use to choose the logon language upon logon. In the same logon pop-up, user can change the client.

Transformation code in INCLUDE: how to perform where-used?

Here let’s have following scenario. ABAP logic for Transformation (TRFN) is encapsulated in ABAP INCLUDE and it needs to be changed. Before a change is done it is beneficial to check what are all TRFN where the ABAP include is used. In case there are several TRFN and change is not supposed to be done for all of them an issues can came.

Normally as the INCLUDE it would be regular ABAP one there is a Where-Used functionality available in t-code like SE38/SE80. However it doesn’t work as the code of TFRN is stored in generated report (GP*).

What actually works in case of the GP* reports is Syntax Check functionality available as well as in the SE38/SE80. Via the Check the list of the all TRFN is available.

APD: all Key figures equal zero after ABAP routine

Working with APD process with ABAP routine I noticed that all key figures were equal to zero. The APD in question had regular BEx query as data source. After then an ABAP routine followed. Code in the routine wasn’t manipulating the key figures. Therefore it was a strange to me why the key figures were all equal to zero.

Currency or unit fields are not a standalone fields as they depend on a value field.  So if just a key figure is mapped in the ABAP routine it won’t transfer real numbers so they all appear as zero. Therefore the key figures associated with the currencies or/and units have to be assigned into field list on “Source Flds” tab in the APD process’s ABAP routine.

BEx Query Designer, query filter: Characteristics Restriction vs Default Values

In the BEx Query Designer there are two areas where characteristics can be restricted (filtered). What are differences between them?

As example this is simple BEx query having characteristics called “BI Appl. Obj. Type” placed at Filter->“Characteristic restriction” area and “InfoProvider Type” at “Default Values” area.

If a characteristic restricted in the “Default Values” area -> users can override the variable value or values at runtime. In the query runtime more values can be pulled into the restriction.

In case the characteristic restricted in “Characteristic restriction” area -> in the query runtime only values which were placed to the filter during query design time can be further restricted but no new values can be added.

Update 20-SEP-2021:

As reporting part of BW moved over the years to Analysis for Office, the pictures in this post became obsolete. Thus, I place new ones here about how the in the Analysis for Office we can remove values from “Default Values” filter. As well as how to setup default values filter in SAP Studio BW Query.

Here’s BW Query in SAP Studio:

Here’s Analysis for Office:  

Seldom BEx query error “NODE_TO_NODEDR - (AXI) redesign query” while running in APD process

I encounter following error in my BEx query that didn’t run in APD. In my case it is very seldom error I didn’t experienced it very often. Basically the query doesn’t run and it produces following errors.

System error in program CL_RSDRC_SELDR_SRVS and form NODE_TO_NODEDR-01-            Message No. BRAIN299

This internal error is a targeted termination since the program has an incorrect status.

Error while getting data (AXI); redesign query               Message No. RSCRM027

The scenario in my case was that the query was part of APD process. When I ran the query standalone it worked just fine. Initially I assumed that it is caused by huge query output. However while disobeying limits on query result set it worked well in t-code RSRT. So it wasn’t about the large data set. There are few SAP Notes (2432897, 2098434, 2265753, 2146267 or 1505587) related to error but in my system based on BW 74 SP09 it turned out that all were already implemented. After more digging into SAP ONE Support Site I found a Note: 2265753 - MDX statement terminates with system error in program CL_RSDRC_SELDR_SRVS and form NODE_TO_NODEDR-01- which turned out to be the one that solved this situation. From the Note description it seems that the issue is related to calculation of members member used in the where-clause (slicer).