Breakpoint validity scope, breakpoint activation conflicts and group user debugging in ADT

[Armin_Beil]

This article could be helpful for you if you are an ABAP developer using ABAP Development Tools (ADT) and you experience one of the following scenarios:

• Your ADT breakpoints are decorated with small red crosses and you get messages telling you that there is a breakpoint activation conflict
• You want to debug for a group user (means multiple persons using the same username and password in parallel, e.g. support user or technical group user).
• You switch between ADT and SAPGUI Debugger (with external breakpoints) for the same system, client and username
• You use multiple ADT projects for the same system, client and username in parallel

The intention of this article is to provide a basic understanding about the specialty of these situations and to show what possibilities ADT offers to deal with them. If you have issues with mass requests and you get too many debug sessions in a short time you can directly go to the section "Mass Requests".

ADT Breakpoints and External Requests

When using SAPGUI you have to deal with three different kinds of breakpoints (debugger breakpoints, session breakpoints and external breakpoints). Now with using ADT things become much easier as there is only one kind of breakpoint for all purposes. In ADT you just create a breakpoint and by default it can be used to catch any request for the current user, including external requests like RFC or HTTP.

Once a request hits a breakpoint a new debug session will be started and the project that was used to create the breakpoint will be the owner of this session, regardless where the request was started from.

Activation Conflicts

ADT breakpoints are easy to handle and work well for 95% of all debugging scenarios. But in some cases like the ones mentioned (group user, multiple IDE case, etc.) things are a bit more complicated. In these cases there are multiple ADT projects / IDEs / persons claiming to debug the same requests (identical system, client and user). The question is now which ADT projects becomes the owner of upcoming debug sessions? This is what we call activation conflict.

Remark: Above is mentioned that projects claim their "right to debug" by creating breakpoints. But the debugger should also work in some other situations, e.g. at the statement "break-point". Therefore an ADT Project claims debugging rights already during system logon and conflicts can also occur if no breakpoints are present.

So what's the solution? Who will be the owner of the debug session?

Before NetWeaver 7.50 it is the project that was most recently used to create a breakpoint (or most recently used to execute the menu action "Refresh Breakpoint" / "Refresh Breakpoint Activation").

Starting with NetWeaver 7.50 there is an integrated conflict handling available for these situations that makes conflicts obvious and offers options to deal with it. Additionally there is a new debugger setting that can be used to avoid conflicts completely at the price of a reduced breakpoint validity scope.

Conflict Management

As long as only one ADT project claims debugging rights for a certain set of requests everything is ok. Once a second project also claims debugging rights for the same requests this is recognized and the second project will change its debugging status to "suspended" while the first project stays unaffected. Within suspended projects all breakpoints are immediately decorated with small red crosses and corresponding texts:

Projects in suspended state cannot be used for debugging at all. But it's easy to reactivate debugging within a suspended project, although this will suspend the currently active project in return.

To reactivate a suspended project and suspend the currently active one you can perform one of the following actions:

• Open the context menu on any breakpoint or the vertical bar where you usually place breakpoints and choose "Refresh Breakpoint Activation"

    

        To reactivate debugging for yourself (including suspension of someone else) you have to choose "Continue" on the confirmation popup

    

• Alternatively create a new breakpoint and choose "Continue" on the confirmation popup

The debugger suspension will cause an information popup in the first project:

Now the first project is suspended and therefore offers the chance to reactivate debugging including the suspension of the currently active project (= now the second project).

Currently running debug sessions are not affected. Even if someone else suspends you while you are debugging you can go on as usual. To remember: The above conflicts are regarding the question who will be the owner of newly upcoming debug sessions.

Additionally you will be warned when you are about to change your debug settings in a way that would cause a conflict. For example if you try to debug the requests of one of your colleagues while he is currently working with his user on his own PC / IDE.

Project Debugging Scope

In case you are not interested in external HTTP and RFC requests but only in the requests that are triggered from your own eclipse project (embedded SAP GUI, ABAP Unit) you can also reduce the validity scope of your breakpoints. There will be no more conflicts at all, but you won't be able to debug external HTTP or RFC requests anymore. Additionally nobody else will be able to catch the requests that are fired from your project.

To reduce the breakpoint validity scope you can enter your project properties, navigate to ABAP Development -> Debugand choose "This project only".

Conflicts between ADT and SAPGUI external breakpoints

The conflicts that can occur between SAPGUI and an ADT project are conceptual similar to the conflicts between multiple ADT projects:

But there are also some differences. Once an external breakpoint is created in SAP GUI all active ADT projects that are aiming for the same requests will be suspended. There is no further confirmation popup within SAP GUI. Also vice versa ADT projects do not take SAP GUI external breakpoints into account and suspend them without any further confirmation during the creation of an ADT breakpoint or a similar action (breakpoint refresh, system logon).

The improvement of NW 7.50 compared to lower releases in this case is that you can easily see within ADT that your project has been suspended.

Mass Requests

If you have to debug a code position that is executed very often, like one time per second or even more often, then you probably have the problem of too many debug sessions. This is independent from the above explained conflicts but can also be caused by the work with group users, e.g. if you have a web application that uses a shared technical group user:

In some situations debugging with terminal ID can be useful for this problem. But for tagging HTTP requests with the terminal ID you need to start your browser via the SAP HTTP Plugin for IE (refer to SAP note 1041556), which is also not suitable for some situations.

What you can do instead:

• Use a conditional breakpoint to specify the wanted request(s) more precisely
• Try to create the breakpoint at a code position that will be reached by the wanted request but not by each and every request
• Activate your breakpoint only for the short time when you expect the wanted request and deactivate or delete it when the debug session has been started

Once you have a running debug session for your wanted request it's easy to go on by using soft breakpoints. These can be used like normal breakpoints in running debug sessions but will not start new debug sessions.