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 (http://scn.sap.com/community/data-warehousing/business-planning/blog/2014/09/08/debugging-a-planning-function-of-type-formula-in-bw-ip). 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’.
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?
Thanks,
Emiliyan
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
Thanks 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
XT_REF_DATA
XT_DATA_TAB
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:
https://archive.sap.com/discussions/thread/3869343
Can you explain the revaluation using fox formula without using revaluation planning function?
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
Helpful - Awesome !! 🙂
Hello Gerd,
I followed every step as described, but the debugging script was not opened. Any ideas would be appreciated.
Thanks a lot, Christoph
Hi Christoph,
There's an OSS Note related with that issue as 2852931 - RSPLFC_DEBUGGING_SCRIPT_FOX script doesn't stop in debug
https://launchpad.support.sap.com/#/notes/2852931
workaround: add break-points on the first row of these methods:
Class CL_RSPLFR_CONTROLLER, method EXECUTE_SERVICE ()
Class CL_RSPLFC_FORMULA, method IF_RSPLFA_SRVTYPE_IMP_EXEC_REF~EXECUTE ()
Thanks,
Mustafa
That works, Thanks Mustafa
Hello,
Between STEP #3 and STEP# 4, if the Fox debugger is not working. please add a break point in
Class CL_RSPLFC_FORMULA, method IF_RSPLFA_SRVTYPE_IMP_EXEC_REF~EXECUTE ()
Regards
Don
Hello Gerd,
Recently I wrote AMDP planning code and smehow the TREX debugging not working at all while Tracing.
METHOD if_rsplfa_srvtype_trex_exec_r~trex_execute.
DATA: l_r_sql_script TYPE REF TO if_rspls_sql_script,
l_procedure_name TYPE string,
l_t_iobj_param TYPE if_rsr_pe_adapter=>tn_t_iobj_param.
l_r_sql_script = cl_rspls_session_store_manager=>get_sql_script_instance( i_r_store = i_r_store ).
l_r_sql_script->get_parameter_values(
EXPORTING
i_r_param_set = i_r_param_set
i_para_name_for_procedure = 'CALC'
IMPORTING
e_procedure_name = l_procedure_name
e_t_iobj_param = l_t_iobj_param ).
l_procedure_name = 'ZCL_ABDP_0001=>CALC'.
r_s_view-view = l_r_sql_script->execute_sql_script(
i_view = i_view
i_view_ref = i_view_ref
i_t_iobj_param = l_t_iobj_param
i_proc_name = l_procedure_name
i_sql_script_returns_ai = abap_true
i_r_msg = i_r_msg ).
ENDMETHOD.
Am i missing something overhere while debugging? Should I pass values to i_view_ref?
Many thanks in advance.
G