New ABAP Debugger: Tips and Tricks

New ABAP Debugger : Tips and Tricks

New ABAP Debugger was 1st  released by SAP with Net Weaver04. Asof release Net Weaver 7.0 it fully replaced in the scope of it's functionality the 'old-fashioned' classic ABAP Debugger. So during the last SAP Tech Eds we learned that more & more people use the New ABAP Debugger [that is a great news] but still many are not aware of some of it's useful feature. Main purpose of this blog is to point you to these features so that you can make the most of the New ABAP Debugger.

Some useful debugger settings -

New ABAP Debugger settings dialog lets you activate special debugging modes & comfort options that can speed up our troubleshooting scenarios. Here we will find some helpful debugger settings with instructions on when & how to use them. We can access debugger settings in the debugger by using Settings -> Display / Change Debugger Settings - 

• 1.System Debugging : if we have problems that involve system programs [such as a function that can not be accessed in the debugger], turn on this setting [or use menu ' Settings -> Systems debugging on / Off ' orr the command /hs in the debugger command field]. We can declare a program as a system program by setting Status to 'System Program' in it's attributes in the SAP ABAP Editor [SE38] [check the radio button Attributes and press Change button].

• 2.Update Debugging : Let's turn on this settings if we need to analyze asynchronous updates, which are functions that are called as follows - CALL FUNCTION ‘…’ IN UPDATE TASK. So these functions are executed asynchronously in a special update work process [after the next COMMIT WORK statement]. The debugger can not follow them since it is attached to a single process. Also set a breakpoint in the function that is called IN UPDATE TASK, start debugging, turn on this settings & the debugger will reach the breakpoint in your update function.

• 3.TRFC [In Background Task] : Block Sending : Let's turn on this setting if we need to analyze transactional Remote Function Calls (TRFC), which are called as follows : CALL FUNCTION ‘…’ IN BACKGROUND TASK. So these functions are called asynchronously, along with other TRFC functions of this logical unit of work (LUW), after the next COMMIT WORK statements. The debugger can not follow them since it is attached to a single process. When we turn on this settings, these TRFC functions are stored in the system for debugging instead of being sent. lets use the TRFC Monitor [transaction SM58] to analyze the unprocessed LUWs and select Edit->Debug LUW to debug them.

• 4.Close debugger After ‘Continue’ [F8] and Roll Area End : Usually after we press Continue [F8] in the debugger session, the debugger session remains available but inactive when the program is finished. If you switch on this settings , then the debugger will be closed automatically after pressing Continue [F8], when the roll area [internal session] is ended.

• 5.Always Create Exception Obj : let's turn on this settings, if we need to analyze exception objects [if we catch ABAP exceptions in your program via the CATCH CX_MY_EXCEPTION with out specifying  reference variables to which the exception objects can be assigned]. We can then examine the created exception objects in the debugger via Display Exception Obj. magnifier button.

A).How to handover a debugger problem – Use Debugger Variants - 

Imagine that we have had to reproduce & troubleshoot a problem in a rather complicated environment. We have finally found the function module which does not work properly under certain conditions. We may need to hand over this debugging sessions for further analysis to a colleague who has expert knowledge of this function module(FM).

So in order to ensure that our colleague can reproduce the problem, we must create a very detailed description : the source lines at which to set breakpoints, the debugger settings that must be active & so on. This is time consuming & there is still a chance that you might forget critical information. In such situation, use a debugger variant [menu Debugger -> Debugger Session -> Save] to store our debugger session. We can choose which parts to store : current layout [customized desktops] debugger settings, options & breakpoints. Then we can save the variants either in the database or in a local file & send it per email to our colleagues.

Afterward our colleagues can load the saved variants from a file or the database after starting a debugging session [menu Debugger -> Debugger Session -> Load]. All settings & breakpoints will become active immediately. Yes of course he can choose which components of the variant to load : layout, settings, options, breakpoints or all of them.

B).How to display all loaded programs & global variables - Use the Loaded Program Tools :

A double click on the variables name in the source code leads to the Variable Fast Display tool where we get information about variables : type, value, etc.., On the Locals tab we get all parameters [including parameter kind] & local variables of the current function module[FM], on the Globals tab, we can display all global variables of the current program. But sometimes this local & global information is not enough ; we maybe need to display all currently loaded programs & their global variables as well. So for this purpose, use the Loaded Programs Tool [button New Tool, Special Tools -> Loaded Programs].

Loaded Programs shows us two tabs. One on the Loaded Programs tab we see the attributes of all loaded programs & their program groups. One on the Global Data tab you get global variables of each global program just by double clicking the program in the navigation tree.

C).How to test a function module in the debugger and pass parameters :

Imagine we want to test a function module in the test framework of the Function Builder [transaction SE37] in the debugger & we need to pass as a parameter a big internal table with many entries. It would be very time consuming to enter the input data for such a table manually in tcode SE37. We do not have to do this. If we access the function module(FM) from the debugger, then we can download its parameters to the SE37 test framework. Select the parameter & use the right mouse button context menu Save Parameters as Test Data [SE37]. Please consider that this download is restricted to the data types which are allowed in the SE37 test framework : we can't download objects, nested internal tables or data references. After that just open the function module in a separate SE37 window & run it in the test framework. We can access our downloaded data in SE37 via Test Data Directory button.

D).Helpful hints for analyzing variables:

• 1.Use the Data Explorer to view deep nested objects With the Objects Tool [Objects desktop] we can examine object properties including visibility, inheritance, references to the object [where-used list]. we can double click on attributes in order to navigate to the sub-components of a class. But if we have to analyze deep nested objects, then the Data Explorer Tool is the better choice. The Data Explorer lets we drill down into nested objects, structures & references without losing context of the upper levels.
• 2.Use Text Translation to display large hex strings & the XML Browser to display XML data. This is very time consuming to analyze the content of a variable that contains 2000 bytes of hex code. Therefore the detail view [detail Display desktop] for simple types & strings allows we to translate hex strings into readable text using the appropriate code page [field View , choose Text Translation].So for binary XML data, there is the XML viewer [field View , choose XML Browser].

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

Imagine our program is running in an endless loop & you need to analyze it's behavior. So In such situations we can force the running programs into the debuggers simply by setting a session breakpoints in a second ABAP Editor. So In Utilities -> Settings… -> Debugging  just choose the Session breakpoint active immed. option. When we activate this options, all [running and waiting] sessions of our logon session immediately inherit all session breakpoint set in any of those session. This is recommended that we activate this option in development environment.

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

Imagine now that we have a background job that is running & running  & you want to analyze its behavior. Just use the Process Overview [transaction SM50] , select the running process & choose from the transaction menu Program->Debugging.

G).How to debug a finished or crashed background job

Imagine now that our background job finishes it's execution so quickly, that we do not have a chance to attach a debugger to it in the Process Overview [SM50], or even worse : this crashed with a dump & you need to analyze what caused the dump. Just choose our job in the Job Overview [transaction SM37] & type 'jdbg' into the command field. Then the debugger will start & you just would need to press a couple of times Return [F7] to get out of the spool functions checks & we can debug our finished or crashed background job online in dialog.

H).How to debug HTTP requests

Now a days we distributed HTTP based application [like BSP, Web Dynpro for ABAP applications] are the reality in many IT scenario . So to troubleshoot such applications we must be able to debug HTTP requests.

Lets use transaction SICF to activate the debugger for a specific web service & a specific user [menu Edit -> Debugging -> Activate Debugging ]. Please keep in mind that our web application must run on the server where we set user breakpoints and / or where we activate HTTP debugging via SICF. So please refer to SAP note 668256 for the details on HTTP debugging.

Helpful debugger ok-codes

/h To activate debugging.

/hs To activate system debugging.

/ha To skip dynpro [PAI, PBO] & directly debug ABAP code.

/hx To detach debugger.

/hmusa To create a memory snapshot [can be used in the transaction S_MEMORY_INSPECTOR for memory consumption analysis].

jdbg in SM37 To restart a finished / crashed background job for debugging.

/ron To start ABAP Runtime Analysis measurement [transaction SE30].

/roff To stop ABAP Runtime Analysis measurement [transaction SE30].