Debugging Overview Education

Session
A hands on experience…
Course Overview
 4 Sessions
 Debugging overview
 Commands and Tools
 Watchpoints and Variables
 Tips and Tricks
 Each session is followed by an exercise!!!
 PAY ATTENTION….

= Pay Attention and Listen!!!!

= Time to do it yourself!!!
Session 1 - Overview
 In this session you will learn to:
 Launch the debugger
 Switch between the debuggers
 Set a break-point
 Session
 User
New / Classic Debugger
 Classic ABAP Debugger  New ABAP Debugger
 Runs in the same roll area as the  Executed in a separate external
application to be analyzed session (Debugger), while the
(debuggee). It is therefore application to be analyzed
displayed in the same window as (debuggee) uses a second external
the application. session.
 However, this technology also has  With this technology, the user
some restrictions. interface of the Debugger can be
 Can debug conversion exist designed freely by ABAP means.
 No ABAP technology can be used
for designing the Debugger
interface and it is therefore not
possible to create a modern user
interface.
Break points
 Breakpoints can be created using
the following mechanisms:
 ABAP Commands
 SELECT
 MESSAGE
 …
 Method
 Class -> Method
 Function Module
 Form
 Program -> Form
 Exceptions
 Class exception
 Source code
 Program -> Include -> Row number
Firing off a break-point
Title Info – Session / Exclusive
 Exclusive
 Exclusively occupies a work
process during debugging
 Non-Exclusive
 Roll-out enforced after each
debugger view => Commit
work
 Limited functionality
 Select – Endselect
 Conversion / field exits
 Inconsistent data
 Not available in Prod
Break-point – Session, User
 Dynamic break-points are set by
double clicking a line in the
ABAP editor (Session Break-
point)
 User specific
 Removed when logged off
 User break-points (previously
known as External or Static
break-points)
 Need to use this type of break-point
to debug BSP or Web Dynpro
applications
 Valid for all logons to the server by
the executing users
Session 1 - Exercise
 Setting break-points
 Transaction ZEM1 (ELD 110)
 Sold to Customer = 300
 Order Creation Date = 12/4/2011
-> 01/03/2012
 Check if debugger session is exclusive
or non-exclusive
 Switch between new and old debugger
and vice versa
 Create a session break-point at the
subroutine SELECT_DATA of program
ZEM_OTC_ORDERSTATUS
 Create a user break-point at the CALL
SCREEN 2000 command of program
ZEM_OTC_ORDERSTATUS
 Create a normal break-point at line 70
of program
ZEM_OTC_ORDERSTATUS
Session 2 – Commands and Tools
 In this session you will learn to:
 Understand the debugging commands and tools
 Skip iterations in a debug session
Understanding the Debugging Screen
 Title Info  System Variables
 Flow Control  Tools
 Program info  Tabs
Flow Control

 Single step - Execute the program statement by statement. This allows you to branch to other
program units (Detailed debugging to view all variables)
 Execute - Process a program line by line. All of the statements on the current line are
processed in a single step (Skip the line because you know it’s not an issue)
 Return - Returns to the point at which control is passed back to the main program. Use this
option to return from other program units. (Once you’ve single stepped in to code and then
you realize this code is not at fault and you want to get out and continue from the calling
program)
 Continue - Process the program up to the next breakpoint. If there are no more breakpoints
in the program, the system exits debugging mode and executes the rest of the program
normally (Continue on to the next break point or let the program commit to the database)
Debugger Tools
 4 Tools on 1 page
 Different views
 Desktop 1
 Initial analysis
 Standard tabs
 Detailed technical analysis
 Break/Watchpoints
 Navigate through the issue
Debugger Tools
 Source code
 Call stack
 Variables
 Breakpoints / Watchpoints
 Table
 Structure
 Data explorer
 Loaded Programs (Global Data)
 Current session
 Memory Analysis
 DiffTool –Variable / Structure
comparisons
 System Areas
Desktop 1

 Double click variables / internal tables to bring them in to the

variables area
 Double click internal table to view internal table contents
 Double click the value in the “Line” column to see the data of an
internal table as a structure
Data Explorer Tab

 Shows data in tree display

 Great for nested / complex structures
Skipping iterations in a loop

 You can skip the execution of a number of the same breakpoint by

entering a number in the Skip column as shown below. The first session
break-point will be skipped 10 times before ultimately stopping. This is
particularly useful if you are running through a large internal table and
want to get to a particular entry. Just skip n rows to get you close to
where your issue is and single step from there.
Session 2 – Exercise (Debugging tools)
 Report
 Transaction ZEM1
 Sold to Customer = 300
 Order Creation Date = 12/4/2011 -> 01/03/2012
 Create a normal break-point at the subroutine SELECT_DATA of program
ZEM_OTC_ORDERSTATUS
 Single step in to the sub-routine
 Continue to execute function /SAPTRX/BAPI_EH_GET_DATA_GEN. Review the contents
returned in row 5 of internal table lt_eventhandlerheaders
 Save the internal table data to a spreadsheet
 Change row content
 Add a row, delete a row
 Add the tool – Call Stack and check the call stack sequence. Close the tool
 On line 361 skip the loop until the 20th record is found. i.e. Stop at line 363 for the 20th record
(TRACKINGID = 0300041823000020)
 Exit out of the sub-routine once the 20th record is reviewed, but stay in the debug mode!!!
Execute line 68 (CALL SCREEN 2000) and return to the debugger
 Continue to exit the debugger
Session 3
 In this session you will learn to:
 Use watchpoints
 Discover how to get to program info and system variables
Watchpoints

 Watchpoints allow you the option of monitoring the content of individual variables. The Debugger stops as soon as the
value of the monitored variable changes. In addition, conditions can be specified. The Debugger also checks whether such a
condition is fulfilled.
E.g. Conditions:
 sy-index > 5
 sy-index = sy-tabix
 lines( itab ) > 0
 lines( itab ) <> sy-tabix
 lines( itab ) < lines( itab2 )
 strlen( s ) >= sy-index
 Watch performance
 Increased memory consumption
 Only valid in current roll area
Program Info and System Variables

 Display Source code of program

 Display Source code of sub-routine
 Display program attributes
 Display system variables (See next slide) – Can insert own
 Return code (SY-SUBRC)
 Table Index (SY-TABIX)
Key System Variables
 Structure – SYST
 UZEIT – System time
 DATUM – System Date
 UNAME – Current user
 INDEX – Current database pointer
 TABIX – Current internal table pointer
 SUBRC – Return Code
 BATCH – Batch mode?
 BINPT – BDC session
 DYNNR – Current screen
 SYSID – Current SID
 UCOMM – Current OK Code
 SUBTY – Background processing?
 DATLO, TIMLO, ZONLO – Current user
date, time and timezone
Session 3 – Exercise (Watchpoints)
 Report
 Transaction ZEM1
 Sold to Customer = 300
 Order Creation Date = 12/4/2011 -> 01/03/2012
 Create a normal break-point at the subroutine SELECT_DATA of
program ZEM_OTC_ORDERSTATUS. Step in to the sub-routine
 Automatically stop the code when the internal table
lt_headerextension has had a value entered in to it
 Run it again but now add the condition to only stop if the table
lt_headerextension has at least 30 rows in it
 Run once more but now check for 300 rows in table
lt_headerextension
Session 3 – Exercise (Watchpoints)
 Hints
Session 3 – Exercise (Variables)
 Report
 Transaction ZEM1
 Sold to Customer = 300
 Order Creation Date = 12/4/2011 -> 01/03/2012
 Create a normal break-point at the subroutine SELECT_DATA of program
ZEM_OTC_ORDERSTATUS. Step in to the sub-routine
 Set a break-point at the LOOP command on line 364 and continue to it
 Continue through the loop until you get to the 5th record
 How did you know you were on the 5th record?
 What package does the program belong to? Who last changed the program
 Answer: Z001, Hennie Nel
 Launch the ABAP code editor from the debugger to view code in the
SELECT_DATA sub-routine
 What is the current system time?
Session 4
 In this session you will learn to:
 Debug an update process
 Debug an Idoc process
 Debug a modal window
 Step backwards in debugging
Debugging Tips – Update Debugging

 IDocs and printouts are function performed in an update task. A

simple /H will not enter the code if it’s executed in a separate task. To
debug an update task.You should execute the debugger and select
Settings -> Display / Change Debugger Settings from the debugger
menu
 Continue with your initial debug session and another separate update
debugging window will appear where you can then debug your update
tasks further.
 V1 update = Critical updates – Same LUW processed consecutively –
Locked together with calling transaction
 V2 update – Less critical – Separate LUW – No locks
Debugging Tips – Idoc Debugging
create a breakpoint At Function where the function
 Activate update debugging to 
module is the outbound function as defined in the
appropriate partner profile setting.
get the update debugger  Shown below is the path of how to get from Output
window type -> Function IDOC_OUTPUT_ORDERS
Debugging Tips – Modal Window

 In common dialogs, the okcode field is available as shown in

the top left picture
 But it is not available in modal windows (we see it but we
can't enter anything in it) as shown in the top right picture
Debugging Tips – Modal Window ctd.
 The solution is to create on the
frontend a SAPGUI shortcut (file
with extension .SAP), of type
System Command and
command /H, and drag and drop
it from Windows desktop to the
SAP modal window.
Debugging Tips, Stepping Backwards
 If you are debugging a
program but have executed
too far and you want to
retrace your steps by a few
then in most cases it’s
possible to do so…

 Note: There are limitations to using this

command but will often work in the
situation we most need it… Executing
a function module only to see that the
error occurred in that function module
so you want to go back to it so you can
step inside to see the error…
 You may need to reset variables that
were set in the code
Session 4 - Exercise
1. Update debugging
Transaction VA01
Sold to Customer = 300
Order Type = ZOR (Sales Area = 1000,10,00)
Material = 205115

a) Save the order and launch an update debugging

b) Continue and stop at function module SWE_EVENT_CREATE
i. What event is triggered against which object?
c) What are some of the functions called in update debugging?
d) What type of update debugging are we looking at?
e) What is the main calling program for the V1 update?
f) How long is your update session in place for?
Session 4 - Exercise
2. IDoc debugging
• Outbound
• Reprocess output for a PO (E.g.
5100018105)
• What output is used for EDI
POs?
• Break the program in the
Idoc processing program for
the ORDSERS Idoc
• How did you find the Idoc
processing program?
• Inbound
• Using the Idoc test tool WE19
debug the processing for Idoc
1576152 in ELD 110
Session 4 - Exercise
3. Modal debugging
Transaction VA01
Sold to Customer = 300
Order Type = ZOR (Sales Area = 1000,10,00)
Material = 205115

 Save the order and debug

after choosing a selection
on the modal screen shown
to the right
Session 4 - Exercise
4. Debugging Tips
 Step backwards in a debug session
 Report
o Transaction ZEM1
o Sold to Customer = 300
o Order Creation Date = 12/4/2011 -> 01/03/2012
 Break-point on line 415 in the SELECT_DATA sub-routine
 Continue to the break-point set above
 Check data value in <DATA>-SO_CREATEDBY and then delete it
 Execute the perform map_ecc_fields again on line 410 but first change the
value for WA_EVENTHANDLERHEADERS-TRACKINGID to
0100427007000060
 What is the new value in <DATA>-SO_CREATEDBY?
Session 4 - Exercise
4. Debugging Tips
 Garbage Collector
 Start the garbage collector?
 What is the garbage collector?
 Hint: The purpose of garbage collection is to identify and discard objects
that are no longer needed by a program so that their resources may be
reclaimed and reused.
 As soon as no more references point to an object, the Garbage Collector
removes it from the memory
Session 4 - Exercise
4. Debugging Tips
 Local and Global variables
 Check to see if you can find the local and global variables found in sub-routine
SELECT_DATA of program ZEM_OTC_ORDERSTATUS
 What is the difference between the 2 types?
 Where do you go to view / update / delete all the breakpoints and
watchpoints that you have created in your debug session?
 SUCCESS!!!!

You are now certified a genius