Debugging process chains

There are few possibilities for debugging a process chain. In case BW system is based on older versions it needs to be debugged is a background process. This can be done via capturing the background process from the chain’s job.

In case the BW system is newer the chain debugging function is available out of the box. In the process chains related t-codes (e.g. RSPC1) when the chain is in EDIT mode there is a drop down menu called “Debug Loop…”.

 

After that a popup window is displayed. In that window it is possible to enter a number of seconds that represent how long the process waits before executing the task. During this waiting time you either go to Job Overview (t-code like SM37) or the Process Overview (SM51, SM50) and capture the process from there. Or make it simpler and set the break point in your code prior to the debugging). After entering the “Debug Loop…” the chain needs to be saved and activated.

The debugging itself can be started from RSPC1’s menu Execution -> “Execute Synchronous to Debugging”.

In a nutshell:

1.    Open the PC in Edit Mode

2.    Find a process you want to debug

3.    Right click and select “Debug Loop”

4.    Set a time in seconds e.g. 5 seconds

5.    Save and activate the chain

6.    In the menu -> Execution -> Execute Synchronous to Debugging

 

More information:

Finding any process in Process Chain that deals with certain object

Reassigning of Process Chain’s InfoArea

Streaming for Process Chains

Possibilities of Process Chain monitoring

Other ways of starting Process Chains

Critical path of a process chain

Process chain where used

Dummy report for process chain decision processes

Skip Process Chain’s process – some details

Debugging End Routine in HANA runtime of BW Transformation

In BW’s Transformation that are set to be executed in HANA mode there is still possible to have an ABAP End Routine. Here’s a short guide on how to debug ABAP code in such End Routines.

Technically a place that where the ABAP code of the End Routine is embedded into overall code of the HAAP process is a generated ABAP class. As an example if HAAP name (variable I_HAAPNM) is TR_ZQPTTP4YE36NYCQEVA6P_A then the ABAP class name is /BIC/ZQPTTP4YE36NYCQEVA6P_A (variable R_CLASS_NAME). In that ABAP class there is a method called GLOBAL_END where it code is located.

There are two environments where such an End Routine can be debugged.

 

1. in SAP HANA Studio – First open the transformation and display the End Routine code. Do a right click on some executable ABAP statement and set the breakpoint via choosing "Toggle Breakpoint" context menu item. 

While being in BW Modeling perspective open respective DTP and via button on DTP’s toolbar called "Start execution of data transfer process" select "Simulate in Dialog" item. This action open an RSDTP t-code embedded in SAP HANA Studio. Here hit a Simulate button and continue as you would do the debugging in SAP GUI as described below.

2. in SAP GUI – The debugging is still possible in SAP GUI if one prefer to do so. While being in RSDTP t-code set a "Processing Mode" to "Serially in the Dialog Process (for Debugging)" position, check out "Expert Mode" checkbox and hit Simulate button.

Next, a following pop-up called "Debug Request" is shown. Here enable "Before Transformation" checkbox. After that run it.

After a while, an ABAP debugger screen of SAP GUI is presented. Follow to Break./Watchpoints tab of the ABAP Debugger. Create a new breakpoint here pointing to ABAP objects:

Class name       CL_RSDHAR_TGT

Method Name      IF_RSDHAR_TGT~EXTRACT

Once the new breakpoint is created, it is visible like below:

Run the debugger until the new breakpoint is reached. There may be few more stops caused by hardcoded BREAK-POINT ABAP statements until it is reached to. If the ABAP debugger finally stops at IF_RSDHAR_TGT~EXTRACT (CL_RSDHAR_TGT) breakpoint just scroll a little bit down to a place where a call of method o_execute_abap_endrout is located and place a another breakpoint there.

Once that new breakpoint at the call of method o_execute_abap_endrout is reached, you came into the point where the ABAP code of custom End Routine is executed.

Switching between a Standard (New) Debugger & (Old) Classic Debugger

A New ABAP Debugger was introduced in Release 6.40. Since that there was a change in its name. Thus the “NEW” name became obsolete. The New Debugger is called just Standard ABAP Debugger. Similarly, the Old ABAP Debugger is called Classic Debugger.

Normally when you start to use the debugger system jumps to the Standard ABAP Debugger right away. There is no possibility to set the Classic Debugger as default debugger in ABAP Workbench settings (t-code SE80 or SE38 -> Utilities -> Settings) anymore. Thus by default the debugger starts as a Standard one. However, if there is a necessity to use the old one it is still possible.

Once you enter the Standard Debugger via following value that is entered into t-code field (so called “ok-code”) the debugger switches to Classic one:

 

/hset debugger=classic

 

Similarly to switch to Standard one:

 

/hset debugger=standard

 

Switching the default debugger using above ok-codes is valid for the current logon session only. After the re-logging to SAP GUI it won’t be valid anymore.

How to find out code of SAP icon

Codes of SAP icons are used in ABAP report in some cases. For example of here a dynpro having some icons assigned to particular data rows in table grid there can be a logic which evaluates what is value of particular icon. In case one needs to debug it and perhaps change the icon, (means change value of the icon’s code) it is handy to know these codes. Because the icon can only be entered into debugger by providing its value.

Recently I debugged some BW’s UD Connect data source screens and I came across statement that evaluated value of the icon:

Variable icon_bw_datasource declared in Type group called ICON. In this particular type group, there are more than 1200 icons available.

The type group are available from Data Dictionary related t-codes like SE11. 

What foreign currency rate was used in BW currency conversion?

BW uses standard SAP’s ECC functionality with regards to foreign (FX) currency conversion. This means that same set of TCUR* tables are being used while the BW system is doing the conversion. This is valid while doing the FX conversion during transformation /loading of data and also while running reports.

In BW reporting a key figure in report can have Conversion Type specifies in its definition under Conversion tab in its properties. 

The Conversion Type that can be chosen here are defined in the SAP BW backend – in tcode RSCUR. Here all settings like: what and how an Exchange Rate shall be obtained; where a source and target currency shall came from; and Time Reference to which the conversion type shall be tied to are specified.

So this is all that can be setup for the FX conversion. While looking at the converted numbers in the report’s output an issue of wrong data can arise from users. Question here is basically what FX from table TCURR was used?

To find out that for starter an “Currency and Unit Conversion” debugging can be started form t-code RSRT. This is available by hitting on “Execute + Debug” button.

While debugging it can be seen that following function modules are used in following sequence:

RSW_CUR_TRANSLATION_RATE_GET   Wrapper function ->

-> RSW_CTT_GET                                  Reads currency translation type

-> RSW_SCUR_CHECK_AND_GET              Determine source currency

-> RSW_TCUR_CHECK_AND_GET              Determine target currency

-> RSW_TRANSLATION_DATE_GET  determines date used to find translation rate

-> RSW_RATE_GET_BASIC                              determine the translation rate

-> CONVERT_TO_FOREIGN_CURRENCY here function DATA_FROM_DATABASE is called which calls another function DATEN_BEREITSTELLEN and this one finally reads the FS rate from table TCURR for previously determined Currency conversion type; from/to currency, date and client of the SAP BW system.

Therefore you may want to just set a breakpoint into the FM CONVERT_TO_FOREIGN_CURRENCY to speed up debugging process.

Notice that variable DATC is nothing else just value from EXC_DATE variable converted into internal format by below ABAP statement:

CONVERT DATE exc_date INTO INVERTED-DATE datc.

This means the source variable in character format is converted into target one as complement on nine - difference to the number nine.

Needless to say that above statement is obsolete ABAP statement. It shall be replaced by using TRANSLATE statement.

More information:

Currency Translation in the Business Explorer

Selection/Formula/Cell Properties

Detecting debugger in ABAP program

With relation to my recent post “How to determine simulation mode of DTP” where I was blogging about detecting debugger within BW’s transformation’s routines I was curious how to achieve the same with classic ABAP environment. Within the BW’s transformation it was simple there is a clear variable which simple evaluation get the answer weather the transformation is running in the debugger or not.

In case of pure ABAP environment it is not that simple. There are ABAP system field like SY-DEBUG and SY-BATCH which I immediately thought of. However at least in newer versions of NetWeaver (7.x) they seems not be functioning in case of evaluating whether the ABAP program runs in the debugger or not.

As next I found FM TH_GET_DEBUG_INFO which looked from description that it does the job: get debugging info… I tried to put following code into my report:

DATA: lv_dbg_cnt TYPE i.

 CALL FUNCTION 'TH_GET_DEBUG_INFO'

  IMPORTING

DEBUGGING_COUNT= lv_dbg_cnt.

IF  lv_dbg_cnt EQ 2.

   write: / 'dbg is ON'.

 ENDIF.

  IF  lv_dbg_cnt EQ 1.

   write: / 'dbg is OFF'.

 ENDIF.

However this didn’t work out either.

As third thing I found FM SYSTEM_DEBUG_BREAKPOINTS. This FM calls C function called 'DEBUG_CNTL' which finally does the job. Actually the breakpoints seem to be stored somewhere within app server memory and the C function provides them. The above mentioned FM needs to be called up with input parameter MAIN_PROGRAM which’s values is the program that we want to evaluate whether it run in debugger.

Down below is simple call of the FM. In case TABLE parameter’s BREAKPOINTS has at least one row then the debugger is set in source code if input’s parameter MAIN_PROGRAM.

This solution will work in cases someone puts breakpoints manually in source code. Therefore I think it should cover all switches to debugger in case the breakpoints are set. However it won’t cover the case if someone just hits /h and continues to debug the code.

REPORT  ZMM_TEST.

DATA: lt_breakpoints TYPE TABLE OF breakpoint.

CALL FUNCTION 'SYSTEM_DEBUG_BREAKPOINTS'

 EXPORTING

   main_program                = 'ZMM_TEST'

 TABLES

   breakpoints                 = lt_breakpoints.

How to determine simulation mode of DTP

Simulation mode of DTP is quite useful function of BW. When there are some issues with the data in target of transformation we can use it to see how actually the data was transformed. In particular we can see in the debugger what is going on with the data within the transformation.

For debugging of the DTP we use Simulation of the DTP.  While using system basically jumps into debugger. For details how to use it see this wiki or online documentation.

While the DTP is running in Simulation mode no data is uploaded into the data target. This basically means that no data is changed. Sometimes there is ABAP code within the transformation where we manipulate further data e.g. in custom tables. Of course running in the Simulation mode we want to avoid manipulating the data in custom tables. As these are the custom tables by SAP standard it is not guaranteed that data is not saved as it is not saved into the BW data targets. So it is up the BW developer to ensure that no data is changed in in custom tables.

To implement it we can leverage the attributes of Simulation mode of the transformation – means Simulation of the DTP. In custom coding we can easily identify heather the DTP is running in the simulation mode. The attribute of simulation DTP carries value "DTPR_SIMULATION" in the request. Here’s example ABAP coding:

    IF request NE 'DTPR_SIMULATION'.

      MODIFY dbtab …

    ENDIF.

This fragment of code can be used in any of start/end/expert routines.

Can’t set more than 30 breakpoints

Sometimes it is very easy to set many breakpoints while digging into SAP system. Very common case for that is to set a breakpoint into every statement like MESSAGE. Then in case one still needs more breakpoints following messages pops-up:

Can’t set more than 30 breakpoints

Message No. SY407

It is a matter of fact that there is this hard limit on number of breakpoints = 30 per one login into the system. It is not possible to set more breakpoints than that. The breakpoints (session breakpoints) are managed by C function DEBUG_CNTL so it is not possible to tell where the list of the breakpoints already set are stored. Only in case of external breakpoints it is possible to determine no of these. They are stored in table ABDBG_BPS.

Now how to easily get rid of all the breakpoints currently set in the system? Deactivating and also removing the breakpoints can be achieved in following ways:

1. In ABAP Workbench (tcode SE38): while in source code, see menu:

Utilities -> Breakpoints -> Delete

Utilities -> External Breakpoints -> Delete

2. In ABAP Debugger, menu: Breakpoints -> Delete all BPs or Deactivate all BPs

3. tcode RSBREAKPOINTS -> Delete Breakpoints

More information on breakpoints topic:

Remote ABAP Debugging and more (btw: this blog was written almost exactly 6 years back from writing this blog J )

ABAP Debugger

ABAP Debugger

It is needless to say how debuggers are important to programmers. Code would never be working without having debugger tools in any of programming language. So it is in ABAP.

Basically at present stage we have 2 debuggers:

• Classic ABAP Debugger
• New ABAP Debugger

Classic one was here from early age of R/3. It is known for its flat structure, not offering very comprehensive view on what is going on in program execution. Although all basic features one would require from any debugger tool are there: you can create your own breakpoints, watch points, display content of any of variables, change the variables, process data within internal table, do the jumps in the code, etc. At present old debugger is still available in all SAP solutions based on SAP Basis Component <= 4.6. For online documentation refer to help.sap.com site.

New debugger came within SAP NetWeaver 04 as part of Application Server around of year 2006. The big differences to old one is that new one is executed in separate own mode. This consumes another dialog session of user. This is known as 2 process architecture. You have still possibility to switch between old-new one on the fly while debugging. UI is completely different in fancy tabs fashion. The UI is completely configurable. Basically you can setup your own look and feel while placing different tools/tabs around the screen.

New New ABAP Debugger features:

External debugging – HTTP and RFC debugging support with regards to integration of JAVA Stack to NetWeaver

Layer Aware debugging - profile-controlled debugging, enables to debug only relevant fragment of code (not relevant parts of code (e.g. system framework) are hidden during the walk through the code) or debug in big steps (instead of single-stepping going one statement by other enables to jump from layer to layer or component to component). Both improvements saves a lot of debugging time.

Debugger scripting – to automate manual inputs during the debugging e.g. in case of monotonous actions. Debugger script helps to automate programmer interaction. You can create your own script to execute many lines of code or change the variables value. Scripting is available via Script Editor.

New Break points – e.g. at Web Dynpro, ST template. Methods, subroutines, exceptions, etc. were introduced.

For your reference see documentation at help.sap.com site.

SDN’s link related to ABAP Debugger:

ABAP Debugger Wiki

New ABAP Debugger Wiki

New ABAP Debugger – Tips and Tricks

ABAP Debugger Scripting

Layer-Aware Debugging

Very useful blogs from Olga Dolinskaja from SAP AG who’s dedicates a lot to ABAP debugger:

Some useful debugger settings

How to handover a debugger problem - Use Debugger Variants

How to display all loaded programs and global variables - Use the Loaded Programs Tool

How to test a function module in the debugger and pass parameters

Helpful hints for analyzing variables

How to debug a program which is running in an endless loop

How to debug a background job which is running in an endless loop

How to debug a finished or crashed background job

How to compare ABAP variables - Use the Diff Tool

How to debug HTTP requests

Helpful debugger ok-codes

Other posts on ABAP debugger topic:

Remote ABAP Debugging and more

Starting up ABAP debugger

SAP system behavior while debugging

Endless loops in ABAP

Debugging of BW IP's planning functions

Debugging of BEx's text variables

Endless loops in ABAP

I haven't updated my blog for quite long time. This is mostly because I’m currently involved in project which requires me to travel a lot. Therefore today here comes again only very short tip. To be more precise the tip will be how to code so called endless loops in ABAP. 

First let me explain what it is endless loop. It is a part of code which is being constantly executed over and over again until certain condition (there can be terminating condition or condition that is never met) is not fulfilled or loop is terminated by user. In other words we call the endless loop as infinite loop or unproductive loop.

Secondly let me explain why we (from time to time) need that. There might be situation that you need to check or monitor behavior of system while runtime of your program. Someone might say that for this I could set a breakpoint and achieve the same. Yes that would be possible but imagine you run your program as a job and within distributed SAP environment comprised from several application servers. In such a scenario you cannot be sure by which server your program will be executed. Therefore you let your program run in endless look.  Afterwards you observe on which server it runs and you switch into its runtime from e.g. TA SM50 via Debugging functionality (process, menu Program-> Debug program).  Actually in this case loop gives you a time to prepare TA50 and get into the processing of program as well.

In case of BW there are certain situations where infinite loops are handy as well. As all BW processing usually takes place on background (e.g. extraction: DTP, InfoPackages, Process Chains or BEx reporting variables programming) endless loops are needed here as well. I’m pretty sure you can figure out our examples.

Here’s one example of the endless loop:

data: debug(1).

do.

if debug = 'X'.

exit.

endif.

enddo.

If you are done with program’s environment monitoring you can easily escape this loop by manipulating with value of variable debug setting it to ’X’.

See blog on similar ABAP topic: If 1 equals 2, what’s the purpose?

Remote ABAP Debugging and more

You have possibility to set User Breakpoint (formerly External Breakpoints) in ABAP backend to get into debugging mode while you invoking this code outside (e.g. via RFC or HTTP requests) of ABAP backend. Such a breakpoint is set on application server on which are you currently logged in. You will not get into debugger if your request is send to other application server in which you haven’t set break points. To obey this behavior SAP is providing transaction SRDEBUG where you can activate your User Breakpoint in all applications servers.



There is one more useful transaction called RSBREAKPOINTS via which you can manage your breakpoints. Basically this TA deals with tables: ABDBG_BPS (ABAP Debugger: Breakpoints), ABDBG_INFO (ABAP Debugger: Information on Breakpoints) and ICFATTRIB (Description of ICF Attributes (Trace/Debugging)).



Other posts with debugging topic:
• SAP system behavior while debugging
• Starting up ABAP debugger

Debugging of BW IP’s planning functions

Such a debugging of Integrated Planning’s planning function can be invoked by classic ABAP statement BREAK-POINT. You can easily put it into your ABAP formula of your planning function. 

 

Such a debugging is based on classical external debugging which can be switched on TA SE38.

 

Here’s how your break point looks like in generated ABAP code behind your planning function:

Some other SAP specialties concerning debugging can be found here.

SAP system behavior while debugging

In one of my previous posts I stated several possibilities how to start ABAP debugger tool. Here comes some debugging specialties discussed.

Debugging is often activity of skilled users or key users and I don’t know a lot of consultants who can avoid usage of debugging as well. Several possibilities are in place: remote debugging; tRFC/ /qRFC/bgRFC debugging; HTTP/external debugging etc. Normally we debug while logged in SAP GUI in SAP system. Basically you can switch processing of any transaction or report to debug mode via entering /h code to transaction field of SAP GUI. There are some other possibilities how to enter debug mode for e.g. job – this is possible via TA SM37 -> menu Job -> “Capture: active job” etc. SAP system based on NetWeaver ABAP stack application server has special functionality dedicated to debugging. A work process which is processing your task is set into a DEBUG mode. Debugging in general does requesting a huge memory consumption and system resources as well. This means that system is moving data to its extended memory in PRIV mode. In this mode normal request being processed by other work processes are located in local memory instead of extended. Extended memory is occupied by data for debugging user exclusively. However this cannot persist in system for a long time. So since you are not active in debugging session for some time system is canceling whole debugging with following messages:

Transaction from "PRIV" session reset after timeout (Message no. 14048)

Transaction from "DEBUG" mode (after timeout) reset (Message no. 14056)

From basis point of view for production system there should not be a necessity to adjust profile parameters in order to allow debugging for a long time and for a so much users. If you wish to avoid this message anyway or you want to make debugging more comfortable on development or test system you need to consider following profile parameters:

• rdisp/max_priv_time # Standard value: 600
• rdisp/wppriv_max_no # Standard value: MAX(1, Anzahl Dialog-WPs)
• rdisp/max_debug_lazy_time # Standard value: 600

Other very common obstacle is that there is not debugging possible at the moment; you can experience it while a system is issuing message like:

You cannot debug ABAP programs at this time

While there are a few more users doing debugging in system other than you; you can experience following message:

Max. number of debugging mode users reached (Message no. 14111)

In this case you need to check out entry in table T000-CCATEGORY. This field is describing a role of client that you are logged in. If there is a value of P it is a production system/client. In such a clients number of work processes that can change to debug mode is limited to half of the DIALOG processes in system. Therefore setup number of dialog processes accordingly.

If system is running out of memory and it cannot allocate enough memory for data processes in your transaction you may get message like:

Memory low. Leave the transaction before taking a break!

From user’s point of view you really need to at least restart transaction or better to log off and on to system. Basis team would need to re-setup a dialog timeout and/or work process timeout of profile parameters, memory parameters, increase physical of machine, etc.

BTW: Notice that ABAP debugger is completely written in C programming language and not in ABAP. On other world of JAVA stack – in NetWeaver Developer Studio debugging is completely different but this is another story…