Disclaimer: Same as with most of my other blogs this one is meant for beginners. If you`re are an experienced professional, please add your comments and tips and tricks too. It can be that I still have lots to learn and I can learn something cool from you now. Happy debugging!
This is the fourth part of my “SAP standard” blog series (first one, second one, third one). Except the third one which is about demos and not “real productive parts of the standard” these blogs target the SAP standard code reusability. In one of the previous parts in the comments section I promised to share some of my debugging tips and tricks. I don`t pretend they`re super advanced, but as usual – I hope they will help at least a few.
Before you start debugging
Today we will target debugging as the way of getting what you want (to be able to reuse it). If you want to reuse something from the standard, the most important things are to know: a)how it is implemented in the standard and b) where it is used. That sounds obvious. But some people taught me to remind that often.
Give well described tasks only… (…and accept these only)
When you give somebody a task to build something in SAP, you should be asked how it is different from the standard. If that question does not come immediately, please tell the person the motivation, because it means a) he or she didn`t understand the task and/or b) he is not experienced enough to realize that although it is supposed to be different from the SAP standard, you first need to learn about the standard before you can build something like “SAP standard minus XYZ (when you need to skip a step or two) or plus ABC (when you need to add an extra step)”.
In case of working with a ABAP youngster, it will spare the person lots of effort and time, because at the end he or she would anyway come to a conclusion that the produced code is just like the function module ABC or transaction XYZ (and then the person starts reviewing the standard and removing those parts of the coding that can be replaced by a simple call of a standard function module or with a help of a standard class etc. Then the time and effort (and money) is lost. That person might also start complaining “Why didn`t you tell me at the beginning?”). So if you learn to emphasize the standard solution and it`s different from the newly required application, you will spare everybody lots of unpleasant moments.
Give the starting point
So now it is clear why we need it. That means that there is something we would like to use, but we can`t. So now we have to review what`s that thing that`s “almost what we need” to find out how to spare us as much effort as possible.
If you`re giving a task, always give a starting point. Name a transaction. Name a function module. Give something. If you`re given a task, always check you know enough to know where to start. Often transaction is not enough. Often you need something like “do what the button A in transaction X does, but do it en masse please” (typical example from my experience).
Your first move (and often the right “solution”) should be going to that transaction, preparing some input and (now IMPORTANT for newcomers starts here!!!) put “/h” into the OK-CODE field (where you normally put the transaction code). Success message saying “Debugging switched on” should appear at the bottom of your window. It means that everything you do from now on will start a debugger.
Now we are in the debugger. I don`t have any special tricks here, except using F6 instead of F5 in most cases. If you know that the call that is about to be done is not the thing you`re looking for, why would you bother to “step into” and debug it? You can just “step over” and carry on. You often don`t know if you can hit F6. Then I see I have two options.
Option a) guess it out based on the “processing block” name – example: if you`re unsure if you need to debug a function module call, you`re interested in creating an item, but the function module name says something about “check”, then you can ignore it. Option b) is to use F6 as often as possible and when you know you`re too far, start over and don`t use F6 for last couple of processing blocks (function module calls or MODULEs in screen processing).
I forgot to point out an important thing. If you`re giving the task to a newbie, it`s very probable that you know what data to put into the screen to make the button (like in the example scenario above) work. The person getting the task can be so confused by everything being new (that was often the case for me, I can admit it and would like to warn you about it) that he/she just forgets to ask you for an example input. Give the person the example input. Often it is two minutes delay for you, but can be two days of trying for the newbie (I experienced all this, I am not exaggerating here…much).
In the debugger
While in the debugger you can stick to your own ways, ask your colleagues, anything. My trick is to use two things: notepad and call-stack.
The first one is not a special debugger feature it is the Windows standard notepad. Every time I see something potentially useful, I copy the call to the notepad (often including the variables with values – I click on every variable going into the call so I can see it on the right in the format variable + value and using CTRL+Z I select everything and coy it into the notepad application).
It is very fast. Plus… it has one more benefit. If you went too far with your debugging and have to start over, you would like to be able to skip the parts which were irrelevant to your task. Then I check my notepads (often multiple of them, one for each call or one for each “phase” of processing) and look for function modules (typically) where I can put breakpoints and after I restart the debugger, I can safely hit F8 – go and land in the function module with the debugger and start from there.
The second trick is to follow the call stack. Not all the time. But when you find the part of the code relevant to your task, a candidate for being reused, you need to learn how much you can reuse. You follow the variables` values and when they match your expectation, you`re often lost deep in FORMs etc. Then checking the call-stack can tell you things like “what is the nearest function module or method call”, because these are typical candidates for being reused. Yes, one can (sometimes, rarely) reuse things on FORM level, but hand on heart, how many people really do it? It is not very safe, stable, good for future maintenance and support etc.
You can click entries in the call stack and the debugger takes to the location where that call was made PLUS what are the values of the variables. That can tell you a lot, if this is the right part of the code to be reused PLUS when you copy that part of the code (really reuse it in your code) you need to know how to call it. You need to know what the right values for the call are (or at least what type of value fits).
Getting to know the data types
Before I end this blog, there are two more things that are helpful. One thing is know the data types of the information being processed in the code you`re debugging. In the debugger that information is not always nicely visible. Then I use the include name in the top part of the debugger window, navigate to the code outside the debugger and can navigate using “clicks”. Click on the variable name to jump to the declaration. Click on the FORM keyword to see where is this thing being called from (and what are the parameters). And you can use search (here learn to use “In main program” option instead of “In program”, since it gives you – well, it gives me – better results, more aligned with my needs and expectations).
Debugging without OK-CODE available
One often needs to debug something being started from a popup screen. Then you don’t have the access to the OK-CODE to say “/h”. But there is again an easy way around it. Pick a field in the dialog. Hit F1 and click on technical info. That will tell you the name and type of the field PLUS the number of the screen. Then you can jump to the screen and its modules and put your break point there. While jumping to the modules you often see the section handling the f_code (function code of the button) immediately so you might be able to spot what you need directly here.
Well, the blog got little longer than expected, but I needed to tell my story from A to Z. Hope you arrived here safely, learnt something useful or formulated your objections. Also hope you don`t regret the time.
Cheers Otto
- SAP Managed Tags:
7 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
