Skip to Content

Debugging Fox Formulas in BW-IP and PAK

In his blog Hans-Georg Beuter has given some details on how you can debug Fox formulas ( In this blog we would like to show you in a screen cam how the debugging works.

1st Step: Set a Break-Point in ABAP (0-26s)

The Fox debugging uses a so-called debugging script in the ABAP debugger. In order to activate it we need to stop in the ABAP debugger first. We start by setting a break-point in the ABAP coding. We open the transaction se80, navigate to the class CL_RSPLFR_CONTROLLER, and search for the method EXECUTE_SERVICE. The method calls the execution of the planning function. We set a break-point in the first line of the coding.

2nd Step: Start the Planning Function (27s-44s)

We start our planning function from a planning sequence. Thus we open the Data Warehousing Workbench (rsa1), make sure we are displaying our planning
sequences, and display the corresponding sequence. We select the Fox formula we want to debug. As we can debug Fox formulas only in ABAP execution we need to make sure the Fox formula is not executed in memory. If you are using PAK then you can switch the execution to ABAP by setting the user parameter  RSPLS_HDB_SUPPORT to HBD_OFF for the current user (see note 1637199). Another optio is to execute the planning function in trace mode as this always forces an execution ion ABAP. We choose this (more direct) option.

3rd Step: Start the Fox Debugger (45s-1:03s)

We stop at the break-point before the execution of the actual planning function and see the ABAP debugger. We change to the tab ‘Script’ and load the script ‘RSPLFC_DEBUGGING_SCRIPT_FOX’. After that we start the script.

4th Step: Step into the First Block (1:04s-1:15s)

We now can see the fox debugger. We see the fox coding and also the selection (block values) for the first data block (Remember: when a planning function is executed then the data is partitioned into smaller blocks and the actual planning logic is executed for each of these blocks. The blocking is defined by
the selection of the characteristics that are to be changed. A block contains all data within the selected data where all characteristics that are NOT to be
changed have the same value).

In order to start the debugging press ‘Start Debugging’. If you want you can set a break-point before starting the debugging.

5th Step: Debug the Function Logic (1:16s-end)

You can now use several features in the debugger. You can set break-points, move forward by a single step, or jump to the next break-point.

You can also display the current block values again, show messages, choose which (Fox) variables should be displayed, display the reference data for the current block, and toggle the display for the plan data in order to show the entire records (not just the characteristics that are to be changed).

As we step through the coding we can see the values of the variables and the plan data changing.

When we press F8 and do not have set a break-point inside the Fox coding we will jump to the next block (2:25s). By using ‘Start Debugging’ we can step into the next block or skip the block. If we want to stop the debugging you can simply use the yellow ‘log off’ button (2:40s).

You will end up in the ABAP debugger again. You can either simply continue by pressing ‘F8’ or in some cases might have to switch to the standard display, delete the break-point, and finish by pressing ‘F8’.

You must be Logged on to comment or reply to a post.
  • Question about the blocks.

    When you have a code which is not working on the current blocks, but is reading some attributes from other infoprovider and it is saving those attributes into internal table for the use in the Reference Data later.

    From my understanding that code will be run with each block which probably will not result in the best performance?

    What is usually the benefits of having blocks? Less Memory consumption? Less locks (not..)?

    If I incerase the fields to be changed in order to reduce the block to just one, does that have a performance impact? I gues there is some trade off?





      Hi Emilyan,

      Blocking is used to make the definition and the execution of a planning function more easy. Say you have an InfoCube/DSO/aDSO with a lot of characteristics and you just want to copy all data from one version to another. So you create an aggregation level containing all characteristics and a planning function that just uses ‘version’ as a characteristic to be changed. By definition the system will not touch the values of all the other characteristics and you also will only have to set up a rule (copy function, Fox, or SQL-Script) how the value of version changes. In a similar way, it is also much easier for the system to execute the planning function when it uses blocks. Also, when running on HANA the system can parallelize the execution of planning functions as the blocks are disjoint and independent from each other.

      In the end the usual recommendation is to put all characteristics you need to change in the characteristics to be changed and let the system handle the rest. And keep in mind that your coding might be executed several times (in parallel).

      Best regards, Gerd

  • Could you please also explain how the execution of Planning Sequence on saving. When  “Only Read Changed Data” is enabled, I still get all the data outside of the current form




    I am having a company code as a variable and I am trying to work on the data only on the code I currently have in the Input Query.


    EDIT: It has been answer here:






    • Hi,

      The idea was just to create an example that is easy to understand. In ‘real life’ I would rather use a revaluation function whenever possible.

      Best regards, Gerd