Does SAP ABAP debugging bug you? Most people are probably used to using the new SAP ABAP debugger, but it does...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
have some limitations. However, usually you can freely switch between the old and new, so you really can have the best of both worlds.
Here are a few tips that are useful for tracking down problems in the ABAP programs.
Setting a breakpoint in the flow logic of a classic SAP Dynpro
When you're debugging in SAP ABAP, you might see code like this:
What you want to do is get to the
Because that's the bit that processes the button you just pressed. But in the new ABAP debugger, if you try to set a breakpoint there, you get the message: "Breakpoints are not (yet) possible in screen debugging". And, despite the "yet", that message has been there a long time.
But this is easily dealt with. Just switch to the classic debugger (Menu option Debugger->Switch to Classic Debugger), and you'll find that you are now able to set breakpoints in the flow-logic).
Finding the available variables
In the new ABAP debugger, you can do this by opening the standard tool "Variable Fast Display" (part of standard desktop 1). This has a tab for local and global variables. Or special tool "Loaded Programs". But you can also find this information in the classic debugger too. Goto-> System Areas-> Internal Information and enter symbdatanm in the Area field. This will show you the names of all available variables.
What's in ABAP Memory?
When you're working in a user exit, you often find that there's some information you need that should be available, but it isn't supplied to the exit. One possibility is that at some point before the user exit, the standard SAP program exported the data you need to memory. But how do you find it?
From the classic ABAP debugger, it's menu option Goto-> System Areas-> ABAP Memory. This lists available memory Ids from where you can IMPORT FROM MEMORY. If you double click on the memory Id, you might get some idea of what's contained in it. The tricky part, is finding out the exact place where the EXPORT TO MEMORY occurred, so you know what data types to use. One way of finding that, is to just search the SAP source code. Or you can set a Breakpoint at Statement (menu option), for the statement EXPORT.
I don't think this is doable from the new debugger. But if anyone can tell me different, I'd be delighted to hear it!
Where is that message being triggered?
I can't remember who told me this one. I wish I could, because it's a really useful trick, that works in both debuggers. The problem is that an error message is triggered, but you can't find out why. You've used the "where-used" for messages in SE91, but it doesn't give anything useful. What you should do is this.
- Run the transaction
- When the message is displayed, look at the long text. This will tell you the message id and message number.
- Take a note of the message Id and number.
- Create a watchpoint on sy-dynnr, so that it will trigger when it has the value of the message number! Make sure the Id is the one you noted, and if it is, you've found the place where the message is first triggered.