Go-lives are a classic time where you would be encountering bugs at a very steady pace. Some bugs would be pretty straight forward where clarity on the feature would solve it, some would need a simple code fix, some would be an algorithm issue, some would be performance issue but there is a class of bug which would make you toil, tease and then push you to the limit. For e.g. the value of the variable changes unexpectedly in a process remotely linked to it. (We faced this situation actually where the workflow changed the status of a quotation and we were at our wits end to find the root cause of this).
When such a problem occurs, it is very interesting how different people react to this. Some people rerun the application many times to actually see if the problem occurs every time, some believe this problem could be because of system issue or configuration without verifying; some just throw in the towel. It is not something which is a figment of my imagination but it is very surprising as people fail to utilize the capabilities of the debugger and debugging tactics. This is because of art of debugging could not be taught and people are not sure whether they can for sure solve the issue using debugging.
Some of the keys aspects to debugging are
- Check if the problem is reproducible. If it occurs for some users or only a class of users, then usual suspect could be an authorization, roles etc. But if the problem occurs for all class of users then anyone can reproduce it for analysis. Make sure that you have asked the reporter of the problem, the steps to reproduce the problem. This is helps in recreating the problem on your end.
- Don’t be daunted by the problem. If you are looking a real landscape there could be at least 4-5 systems, their UIs, middlewares connecting them. It is very easy to get lost in the details. But if the problem occurs for e.g. when data is passed between two views in a UI then all the other systems are out of scope. Or if there is a problem in data exchange through middleware, then the scope of the problem is reduced to two systems and middleware.
- Analyse the problem and decide on the areas which you can safely remove from your list of debugging. This process is very important as you can’t debug the whole system. For e.g. you can safely assume in the first pass, that the SAP delivered code doesn’t play the truant. This would help you reduce the effort of debugging. Mind it I never said that SAP delivered code does not have error. What I am trying to point out is that you have cut down the amount of code you would debug.
- Now you must go on debugging trying to form a hypothesis as to what could be the possible reason for the error. This is must as you would have to come to some conclusion later but what should be the path that you would follow to reach that conclusion. Some of the possible hypothesis could be a system issue/configuration issue, table maintenance error etc.
- Once you have formed a hypothesis as to where this problem could be, the next logical step would be to validate your hypothesis. For e.g. if you believe that the problem occurs in SAP standard code after Step B) you can move forward debugging only the SAP standard code and this would either validate your hypothesis or invalidate it. Building and validating the hypothesis are the essential phases of debugging. Very often this is a make or break phase.
- If you have validated your hypothesis, it turns into theory. Well Done. But have you reached the solution? Not yet. So you have to think in terms of that. Sometimes it is easier to find a solution but sometimes it is difficult to figure it out. Depending on the case, we have to put forward a solution which can fix the problem without causing any regressions.
SAP provides a strong debugging environment. Currently there are two versions of abap debugger: Classical for release earlier than 6.40 and New available as of release 6.40.The abap debugger could be started by command /h or /hex(for system debugging) or by placing session or external breakpoints. The session breakpoints are generally are set in main session and are not effective once the session is closed. The external breakpoints are stored in database and available for 2 hours for all sessions which the users open in the application server. There is an enormous amount of documentation available on the new debugger. (I have not attached the screenshots as everything is available on them).
Apart from the breakpoints, the new debugger allows you to set watch points on specific variables. Whenever the value of the variable is changed, the debugger stops at that point unlike the breakpoint where the debugger stops at a particular line. For e.g. you have a message container, in which a new error message is added. You need to find out where the error message is added. A watchpoint would cause the debugger to stop when the error message is added to the message container. Alternatively if you know the Message class, Message no and the message type (Error/Information etc.), you can directly use the Breakpoint at Message feature in the debugger. The debugger would stop at the place where the message occurs.
The debugger offers new features such as you can specify the keywords in ABAP and the breakpoint would be automatically set for all the places where this key word occurs. There are some advanced features which ABAP debugger such as scripting. Check them out in the ABAP articles section.
I would illustrate some common debugging techniques and how they can be used in ABAP debugging:
- Print Debugging: This is to generate logs which would help you to understand the problem. SAP does the same for you via ST22 during the dumps and ST05 for database tracing (There are many transactions). The ST22 tools provide rich information on tacking the dumps.
- Remote Debugging: If you have CRM system for order creation and ERP for order processing, then very frequently you have to use remote debugging. In this case you have to use the external breakpoints. Some times there is a problem with remote debugging so you have use SRDEBUG to activate and deactivate remote debugging. Be cautious while remote debugging as if you press F8 instead of F6/F5 you would come out application.
- Brute Force Debugging: You expect the value of a variable to be different than actually what it should occur. You can forcefully change the value of the variable in the debugger. For e.g. if you don't have an authorizationfor a particular transaction, then you can either forcefully change the sy-subrc values in the debugger after Authorization checks or Use Shift F12 to jump to the statement which would allow you to jump to the desired statement avoiding authorization checks.
If you are debugging object oriented ABAP, the new debugger comes very handy. You can drill down to individual instance variables, if the instance variables are also references you can further drill down to check the values of their instance variables. CRM developers would have appreciated this feature during their work.
To conclude, the debugger and the debugging techniques can ease your life. It is upto to individuals how they educate themselves with these techniques.
