If your program does not stop at breakpoints then follow the below list step by step.
Scope: This blog is about the ABAP Development Tools in Eclipse (ADT), not about the SAP GUI Debugger. Nevertheless, many of the following hints are also useful for the SAP GUI Debugger as well.
1) Check whether your breakpoint looks normal like this one
. If yes, that's good and you can directly continue with the next step of this check list.
If your breakpoint looks unusual like these
then follow the link to the corresponding detail section of this blog.
2) Check whether a notification appears on the lower right corner of your screen when you try to debug.
If yes, see the corresponding detail section.
3) Open transaction RZ11 and lookup the value of parameter rfc/ext_debugging. It should be 3. If the value is not 3, contact your administrator and ask him to change the value. More on this in the detail section.
4) Right click on the breakpoint and select "Refresh Breakpoint Activation". Close the program / transaction / app that you want to debug and completely restart it.
5) Verify that the program flow actually reaches the code line where you placed the breakpoint. Don't skip this step. It's a bit of effort, but it's also the root cause for more than 50% of all debugger-not-stopping situations. Being convinced that the program reaches a certain code line while it actually doesn't can also happen to very experienced developers. In case you are not sure how to verify, see the detail section.
6) Trying to debug the request of a foreign user? Are you sure the breakpoint is created for the user that is used to run the program/request? More on this in the detail section.
7) Trying to debug a background job / batch job? If yes, see the detail section.
😎 Trying to debug an update module? Is your code containing 'call function ... in update task'? If yes, see the detail section.
9) Trying to debug the request of a Fiori app? Start the app, press Ctrl-Alt-Shift-P and check whether your used UI5 version is at least
1.38.24
1.44.16
1.46.10
1.48.3
If your patch version (the 3rd number) is lower than the ones listed above, go to the detail section. If your version is equal or higher, that's good and you can continue.
10) Trying to debug across different clients (mandt)? Debugging cross-client is not possible and never was. You need to create the breakpoint in the same client where you execute the debuggee (= the program to be debugged).
11) System debugging? Trying to debug low level functionality of SAP basis? If yes, see the detail section.
12) Are you in one of the below listed scenarios?
- Parallel use of multiple ADT projects with the same combination of system, client and user
- Parallel use of ADT Debugger and SAP GUI Debugger with the same combination of system, client and user. Only external breakpoints of the SAP GUI are relevant, non-external breakpoints do not matter.
- Using same user & password together with other people (e.g. technical users or group users, like user 'DDIC')
If yes, see this blog.
13) If you are not sure whether sufficient debug authorizations have been provided to your user then double check. E.g. via transaction SU53 or ask the administrator to check.
14) Do you use tools that deal with ABAP breakpoints, besides ADT & standard ABAP workbench? E.g. ABAP in Visual Studio Code, transaction ANST, transaction SRDEBUG. If yes, please try to not create breakpoints / perform debug activities via those tools for a while and see whether it solves the issue.
15) Debugging across different ABAP servers within the same system is possible since many years and there are no known problems. There is no need to use transaction SRDEBUG at all, if your system is based on SAP_BASIS 7.02 or higher. I've put this on the list only for completeness, since many people still think cross-server debugging is a potential error source. Actually it is not. However, if you really want to, you can try to set the breakpoint on the same application server where the program to be debugged runs.
16) Did you verify that the code line with the breakpoint is actually reached as explained in 5)? If no, please go back to 5) and repeat that step.
From time to time there are bugs in the ABAP debugger, just like in any other software. Updating to the newest available versions is always recommended and can potentially fix the debugger-not-stopping situations.
A) If you checked the above and the ABAP debugger still does not work as expected: Feel free to create a customer incident for BC-DWB-AIE-TST (ADT Debugger & AMDP Debugger) or BC-DWB-TOO-DBG (SAP GUI Debugger).
A few hints that potentially speed up ticket processing of ADT incidents can be found in the detail section.
B) If code changes are possible you can try to use the ABAP statement 'break-point' instead of a normal line breakpoint (e.g. if sy-uname = 'my_user'. break-point. endif.).
C) If code changes are possible you might want to try the work around via endless loop & SM50 attach. More details on this in the detail section.
Debugging ABAP with ADT is easy. In more than 99% of cases you just create a breakpoint, start your program and everything works as expected. There is also no differentiation between external or non-external breakpoints in ADT anymore. I would like to highlight this, because when looking at the above list you could potentially assume ABAP debugging with ADT is complicated, while it's actually not.
1) Unusual looking breakpoint
a) Your breakpoint is decorated with a gray diamond. That means the source where you placed the breakpoint is currently inactive. Activate the source to make the breakpoint work.
b) Your breakpoint is crossed out. That means you activated the Eclipse feature 'Skip All Breakpoints' that can be used to make ALL breakpoints non-functional. Deactivate the 'Skip All Breakpoints' feature via main menu 'Run' -> 'Skip All Breakpoints'. Alternatively use the buttons in the Eclipse main toolbar or in the breakpoints view toolbar.
c) Your breakpoint is white. That means the breakpoint was disabled. To enable it keep shift pressed and double click the breakpoint. Alternatively open the context menu on the breakpoint and choose 'Enable Breakpoint'.
If you are told this cannot be done because '... debugging is disabled ...' click the link on the popup and activate the checkbox 'Enable debugger'.
d) Your breakpoint is green. That means you currently deal with a special kind of breakpoint which can be a soft breakpoint, a temporary breakpoint or an AMDP breakpoint. To identify what it actually is you can mouse hover over the breakpoint and check the hover text or you can open the breakpoints view and check the text there.
- Soft breakpoints are only effective in a running debug session but they cannot launch a new debug session on their own. This is a special feature for debugging situations with massive amounts of requests, e.g. catch one request with a normal breakpoint, disable that normal breakpoint and continue working with soft breakpoints. To remove the attribute 'Soft' from your breakpoint keep ALT pressed and double click it or change it via the breakpoints view.
- Temporary breakpoints occur in temporary editors, e.g. if you stepped into a foreign system via RFC or if you debug classic dynpros/screens with ADT. They are only effective in a running debug session but they cannot launch a new debug session. If you need a standard breakpoint that is able to startup a new debug session try a different/earlier source position.
- AMDP breakpoints are not ABAP breakpoints at all. Learn more about AMDP Debugging in this blog. A similar blog 'What to do if your DB procedure does not stop at AMDP breakpoints' is planned. It will be linked here once available.
e) Your breakpoint is decorated with a red cross. That means that there is a conflict with someone else who wants to debug the same requests as you do. Learn more about debugging conflicts in this blog.
f) Your breakpoint is decorated with a gray cross. That means the ABAP system is not reachable at all. Check whether your computer has a working network connection and whether the ABAP system is reachable at all (e.g. via SAP GUI).
g) Your breakpoint is decorated with a small U (User). That means you currently try to debug the requests of a different user. See this detail section.
h)
Your breakpoint is decorated with a small T (Terminal-ID). Unless you have a good reason you should not use this option at all. To go back to normal mode, right click a breakpoint, choose "Debug Properties..." and change the radio button to "Logon User".
i)
Your breakpoint is decorated with a small P (Project). That means you can only debug requests that are started from exactly the ADT project you are currently working in. That includes execution of ABAP unit tests, activities in embedded SAP GUI or class runs (Right click -> "Run As" -> "ABAP Application Console"). In this mode, you cannot debug requests from other ADT projects, from a web browser (e.g. Fiori Apps) or RFC requests.
If you are not sure what this project mode is good for or how you even entered it you can read this blog. To go back to normal mode, right click a breakpoint, choose "Debug Properties..." and change the radio button to "Logon User".
j)
Your breakpoint is decorated with a small C (Conditional). That means you added a condition to the breakpoint (e.g. "sy-subrc = 4"). The condition is evaluated during runtime once the breakpoint is reached. If the result is false, the debugger will not stop the program and there will be no debug session. For further details see the ADT documentation.
To make the breakpoint always stop, just remove the condition via the breakpoints view or via right click on the breakpoint and "Breakpoint Properties...".
2) Notification appears
If the notification contains a link "(Further Information)" then click on that link and check the details directly in ADT.
If the notification mentions the term non-exclusive see also the following ADT documentation.
If none of the above is helpful and the text on the notification is not understandable, then feel free to create a customer incident as described in the above section "Create a Ticket". Please add a screenshot of the notification or quote the text.
3) Parameter rfc/ext_debugging
In some systems the parameter rfc/ext_debugging shows 0 as recommended value, but that recommendation is wrong. Value 0 means ADT breakpoints and external breakpoints in the SAP GUI debugger are completely disabled for all users of the system. Value 3 means ADT breakpoints and external breakpoints in SAP GUI are allowed. Note 668256 describes the possible values in more detail.
In newer releases / support packages this parameter was completely removed by SAP, so it cannot be misconfigured anymore. Details about the removal of the parameter can be found in note 2909642.
Keep in mind that the parameter is server-specific, meaning it needs to be changed at every AS ABAP instance of the system.
5) Verify the breakpoint is actually reached
To ensure the code line with the breakpoint is actually reached during program execution you can use one of the following approaches:
a) Use a dynamic logpoint: Right click on the breakpoint, choose "Create logpoint...", press finish, re-execute the program that you want to debug, open the logpoints view and choose "Collect Logs from All Servers" (refresh icon), check the second column "Log Events" for your logpoint: If the counter is 0 then the code was NOT executed. More information about dynamic logpoints can be found in this blog.
b) Create another breakpoint at a very early entry point and check whether that one works. If it does, step down into the code that you want to debug to see whether it is actually reached.
c) Disclaimer: This option is on your own risk. Only do this if you are completely aware of what an ABAP dump is and what consequences it might involve.
To be absolutely sure whether a certain piece of code is reached or not, you can provoke an ABAP dump, e.g. by adding the following code:
if sy-uname = 'your_name'.
assert 1 = 2.
endif.
Execute your program and trigger the dump. Check ST22 or the ADT dump feed (view "Feed Reader") for the ultimate proof on whether your code line was reached or not.
d) Use the ABAP Profiler or other tracing functionality to double check what code sections were actually reached
6) User mismatch
The program / request you want to debug is processed under a certain user and this user must be identical to the user in your debug settings.
To check your debug settings right click on a breakpoint and choose "Debug Properties...". It shows for which user you are currently debugging.
To see under which user the program to be debugged is processed, there are different options:
a) [Requires authorization for using dynamic logpoints] Right click on your breakpoint and choose "Create Logpoint...". Add "sy-uname" to field "Variable(s)". Press finish and re-execute your program / request one more time. Check the results of the logpoint in the ADT view "Logpoints". For more details on dynamic logpoints see this blog.
b) [Requires authorization to change code] Change your code in a way that it writes sy-uname into a custom DB table, into a static logpoint or any other place where you can look it up afterwards.
c) Use tracing / monitoring tools to identify the user name. E.g. the ADT Profiler (ADT view "ABAP Trace Requests", keep the user field empty), transaction STATS, the ABAP Call Monitor, etc.
Also consider that RFC-calls in your program may include implicit user switches. Consider that processing of OData requests may contain RFC calls. E.g. if you have a system setup with frontend-server & backend-server, meaning UI5 sends HTTPS requests to the frontend-server and the frontend-server forwards them via RFC to the backend-server. If in doubt, check the configuration of your OData service.
7) Background Job / Batch Job
If you use ABAP Platform 2020 (SAP_BASIS 7.55) or higher:
Create a breakpoint and additionally activate the debugging for a certain job via transaction SM37 as described in the official documentation. This action requires debug change authorization.
If you use an older release:
There is no proper support for debugging of background jobs. Work arounds are described in note 573128.
😎 Update Debugging
In order to debug update tasks you need a breakpoint and additionally need to activate update debugging. Different to SAP GUI, in ADT you can do that only in a running debug session. That means you need a breakpoint before the relevant commit-statement, in order to start up a regular debug session.
Once you have a running debug session, select "ABAP Debugger Actions" from the eclipse main toolbar.
9) Old UI5 Version
Unfortunately, the UI5 versions below 1.38.24, 1.44.16, 1.46.10 and 1.48.3 contain an issue that makes UI5 requests undebuggable. The only possible work around is described here. The proper solution is to upgrade the UI5 version. Note 2468634 explains that upgrade, when starting from 1.48.1. In case that is not the UI5 version you are starting from, try to find a similar note / instruction on how to update or contact the component named in the above note.
11) System Debugging
Source code which is flagged as system code can only be debugged if you have system-debugging activated.
In order to debug such code, simply create a breakpoint at the position you want to debug. If you do this while having system-debugging currently deactivated, a popup will appear that asks you whether you want to activate system debugging now. Just click yes. You can undo that decision via the Eclipse menu "Window" -> "Preferences" -> "ABAP Development" -> "Debug" -> "Enable debugging of system programs".
A) ADT Ticket Hints
In order to speed up processing of ADT tickets, consider the following:
- Select from the Eclipse main menu "Help" -> "Collect Support Information..." and attach the resulting zip file to the incident. It contains the error log and support information like version numbers of your Eclipse, ADT and OS. This can speed up support.
- In order to reproduce an ADT issue from SAP side, we mostly need an NI connection. A standard SAP GUI support connection is helpful, but not sufficient to reproduce ADT issues. Note 1718597 describes how to open an NI connection. If you assume that a SAP supporter needs to connect to your backend system with his ADT, you can already open the NI connection together with the incident in order to speed up support.
- For HANA Studio users: HANA Studio on the one hand and ABAP Development Tools in Eclipse (ADT) on the other hand, are two different products. Since both are implemented as Eclipse plugins, it's possible to run them side by side in a single Eclipse installation. However, if you face issues that are clearly related to ABAP (e.g. issues with ABAP debugging), then you should be aware it's an ADT issue and not a HANA Studio issue, even though the program you execute on your PC may be namend HANA Studio. Keep this in mind when writing the ticket, because it reduces the risk that the ticket is routed towards HANA Studio teams instead of ADT teams. Of course SAP first level support knows the above, but it's better if the ticket author is also aware.
- Every information that helps us to narrow down the root cause is very welcome and could potentially speed up the processing of your ticket. For example: Is debugging working with SAP GUI but not with ADT or other way around? Is the issue occurring only for your user or also for other users? Is it occurring only in a certain ABAP system or in multiple? Is it limited to a certain scenario? E.g. debugging of unit tests fails while debugging of reports works. Is it reliably reproducible or only rarely occurring?
C) Endless loop work around
Prerequisites of this work around:
- Code changes are possible
- You have authorizations to change variable values in the ABAP debugger
- You can attach the debugger to a running ABAP process via transaction SM50
Procedure:
Add an endless loop to the source position where you want to stop, e.g.
if sy-uname = 'my_user'.
data(continue_loop) = abap_true.
while continue_loop = abap_true.
endwhile.
endif.
Execute your program/request and find its representation in SM50 (embedded GUI, e.g. via Alt-F8 -> SM50). Select the work process and choose menu 'Administration' -> 'Program' -> 'Debugging'. Once the debugger started up, change the variable value of continue_loop to space and leave the endless loop via F6.
Please ensure to not transport any endless loop into your productive system.
Scope: This blog is about the ABAP Development Tools in Eclipse (ADT), not about the SAP GUI Debugger. Nevertheless, many of the following hints are also useful for the SAP GUI Debugger as well.
Check List
1) Check whether your breakpoint looks normal like this one
. If yes, that's good and you can directly continue with the next step of this check list.If your breakpoint looks unusual like these
then follow the link to the corresponding detail section of this blog.2) Check whether a notification appears on the lower right corner of your screen when you try to debug.
If yes, see the corresponding detail section.
3) Open transaction RZ11 and lookup the value of parameter rfc/ext_debugging. It should be 3. If the value is not 3, contact your administrator and ask him to change the value. More on this in the detail section.
4) Right click on the breakpoint and select "Refresh Breakpoint Activation". Close the program / transaction / app that you want to debug and completely restart it.
5) Verify that the program flow actually reaches the code line where you placed the breakpoint. Don't skip this step. It's a bit of effort, but it's also the root cause for more than 50% of all debugger-not-stopping situations. Being convinced that the program reaches a certain code line while it actually doesn't can also happen to very experienced developers. In case you are not sure how to verify, see the detail section.
6) Trying to debug the request of a foreign user? Are you sure the breakpoint is created for the user that is used to run the program/request? More on this in the detail section.
7) Trying to debug a background job / batch job? If yes, see the detail section.
😎 Trying to debug an update module? Is your code containing 'call function ... in update task'? If yes, see the detail section.
9) Trying to debug the request of a Fiori app? Start the app, press Ctrl-Alt-Shift-P and check whether your used UI5 version is at least
1.38.24
1.44.16
1.46.10
1.48.3
If your patch version (the 3rd number) is lower than the ones listed above, go to the detail section. If your version is equal or higher, that's good and you can continue.
10) Trying to debug across different clients (mandt)? Debugging cross-client is not possible and never was. You need to create the breakpoint in the same client where you execute the debuggee (= the program to be debugged).
11) System debugging? Trying to debug low level functionality of SAP basis? If yes, see the detail section.
12) Are you in one of the below listed scenarios?
- Parallel use of multiple ADT projects with the same combination of system, client and user
- Parallel use of ADT Debugger and SAP GUI Debugger with the same combination of system, client and user. Only external breakpoints of the SAP GUI are relevant, non-external breakpoints do not matter.
- Using same user & password together with other people (e.g. technical users or group users, like user 'DDIC')
If yes, see this blog.
13) If you are not sure whether sufficient debug authorizations have been provided to your user then double check. E.g. via transaction SU53 or ask the administrator to check.
14) Do you use tools that deal with ABAP breakpoints, besides ADT & standard ABAP workbench? E.g. ABAP in Visual Studio Code, transaction ANST, transaction SRDEBUG. If yes, please try to not create breakpoints / perform debug activities via those tools for a while and see whether it solves the issue.
15) Debugging across different ABAP servers within the same system is possible since many years and there are no known problems. There is no need to use transaction SRDEBUG at all, if your system is based on SAP_BASIS 7.02 or higher. I've put this on the list only for completeness, since many people still think cross-server debugging is a potential error source. Actually it is not. However, if you really want to, you can try to set the breakpoint on the same application server where the program to be debugged runs.
16) Did you verify that the code line with the breakpoint is actually reached as explained in 5)? If no, please go back to 5) and repeat that step.
Update ADT, SAP_BASIS & ABAP Kernel
From time to time there are bugs in the ABAP debugger, just like in any other software. Updating to the newest available versions is always recommended and can potentially fix the debugger-not-stopping situations.
Create a Ticket
A) If you checked the above and the ABAP debugger still does not work as expected: Feel free to create a customer incident for BC-DWB-AIE-TST (ADT Debugger & AMDP Debugger) or BC-DWB-TOO-DBG (SAP GUI Debugger).
A few hints that potentially speed up ticket processing of ADT incidents can be found in the detail section.
Work Arounds
B) If code changes are possible you can try to use the ABAP statement 'break-point' instead of a normal line breakpoint (e.g. if sy-uname = 'my_user'. break-point. endif.).
C) If code changes are possible you might want to try the work around via endless loop & SM50 attach. More details on this in the detail section.
About ABAP Debugging
Debugging ABAP with ADT is easy. In more than 99% of cases you just create a breakpoint, start your program and everything works as expected. There is also no differentiation between external or non-external breakpoints in ADT anymore. I would like to highlight this, because when looking at the above list you could potentially assume ABAP debugging with ADT is complicated, while it's actually not.
Details Section
1) Unusual looking breakpoint
a)
Your breakpoint is decorated with a gray diamond. That means the source where you placed the breakpoint is currently inactive. Activate the source to make the breakpoint work.b)
Your breakpoint is crossed out. That means you activated the Eclipse feature 'Skip All Breakpoints' that can be used to make ALL breakpoints non-functional. Deactivate the 'Skip All Breakpoints' feature via main menu 'Run' -> 'Skip All Breakpoints'. Alternatively use the buttons in the Eclipse main toolbar or in the breakpoints view toolbar.c)
Your breakpoint is white. That means the breakpoint was disabled. To enable it keep shift pressed and double click the breakpoint. Alternatively open the context menu on the breakpoint and choose 'Enable Breakpoint'.If you are told this cannot be done because '... debugging is disabled ...' click the link on the popup and activate the checkbox 'Enable debugger'.
d)
Your breakpoint is green. That means you currently deal with a special kind of breakpoint which can be a soft breakpoint, a temporary breakpoint or an AMDP breakpoint. To identify what it actually is you can mouse hover over the breakpoint and check the hover text or you can open the breakpoints view and check the text there.- Soft breakpoints are only effective in a running debug session but they cannot launch a new debug session on their own. This is a special feature for debugging situations with massive amounts of requests, e.g. catch one request with a normal breakpoint, disable that normal breakpoint and continue working with soft breakpoints. To remove the attribute 'Soft' from your breakpoint keep ALT pressed and double click it or change it via the breakpoints view.
- Temporary breakpoints occur in temporary editors, e.g. if you stepped into a foreign system via RFC or if you debug classic dynpros/screens with ADT. They are only effective in a running debug session but they cannot launch a new debug session. If you need a standard breakpoint that is able to startup a new debug session try a different/earlier source position.
- AMDP breakpoints are not ABAP breakpoints at all. Learn more about AMDP Debugging in this blog. A similar blog 'What to do if your DB procedure does not stop at AMDP breakpoints' is planned. It will be linked here once available.
e)
Your breakpoint is decorated with a red cross. That means that there is a conflict with someone else who wants to debug the same requests as you do. Learn more about debugging conflicts in this blog.f)
Your breakpoint is decorated with a gray cross. That means the ABAP system is not reachable at all. Check whether your computer has a working network connection and whether the ABAP system is reachable at all (e.g. via SAP GUI).g)
Your breakpoint is decorated with a small U (User). That means you currently try to debug the requests of a different user. See this detail section.h)
Your breakpoint is decorated with a small T (Terminal-ID). Unless you have a good reason you should not use this option at all. To go back to normal mode, right click a breakpoint, choose "Debug Properties..." and change the radio button to "Logon User".i)
Your breakpoint is decorated with a small P (Project). That means you can only debug requests that are started from exactly the ADT project you are currently working in. That includes execution of ABAP unit tests, activities in embedded SAP GUI or class runs (Right click -> "Run As" -> "ABAP Application Console"). In this mode, you cannot debug requests from other ADT projects, from a web browser (e.g. Fiori Apps) or RFC requests.If you are not sure what this project mode is good for or how you even entered it you can read this blog. To go back to normal mode, right click a breakpoint, choose "Debug Properties..." and change the radio button to "Logon User".
j)
Your breakpoint is decorated with a small C (Conditional). That means you added a condition to the breakpoint (e.g. "sy-subrc = 4"). The condition is evaluated during runtime once the breakpoint is reached. If the result is false, the debugger will not stop the program and there will be no debug session. For further details see the ADT documentation.To make the breakpoint always stop, just remove the condition via the breakpoints view or via right click on the breakpoint and "Breakpoint Properties...".
2) Notification appears
If the notification contains a link "(Further Information)" then click on that link and check the details directly in ADT.
If the notification mentions the term non-exclusive see also the following ADT documentation.
If none of the above is helpful and the text on the notification is not understandable, then feel free to create a customer incident as described in the above section "Create a Ticket". Please add a screenshot of the notification or quote the text.
3) Parameter rfc/ext_debugging
In some systems the parameter rfc/ext_debugging shows 0 as recommended value, but that recommendation is wrong. Value 0 means ADT breakpoints and external breakpoints in the SAP GUI debugger are completely disabled for all users of the system. Value 3 means ADT breakpoints and external breakpoints in SAP GUI are allowed. Note 668256 describes the possible values in more detail.
In newer releases / support packages this parameter was completely removed by SAP, so it cannot be misconfigured anymore. Details about the removal of the parameter can be found in note 2909642.
Keep in mind that the parameter is server-specific, meaning it needs to be changed at every AS ABAP instance of the system.
5) Verify the breakpoint is actually reached
To ensure the code line with the breakpoint is actually reached during program execution you can use one of the following approaches:
a) Use a dynamic logpoint: Right click on the breakpoint, choose "Create logpoint...", press finish, re-execute the program that you want to debug, open the logpoints view and choose "Collect Logs from All Servers" (refresh icon), check the second column "Log Events" for your logpoint: If the counter is 0 then the code was NOT executed. More information about dynamic logpoints can be found in this blog.
b) Create another breakpoint at a very early entry point and check whether that one works. If it does, step down into the code that you want to debug to see whether it is actually reached.
c) Disclaimer: This option is on your own risk. Only do this if you are completely aware of what an ABAP dump is and what consequences it might involve.
To be absolutely sure whether a certain piece of code is reached or not, you can provoke an ABAP dump, e.g. by adding the following code:
if sy-uname = 'your_name'.
assert 1 = 2.
endif.
Execute your program and trigger the dump. Check ST22 or the ADT dump feed (view "Feed Reader") for the ultimate proof on whether your code line was reached or not.
d) Use the ABAP Profiler or other tracing functionality to double check what code sections were actually reached
6) User mismatch
The program / request you want to debug is processed under a certain user and this user must be identical to the user in your debug settings.
To check your debug settings right click on a breakpoint and choose "Debug Properties...". It shows for which user you are currently debugging.
To see under which user the program to be debugged is processed, there are different options:
a) [Requires authorization for using dynamic logpoints] Right click on your breakpoint and choose "Create Logpoint...". Add "sy-uname" to field "Variable(s)". Press finish and re-execute your program / request one more time. Check the results of the logpoint in the ADT view "Logpoints". For more details on dynamic logpoints see this blog.
b) [Requires authorization to change code] Change your code in a way that it writes sy-uname into a custom DB table, into a static logpoint or any other place where you can look it up afterwards.
c) Use tracing / monitoring tools to identify the user name. E.g. the ADT Profiler (ADT view "ABAP Trace Requests", keep the user field empty), transaction STATS, the ABAP Call Monitor, etc.
Also consider that RFC-calls in your program may include implicit user switches. Consider that processing of OData requests may contain RFC calls. E.g. if you have a system setup with frontend-server & backend-server, meaning UI5 sends HTTPS requests to the frontend-server and the frontend-server forwards them via RFC to the backend-server. If in doubt, check the configuration of your OData service.
7) Background Job / Batch Job
If you use ABAP Platform 2020 (SAP_BASIS 7.55) or higher:
Create a breakpoint and additionally activate the debugging for a certain job via transaction SM37 as described in the official documentation. This action requires debug change authorization.
If you use an older release:
There is no proper support for debugging of background jobs. Work arounds are described in note 573128.
😎 Update Debugging
In order to debug update tasks you need a breakpoint and additionally need to activate update debugging. Different to SAP GUI, in ADT you can do that only in a running debug session. That means you need a breakpoint before the relevant commit-statement, in order to start up a regular debug session.
Once you have a running debug session, select "ABAP Debugger Actions" from the eclipse main toolbar.
9) Old UI5 Version
Unfortunately, the UI5 versions below 1.38.24, 1.44.16, 1.46.10 and 1.48.3 contain an issue that makes UI5 requests undebuggable. The only possible work around is described here. The proper solution is to upgrade the UI5 version. Note 2468634 explains that upgrade, when starting from 1.48.1. In case that is not the UI5 version you are starting from, try to find a similar note / instruction on how to update or contact the component named in the above note.
11) System Debugging
Source code which is flagged as system code can only be debugged if you have system-debugging activated.
In order to debug such code, simply create a breakpoint at the position you want to debug. If you do this while having system-debugging currently deactivated, a popup will appear that asks you whether you want to activate system debugging now. Just click yes. You can undo that decision via the Eclipse menu "Window" -> "Preferences" -> "ABAP Development" -> "Debug" -> "Enable debugging of system programs".
A) ADT Ticket Hints
In order to speed up processing of ADT tickets, consider the following:
- Select from the Eclipse main menu "Help" -> "Collect Support Information..." and attach the resulting zip file to the incident. It contains the error log and support information like version numbers of your Eclipse, ADT and OS. This can speed up support.
- In order to reproduce an ADT issue from SAP side, we mostly need an NI connection. A standard SAP GUI support connection is helpful, but not sufficient to reproduce ADT issues. Note 1718597 describes how to open an NI connection. If you assume that a SAP supporter needs to connect to your backend system with his ADT, you can already open the NI connection together with the incident in order to speed up support.
- For HANA Studio users: HANA Studio on the one hand and ABAP Development Tools in Eclipse (ADT) on the other hand, are two different products. Since both are implemented as Eclipse plugins, it's possible to run them side by side in a single Eclipse installation. However, if you face issues that are clearly related to ABAP (e.g. issues with ABAP debugging), then you should be aware it's an ADT issue and not a HANA Studio issue, even though the program you execute on your PC may be namend HANA Studio. Keep this in mind when writing the ticket, because it reduces the risk that the ticket is routed towards HANA Studio teams instead of ADT teams. Of course SAP first level support knows the above, but it's better if the ticket author is also aware.
- Every information that helps us to narrow down the root cause is very welcome and could potentially speed up the processing of your ticket. For example: Is debugging working with SAP GUI but not with ADT or other way around? Is the issue occurring only for your user or also for other users? Is it occurring only in a certain ABAP system or in multiple? Is it limited to a certain scenario? E.g. debugging of unit tests fails while debugging of reports works. Is it reliably reproducible or only rarely occurring?
C) Endless loop work around
Prerequisites of this work around:
- Code changes are possible
- You have authorizations to change variable values in the ABAP debugger
- You can attach the debugger to a running ABAP process via transaction SM50
Procedure:
Add an endless loop to the source position where you want to stop, e.g.
if sy-uname = 'my_user'.
data(continue_loop) = abap_true.
while continue_loop = abap_true.
endwhile.
endif.
Execute your program/request and find its representation in SM50 (embedded GUI, e.g. via Alt-F8 -> SM50). Select the work process and choose menu 'Administration' -> 'Program' -> 'Debugging'. Once the debugger started up, change the variable value of continue_loop to space and leave the endless loop via F6.
Please ensure to not transport any endless loop into your productive system.
- SAP Managed Tags:
24 Comments
| User | Count |
|---|---|
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
