Basic ABAP

Debugging
For SAP Professionals

Gaurav Singh
Basic ABAP Debugging For SAP Professionals

Date: 06-01-2025

Time: 08:43 am

Context:

1. Introduction
2. What this is not about
3. What this is about
4. Brief Overview of ABAP Programming
5. How ABAP code works
6. Accessing the Debug Mode
7. Breakpoints
8. Understanding the ABAP Code
9. SAP ABAP Business Objects
10. System Variables
11. Debugging Techniques
12. Debug Environment
13. Navigation and Execution Controls
14. Setting the breakpoint on Message Class
15. Ending a Debug Session
16. Analyzing ST22 Dumps
17. What’s Next
18. References

A Note for Readers

1
#1: Introduction – Basic ABAP Debugging

Debugging is the process of finding and fixing errors in a software code, also known as bugs. It is an
important part of software development as it improves the quality of code and enhances user
experience.

In SAP, we do some custom code enhancements and develop other custom objects as per the
business requirements. Most often, we find certain scenarios where the code/functionality does
not work as per our expectations and sometimes we directly get the dump or exceptions.

In such cases, we need to debug the code and resolve the issue asap to avoid the business loss.

Now to be clear first, there is no such thing as basic debugging. Debugging is an extensive and
exhaustive process. It may take 5 mins to debug an issue, or it might take several hours as well. It is
of utmost importance that one has basic knowledge of ABAP programming that includes data
objects, conditional statements, select queries, loop and other paradigms but not limited to just
that. Without complete knowledge, I’d quote Samuel Johnson:

A little knowledge is a dangerous thing.

Now the question arises, what about the functional consultants or let’s say Basis or PI/PO
consultants who have very little to do with the technical code and ABAP know-how? How can they
utilize debugging to assess the issues firsthand in case of an emergency or in any other scenario?

To simplify the process, we would first begin with bare minimum prerequisites details and then
proceed with the debugging process.

#2: What this is not about

Few words of disclaimer first:

 This is not about debugging SAP workflows error.

 This is not about debugging OData issues either.
 This is not about finding Adobe Forms Bugs.
 This is not about how to resolve IDoc issues.
 This is not about finding issues with some enhancement.
 This is not about any of the standard program errors including any BAPIs.
 This is not about resolving any ABAP Proxy errors.
 This is not about debugging AMDP Class.
 This is not about resolving issues with Cloud based development (RAP/BTP/etc.).

#3: What this is about

As mentioned, this document does not help with any of the above points directly. So, what is this
about?

2
This is about basic understanding of how ABAP code works with SAP NetWeaver Client and
enabling one to resolve minor issues related to ALV reports or any transaction code, whatsoever. It
is with practice, multiple debugging scenarios and understanding of the object type, one can gain
confidence to analyse and propose the resolution for a problem. It can also be helpful with
understanding of the ABAP code to deduce the business logic (as seen and required in some
instances).

#4: Brief Overview of ABAP Programming

Why ABAP?

We have several programming languages these days, such as Java, Python, C, C++, JavaScript, then
why another language?

ABAP, popularly known as Advanced Business Programming Language, is a high-level application

programming language used by SAP to cater the various business needs. To put it in simple terms,
ABAP is the language of SAP NetWeaver Platform. It is currently positioned, alongside Java, as the
language for programming the SAP NetWeaver Application Server, which is part of the SAP
NetWeaver platform for building business applications.

It is easy to use and understand.

All ABAP programs reside inside the SAP database.

In the database all ABAP code exists in two forms: source code, which can be viewed and edited
with the ABAP Workbench tools; and generated code, a binary representation somewhat
comparable with Java bytecode.

ABAP programs execute under the control of the runtime system, which is part of the SAP kernel.

The runtime system is responsible for processing ABAP statements, controlling the flow logic of
screens and responding to events (such as a user clicking on a screen button).

#5: How ABAP code works

ABAP is structured around a three-tier structure –

[1] Presentation Layer: This layer is responsible for user interaction with the SAP system. It
provides an interface through which users input data and receive outputs. Users can access this
layer via various channels, such as SAP Logon Pad, SAP Business Client, SAP Fiori, web browsers,
or mobile applications. The graphical user interface (SAP GUI) is commonly used for this purpose.

[2] Application Layer: This layer contains the ABAP application server, which processes user
requests and contains the business logic written in ABAP code. All ABAP code executes in this
environment, which acts as the runtime environment for ABAP programs.

[3] Database Layer: This layer manages data storage and retrieval. All ABAP programs are stored in
the SAP database in two forms: source code and generated binary code.

3
(You can skip this part if you want)

ABAP programs are executed within the SAP kernel’s runtime environment. The execution process
involves several key components:

 Runtime System: The system interprets ABAP statements and manages application flow,
similar to virtual machine. It handles user events and controls program execution.
 Database Interface: ABAP uses a database interface to convert database-independent
SQL statements (Open SQL) into statements that can be understood by specific DBMS
being used (Native SQL).
 Change and Transport System (CTS): This system manages the development lifecycle of
ABAP programs, ensuring that changes are tracked, versioned and transported across
different environments (development, testing, production) without conflicts.

Programming Features

 Event-Driven Programming: The execution of ABAP programs can be triggered by user

actions or system events.
 Modular Programming: Developers can create module pools that consist of multiple
screens and associated logic, enhancing code organization and usability.
 Data Manipulation: ABAP provides robust capabilities for handling database tables,
internal tables and data structures.
Important

Talking specifically about event-based programming and screen-based programming. In SAP, for
each screen you see on SAP NetWeaver client, there is some ABAP-code behind its execution and
control. That means, there’re multiple programs written in ABAP language for whatever we see on
the GUI screen. Similarly, for each action, like, Enter, Back, Execute, Cancel, Save, there are chunks
of code responsible for the corresponding processes on that part. These codes can be organized
into multiple programs for ease-of-availability and multiple use.

These two points are very helpful in understanding the basics of ABAP programming.

I’ll give you a basic example.

When I open SE16N transaction.

I see a table display screen where I can enter the name of any DDIC table and see the data stored in
those tables.

4
Now I click on the System and then go to Status.

I see the screen below.

5
Here, we can see, we have Transaction, Program (Dynpro), Program (GUI), Dynpro Number and GUI
Status.

Dynpro number is the screen number. And Program (Dynpro) is the ABAP program. If we double
click on the program, it takes us to the below screen, which shows a function group, containing
multiple include programs. We can double click on the include program names and check further
for subprograms.

6
If we double click on the Dynpro number, then it takes us to the Screen Painter.

7
8
Here with easy click on layout option, we can explore the design view of an SAP screen.

We can double click on each of the elements to explore further.

9
Gist: To put in one line, in SAP ABAP programming, there is a screen and there’s some code behind
the screen.

Talking about the third point, we have different types of business data in our database, and we
manipulate those data using ABAP programming with operations such as create, read, update and
delete.

#6: Accessing the Debug Mode

Debug Mode: Debug mode is a user interface that allows users to view and change a program’s
internal state to find bugs. It is a simulation of the running program except we can see through the
code part that runs behind in the background.

If you have watched the Hollywood movie, Lucy, then you must remember how the character of
Scarlett Johansson gets the power to see everything at a molecular level that she even finds out
that her best friend is suffering from a deadly disease by just looking at her. Her eyes can observe
the blood flowing through the veins and even the electric signals coming to and fro. Debugging is
akin to the same experience in the programming world.

If coding is magic, then debugging is black magic.

In SAP, there are two ways to enter the debug mode.

10
[1] Using /h transaction: Suppose I’m running MB5B report transaction, and I enter the selection
screen parameters to run the report. Now I would like to know what is going on at the code level. So,
before hitting F8 (execute) button, I enter /h in the transaction code box and press enter.

We can see at the bottom that the debugging has been put on in active mode.

11
Now whatever action we may perform it triggers the subsequent code. I hit F8 and enter the debug
mode. This is our debug environment.

[2] Using Breakpoints: We can also enter the debugging mode by using the breakpoints.

For this, let us again take the example of MB5B report.

12
We go to System->Status and then we can click on either the report ‘RM07MLBD’ or Dynpro
Number, i.e., Screen Number ‘1000’ to enter the code.

13
I click on the report.

Now when you enter an executable report with a selection screen. You can see at the top first line,
it begins with the keyword REPORT.

The very presence of the keyword ‘REPORT’ signifies that this must be an executable program. We
do F8 and it goes to some kind of selection screen if it exists (this is the general perspective, but it
may not be necessary).

It means there must be some other kind of program that are non-executable directly. Yes.

There are different kinds of programs in SAP. We will know more about them in the later part.

Does this question pop up in your mind, what is a program?

A Program is a set of instructions that we pass on to our computer so that it performs some tasks.

14
START-OF-SELECTION: This event keyword defines the standard processing block of an executable
program. The associated event is raised by the ABAP runtime environment.

It means that when we run a report, the actual processing part begins after the START-OF-
SELECTION statement.

We can analyse the code after this keyword, or we can put the breakpoint to debug.

15
Now, what is a breakpoint?

#7: Breakpoints

Breakpoints: A breakpoint is a signal at a particular point in the program that tells the ABAP
runtime processor to interrupt processing and start the Debugger. The Debugger is activated when
the program execution reaches this point.

In layman terms, a breakpoint breaks down the program so that we can run, process and
understand how the code is working at runtime.

There are different types of breakpoints – static breakpoints, dynamic breakpoints, internal
breakpoints or session breakpoints, external breakpoints or user breakpoints.

From a general debugging perspective, we will learn about the session breakpoints and the external
breakpoints.

Session Breakpoints: A session breakpoint is attached to a user’s session, which exists from the
point in time where the user logs into SAP until they close their last SAP dialog window. The icon
looks like a computer monitor set in front of a stop sign. You can set a session breakpoint, then
open a new session and close the editor window with the session breakpoint and that breakpoint
will still exist. Depending on your role as a developer, session breakpoints may be all you need to
debug ABAP code. Session Breakpoints are also known as Internal Breakpoints.

External Breakpoints: An external breakpoint is attached to the user that set it, and behaves
similarly to a session breakpoint. The icon looks like a person set in front of a stop sign. The major

16
difference is that it exists for 2 hours and can launch the debugger when triggered by an external
process. This makes external breakpoints useful for debugging RFC (Remote Function Call)
processing, ICF (Internet Communication Framework, e.g. HTTP) processing and APC (ABAP Push
Channels) processing. External Breakpoints are also known as User Breakpoints.

Debugger Breakpoints: There is a third kind of breakpoint called a debugger breakpoint that you
can only set after the debugger has already started. The debugger breakpoint icon looks like a stop
sign. These breakpoints will only exist for the lifespan of the debugger session and are useful if you
want to set additional temporary program flow interruptions. While in the debugger, you can save
your breakpoints (using the disk icon at the top of the screen) to turn them into session
breakpoints.

Apart from the above-mentioned breakpoints type, there are two other breakpoints that are useful
from the developer perspective.

Static Breakpoint: Static Breakpoints can be set up in the code using the syntax BREAK-POINT.

They are also called user independent breakpoints or Persistent Breakpoint. One should not keep
this active in the code while moving the changes further as it causes the program to break down at
the mentioned point irrespective of the users or system.

Dynamic Breakpoint: Dynamic Breakpoints are user dependent. They can be added in the code
using the syntax BREAK <SAP Logon userID>. For example, BREAK USR001.

#8: Understanding the ABAP Code

The best part of ABAP programming language is its almost-English-like easy-to-understand syntax.

Data Objects: Anything that contains some form of data is known as a data object. In ABAP
programming, there are various types of data objects, such as, variables, structures, tables, etc.

 Variable – a variable contains a single value. Generally, variables in ABAP programming

begin with lv* or gv*, for example, lv_len, lv_sum, gv_plant, etc.
 Structure – a structure contains one dimensional array of values. Structures in ABAP are
often defined as ls*, gs* or wa*, for example, ls_ekko, gs_likp, wa_vbap, etc.
 Table – a table can contain multiple entries of an array of values. Tables are generally
defined as lt*, gt*, for example, lt_but000, gt_data, etc.
 Reference Object – objects contain references to classes or other data objects, they are
defined as lo*, lo_bcs, lo_ref, etc.
 Field Symbols – Field Symbols are similar to a structure in the way they refer one
dimensional array of values, but unlike structures, field symbols do not hold any memory
themselves, they act as a placeholder for another data-object. Field symbols begin with fs*
or lfs* most often. For example, <fs_data>, <lfs_vbep>, etc.

It is necessary to be aware of this naming convention so that when we debug, we can easily relate
what we are referring to. Most of the standard SAP code, though, might not follow the naming
conventions mentioned but in the custom code, you will find more of such instances.

17
Data Objects in ABAP programming, are declared using the DATA keyword.

If you see anything like DATA: lv_abc TYPE xyz, it means, a new data object has been declared.

You cannot set the breakpoint on such lines.

Type Declarations: Types declarations are used to define the data types for the data objects.

Often used for structure and tables, type declarations begin with the keyword TYPE.

TYPE: BEGIN of ty_abc,

X TYPE a,

Y TYPE b,

END of ty_abc.

You cannot set the breakpoint on type declarations.

Select Queries: Select queries are Open SQL statements used for reading data from one or more
database tables, classic views or CDS entities into data objects.

Conditional Statements: Conditional Statements or decision control statements have one or

more block of statement that are to be evaluated by the program and is executed only when certain
conditions are met.

IF. ELSEIF. ELSE. ENDIF.

CASE. WHEN. ENDCASE.

These are all examples of conditional statements.

Value Assignments: We can assign value from one data object to another using different
statements.

Some examples are direct, like, a = b, and some uses expressions like, MOVE CORRESPONDING,
APPEND, WRITE.

Operations: Apart from data declarations, type declarations, select queries and conditional
statements, there are various other operations we perform in an ABAP program. Such as reading an
internal table or looping through it. Modifying the database.

We can identify them with keywords LOOP, ENDLOOP, READ, REPLACE, MODIFY, UPDATE, INSERT,
DELETE, etc.

Call Programs:

You can call another program inside your SAP Program very easily. You can identify them with
keywords such as CALL FUNCTION, CALL METHOD, SUBMIT, etc. Whenever we call one program
into another then there are various parameters used as references, such as importing parameters,
exporting parameters, changing and returning parameters.

18
When creating an object, importing parameters take the value and exporting parameters export the
value. But while we call the same program in another program, then we mention EXPORTING
keyword before importing parameters (as we’re exporting the parameters into another
function/method) and IMPORTING keyword before exporting parameters (as we’re importing the
values from the original function/method into our program).

Apart from this you can find all sorts of statements in the ABAP code. Most of which you’ll be able
to generalize once you become familiar with the art of debugging. Knowing this much is also good
enough from a beginner’s perspective.

We can put the breakpoint only on executable lines. Executable lines can be your select statement
queries, conditional statements, operations, assignments, beginning of a call
program/function/method, etc. We are unable to set breakpoints on data declarations, type
declarations, anywhere in-between a call function or some non-executable blank line or a
comment.

#9: SAP ABAP Business Objects

In SAP ABAP, there are various business objects and tools where ABAP code can be written.

Below is a categorized list of a number of these objects along with their corresponding transaction
codes for accessing the code editor.

1. Function Modules
 Description: Reusable sub-programs with importing/exporting parameters.
 Transaction Code: SE37 (Function Module Editor)

2. Methods in Classes (Object-Oriented ABAP)

 Description: Methods are part of object classes and can hold reusable business logic.
 Transaction Code: SE24 (Class Builder – Global class and methods are defined here)

3. Programs
 Description: Custom ABAP programs for reports or module pools.
 Transaction Code: SE38 (ABAP Editor for Programs) and SE80 (ABAP Development
Workbench, integrated editor)

4. Business Objects
 Description: Representations of business processes in SAP, used in frameworks like BOPF.
 Transaction Codes: SW01 (Business Object Builder) and SW02 (Business Object Browser)

5. Forms and Scripts

19
 Description: Logic for SAP Scripts, Smart Forms and Adobe Forms
 Transaction Codes: SE71 (SAPscript Form Painter), SMARTFORMS (Smart Forms
Administrator), SFP (Adobe Forms Layout and Interface)

6. User Exits/Enhancements
 Description: Various types of implicit/explicit, customer exit, user exit for
enhancements
 Transaction Codes: CMOD/SMOD

7. BADIs (Business Add Ins)

 Description: Object-oriented enhancement type for standard SAP code
 Transaction Codes: SE18/SE19

8. Subroutines and Includes

 Description: Modularized reusable blocks of code included in programs.
 Transaction Codes: Managed with the program editor (SE38)

9. Workflow Templates
 Description: Used to define workflows for business processes.
 Transaction Codes: SWDD (Workflow Builder)

10. CDS Views/AMDP Classes

 Description: Used to define logic for consumption in OData and other CDS Views or ABAP
programs
 Transaction Codes: Requires Eclipse software as an editor along with ADT Toolkit. In SAP
GUI, CDS Views logic can be seen using available SQLView in SE11 transaction code

Apart from this, there are various other kinds of ABAP objects such as IDoc, Table Maintenance
Events for data dictionary objects, etc. They all basically use function modules or programs for
writing the code.

#10: System Variables

There are multiple system variables available in the debugging mode that provides the runtime
information.

20
 sy-subrc – sy-subrc is used to check whether the current statement has been executed
successfully or not. Normally used after a select query or read statements, it informs about
execution status of a statement. If success then sy-subrc shows the value 0, or else, it is 1
(or something else).
 sy-tabix – sy-tabix returns the current index inside a loop
 sy-langu – sy-langu provides the current system language
 sy-tcode – sy-tcode gives the current executed transaction
 sy-datum – sy-datum gives the current system date
 sy-uzeit – sy-uzeit gives the current system time
 sy-repid – sy-repid gives the report (main program) name
 sy-mandt – sy-mandt provides the client information
 sy-uname – sy-uname gives the current username

#11: Debugging Techniques

Let’s suppose I enter the transaction MM01. If you know the bare minimum of material
management (i.e., MM Module) then you must be aware that the MM01 transaction is used to create
a material master record. This record contains information about material, its description, unit of
measure, material type, etc.

Then we enter some random material number, let’s say, I enter M1234, as the material and then hit
enter.

21
But how do we get this message?

It must be written somewhere in the code, right?

Generally, if you’re an MM Consultant, you’d know, this is a mandatory field for creating material
master records and you’d enter it and move on. But we need to debug to see, what’s in the code?

Generally, we believe that whatever you see on the screen, the good or bad, the wanted or
unwanted, the process running or the errors and dumps, they’re there because it’s all part of the
code.

To get better at debugging means to understand the code. Understanding the code means getting
familiar with the coding language and the programming conventions. Here, we double click on the
error message.

22
Whenever we double click on an error message coming as an alert on the screen, it takes us to the
assistant and informs us about the source of the error message.

Two things in this context are very important as they’re highlighted above, i) first is, the message
class and the message number, in this case, it is M3 and 098 respectively, ii) second is, the tool and
key icon just above it (in simple Hindi, we say, click on Paana).

When we double click on the tool and key icon, we find the first thing more precisely and along with
that the program data.

23
You can double click on the Line, 54, in this case, or you can click on the main program also (but
then you’d have to navigate through include).

We see that on line number 54, there is a MESSAGE keyword raising an error message that
materialtype missing. In this way, if you ever face this situation, where you get some error on your
SAP GUI screen, you can navigate to the part of the code that is responsible for the error message.

24
Remember, we have reached up to here without even entering the debug mode. The point is,
understanding and clarity is more important than the tools in our hands.

Now we are going to put a session breakpoint just above this line and we’re going to debug.

We click on the designated line and then we click on the highlighted button (the stop icon with
monitor in front).

Note: Make sure you have proper debug access authorization, if not, then connect with your basis
team. Check SU53 transaction if you get any authorization issue.

25
Once the session breakpoint is set, you can see the same icon on the designated line and an
information message at the bottom. We then go back to the MM01 screen closing all the open
dialog boxes. And with material already entered on the screen we again hit enter.

As we hit enter, a debugging screen opens in a separate session.

#12: Debug Environment

26
Let us briefly understand the meaning and use of these screen tools highlighted in the above
picture.

First of all, we’re in the New ABAP Debugger (or what we call Standard Debugging Environment),
there is an old debugging environment as well, called classic debugger (check that for yourself
please).

Main Components of the Debugger User Interface:

 Process Information Area – It displays the current status of the debug, such as program
name, user and session details. It is above the control area.
 Control Area – It displays the navigation control keys such as F5, F6, F7 and F8 or execution
keys as well as options for customizing the debugger layout.
 Source Code Information Area – It shows the current ABAP source code (highlighted as
Program Navigator) with features to set breakpoints, view code context, etc.
 Screen Navigator – It includes desktop screens and other standard screens. There are
three user specific desktops (Desktop 1, 2, 3) and seven standard desktops (such as
Standard, Structures, Tables, Objects, etc.). Each desktop can hold up to four tools.
 SY-SUBRC and SY-TABIX Indicator checks – These indicator checks inform about the
current status of the execution. For example, sy-subrc tells if a statement has been
executed successfully or not. If a statement is executed successfully then it shows 0 or else
if it shows 1, 2, 4 or any other non-zero number, it means, the statement has been failed to
execute. Similarly, sy-tabix informs about the current line index most often used with loops.
 ABAP and Screen Stack – It displays the sequence of the screens and programs called with
corresponding number.

27
 Runtime variables and other parameters – On the bottom right, we can see a small
window with Variables 1 and Variables 2 tabs. Here, it displays the runtime values of data
objects. Let’s suppose, I double click on some variable in the program code, then it will
display the value of that variable here.

#13: Navigation and Execution Controls

Step (F5): Executes one statement at a time, including entering subroutines or function modules.

Execute (F6): Executes the current line, skipping over subroutine or function module code.

Return (F7): Completes the current routine and returns to the calling context.

Continue (F8): Runs until the next breakpoint or end of the program.

Go to Statement (Shift+F12): Jump directly to a specific line of code, bypassing blocks as needed.

Apart from this you can also notice the main program, include program, and function module name
below navigation control keys. Let’s debug.

Note: When we debug the code, then there are mainly two approaches, one, we move forward and
go line by line with the execution and understand the process, two, we reach a particular point in
advance, and we move backwards and then analyse the process.

Here as we already know, we are using the second approach. We found an error message, we put
the breakpoint on the message and then we will now move backwards to the source.

28
Here I stay on the Standard screen and I double click on the two variables present on line number
53, i.e., neuflag and mtrart_input. We see that both are showing their values in the variable window,
with newflag marked as ‘X’ while mtrart_input is initial (means blank). The statement on line
number 53, declares, If this neuflag variable is not initial (notice the NOT before neuflag) and
mtart_input flag is initial then it will go to the next line, i.e., the error message, which we got in our
case. What if the condition fails. Then it will skip the next line and it is going to check the elseif
condition written after the IF condition.

Let’s do some fun. We’re going to change the neuflag variable (looks like we have got some access).

We go to the variable window and we click on the small pencil (edit) icon.

We remove the ‘X’ value and hit enter.

29
We click then F5.

You see, the execution control moved to the next elseif condition instead of the message on the line
number 54. But wait. If you see line number 56 and line number 54, then they’re identical. It means,
now neuflag is initial and if I click on mtart_mara then we see it is also initial.

30
Here, in this case, we are going to get the same error message again.

You click F8 and you find the same error message again.

31
The point is we must learn to understand these statements, what do these statements mean? Only
then would we be able to debug and analyse properly. Again, we are going to debug but this time,
we will go differently.

We will first remove the session breakpoint that we had added previously. To remove a session
breakpoint, you again go to the program and click on the same icon that we had used for putting the
session breakpoint.

You can see the message on the bottom. We can also delete a session breakpoint the same way in
the debug mode as well.

#14: Setting the Breakpoint on Message Class

We put /h in the transaction code box before hitting enter twice.

32
Now you can see we have entered a different session than the previous one.

Talking about the approaches, this is the forward moving approach. In the call stack, you can notice
on number 1, there is TRANSACTION MM01 then we have a screen call for 1000 after that, there is
a module call named START_DIALOG and in the current scenario we are processing the screen

33
0060 after the user entered the value (PAI, means, process after input, PBO means, process before
output).

Now, suppose we know the error message class and message number. How do we get there
directly?

We click on Breakpoints/Watchpoints screen, and we put a breakpoint on the message ID and

message number.

We click on the create icon.

34
Then we click on the Message tab.

We must know the message ID and message number. See the reminder screenshot below.

35
Once you enter all the three information, i.e., message ID (or message class), message number and
message type (E for error in this case), you hit enter.

You can see the notification at the bottom. Then we go to the desktop 3 or standard screen and hit
F8. You will see, we reach the same screen with the error message.

36
Similarly, we can also put the watchpoints. Watchpoints are added on a free condition or some
variables. You can find it out by yourself, or we’ll check it in the next part of the series.

#15: Ending a Debug Session

There are 3 ways to end a debugging session.

 Restart – In this option, the debugger is closed, and application is restarted.

It means that you can run the same transaction again while the previous transaction is
aborted.

37
 Exit (Close Application) – In this option, both debugger and application is closed. The
transaction is stopped in-between.

 Exit (Application continues running) – In this option, debugger is closed while application
continues running. This is similar to F8. The transaction is completed in this option.

38
#16: Analyzing ST22 Dumps

Before learning how to check a dump, we must know the difference between an SAP error and ABAP
dump.

Dumps happen when an ABAP program runs and something goes wrong that cannot be handled by
the program. Generally, dumps are the triggered exceptions generated during runtime that are not
handled properly. Dumps that happen in the customer namespace ranges (i.e., custom program),
can usually be fixed by the programmer. Dumps that happen in SAP standard code probably need a
fix from SAP (or value check by the functional).

In SAP, an “SAP error” is a broad term referring to any system error that occurs within the SAP
application, while an “ABAP dump” is a specific type of SAP error that happens when an ABAP
program encounters a runtime error, providing detailed information about the error location and
cause within the program’s code. It means, all ABAP dumps can be considered as SAP errors, but
all SAP errors are not necessarily ABAP dumps.

Whenever we encounter a dump, the program execution is stopped, and a new screen comes up
with the detailed explanation of the dump.

We can also check the list of generated dumps for a specific time or user, using the transaction
code, ST22.

I run a custom program and get a dump.

I go to ST22 transaction to check the log.

39
Now you can see the program name and timestamp in the log list. Either double click on the entry
or select the entry and click on display icon.

Here you can find all the details such as ABAP Program, runtime errors, exception, date and time,
etc.

40
You can either scroll down or you can navigate through the left menu bar.

You can find error analysis, source code, how to correct the error, details there.

If you click on Source Code Extract, then it takes us to the program source code. If we scroll down,
then you’d find arrows pointing down to a line that is breaking at run time and triggering exception.

41
#17: What’s next

Let us take a brief look at what are the remaining topics in debugging which we can explore further:

 Debugging using external (user) breakpoint.

 Setting up watchpoints in a debug session.
 Debugging in update task module.
 Memory analysis.
 Debugging an adobe form object, module pool programs, enhancements, OData, workflow
errors, AMDP class, etc.

#18: References:

 https://community.sap.com/t5/application-development-blog-posts/abap-dumps/ba-
p/13243664
 https://www.linkedin.com/pulse/mastering-sap-debugging-key-skill-abap-developers-
nishant-porwal-zgavf/
 https://community.sap.com/t5/technology-blog-posts-by-members/deep-dive-into-
abap-debugging/ba-p/13621386
 https://www.linkedin.com/pulse/abap-debugger-script-seunghyun-paek-lgmzc/
 https://www.linkedin.com/posts/pankajkumarsaptrainer_sap-abap-debugging-activity-
7126757520433364992-D00p/
 https://www.linkedin.com/posts/sap-knowledge-hub-ambikeya_debugging-
techniques-in-sap-abap-activity-7154765841534705664-OH6B/

42
A note for readers

My Fellow SAP Enthusiasts!

Hope you’re doing well and learning cool things.

This document is a small effort in the direction to democratize SAP knowledge to all the SAP
learners. Often asked by my colleagues and juniors, with a keen desire to learn SAP ABAP or
debugging, this short document is my answer to all those knowledge seekers. I know this is not the
complete package and much comprehensive or you can say the standard manual for the
academia, but, at the same time, I believe, may you receive some motivation and self-confidence
to start something and go through the SAP code with some clarity. Any mistakes if you find
anywhere are my own and I’m grateful to all the people who were/are kind enough to share their
knowledge with me in my formative years and continue to do so.

If you come up with any questions, feedback or suggestions, feel free to drop a ‘Hi’ to me on
LinkedIn:

https://www.linkedin.com/in/gauravskaintura/

Best,

Gaurav

43