Technical Articles
How to start debugging
In this article, I provide an overview of debugging in SAP systems. I discuss the importance of the skills, tools, and intuition needed as well as provide tips for analyzing and collecting relevant information. In essence, I cover all the things I do before setting the first breakpoint in code.
Solving the Complex Puzzle of ERP System
If you had to describe debugging in one sentence, it would be: finding the right line of code to identify the root cause of a program malfunction. However, debugging is much more complex than this, as ERP systems such as SAP consist of many functional modules and client solutions (user exits), as well as interfaces with external systems. A change in one place can often lead to errors in a completely different part of the process, and the issue is not always related to the code. Debugging is akin to detective work, as it requires a broad understanding of both technical and business processes.
An Essential Skill for Stressful Situations
Debugging is often an integral part of the testing process, as it is inevitable that bugs occur during the coding process. However, issues arising from production systems are more critical, as they can cause users to be unable to continue working. These issues, such as those related to logistics and production, can lead to financial losses. This creates a stressful and pressured situation, as the problem must be solved as quickly as possible. In these cases, the ability to debug and resolve the issue rapidly is a vital skill.
Art of Problem-Solving: Tools, Intuition, and Practice
There is never just one way to solve a problem. Each developer or consultant may arrive at the causes through different methods. It is fascinating to observe how other people have entirely different ways of thinking. Knowledge of technical tools such as watchpoints, traces, and breakpoints is essential, but intuition and experience in problem-solving are just as important. This can mainly be acquired through practice. The more problems you solve, the more intuition you will gain over time.
Tips to Help You Analyse and Collect Relevant Information
Debugging each line of code can take a while, so it’s important to take a moment to analyze the problem and collect the most relevant information. Here are some tips that I find helpful:
- Try to understand what process is involved in the problem. What should be the expected results for specific input.
- Identify if the problem is for specific conditions, e.g., it involves a specific business unit or process. If there are logs it can be an ideal tool to analyse such data.
- Reproduce the error. This will allow you to debug new examples. It will probably take a few iterations to find the bug. In addition, if the error can’t be replicated on a test system it may be an indication that the error is in the system settings or involves master data.
- Check program versions and recent changes. Often problems occur after successive transports to production. It’s always a good idea to check for recent changes. They can have an impact on the problem.
- Identify the technical objects associated with the problem. e.g. if we know that the problem occurs only for a particular country it is worth checking from the user exit. For example, if the problem is with creating sales documents, might it be worth starting by finding a BAPI for creating sales orders.
- Break the problem down into smaller, more manageable pieces. This will help to identify and isolate the source of the bug. It can also help to make the debugging process more straightforward, as it reduces the area you need to focus on.
Iterate Your Way to the Right Solution
Good preparation can save us a lot of time when we start debugging the program. It is unlikely that our first guess will be correct. Debugging is an iterative process; in each step, we assume a hypothesis, test its truth, and based on the conclusion, look for the next probable cause until we find the right solution.
Summary
Debugging is the process of finding the root cause of a program malfunction. It requires knowledge of technical tools, as well as intuition and experience in problem-solving. It is important to analyze the problem and gather relevant information before attempting to debug it. Debugging is an iterative process, and the best way to become better at it is with practice. I would love to hear about your experience with debugging preparation. Please share your stories and tips in the comments. If you‘re interested in problem–solving and debugging, be sure to follow my profile. I‘ll be posting more soon!
I would like to add one more trick to the toolset:
In case of an error message, you may start from the message itself (Breakpoint at ... message) and then debug bottom-up (reverse engineering) until finding the root cause behind it.
Funny you mention this, Shai Sinai as it was exactly what I helped colleagues do earlier today when we had an abended job but no dump to go along with it. Only a rather nondescript "Language is not allowed TD 604" message. So, the only thing we knew was that the language was empty, but no indication which sales order was causing this. Via running the relevant program directly and activating debugging with /h and then setting "breakpoint at" for exactly that message, we were able to trace steps back with the call stack to where we could take a look at the currently processed vbap-data. This contained the sales order number and that actually had some data issue with the language not properly filled for one of the partners. Finding and eliminating the root-cause for that will be the next step.
Cheers
Bärbel
@Shai Sinai, Good point!
I think you can also set the breakpoint using an exception class or other points. Debugger tools give us a few possibilities:
I hope there is a sequel "How to stop debugging and get your life back". 🙂 As much as I respect debugging as a helpful tool, in SAP especially it can take anyone on a trip down the rabbit hole. Usually I set some time limit, otherwise it's too easy to spend the whole day in debugger (and it can be a fascinating journey) but then you might not get any solution or even helpful result. If you find yourself debugging for hours, it's time to stop and reconsider.
Yes, I know that feeling too. After some time of debugging, efficiency decreases and it becomes less likely to find the reason. There's no better option than to take a break or set a limit. 😊
Hello Maciej,
a debugging session, which involves setting breakpoints, watchpoints and executing the source code step by step, provides understanding of the dynamic behavior of the source code at runtime with a specific input (variables in the environment/scope).
It is easy to start debugging even without a clear goal. However, it is important to note that the learning journey through the dynamic code behavior can be for understanding and reverse engineering or to identify malfunctions/errors.
To prepare for debugging and finding errors, I gather as much information about the specification as possible. It is common to have code without specification, but without a specification, I cannot determine if the program behavior is correct, if there is a fault, an omission or a surprise (cf. Testing ABAP code). I expect debugging to be time-consuming and open-ended.
best regards,
JNN
Hi Jacques,
Thanks for your comment. I recently was looking for ways to implement memorization in ABAP and I found your post about abap pattern very helpful.
I think there are two distinct approaches to debugging. One is for custom development, which I completely agree with you on - it's a learning journey. The other type is debugging SAP standards. Often this involves following the process in several steps. Sometimes fields are inherited from previous documents, like in the case of FI documents from billing or material movement. In such scenarios, I find it difficult to debug line by line as it's just too much. So, I try to find a specific code, which is relevant. It's often useful to get ABAP or sql trace or use a code scanner to find such possible places.
Best regards,
Maciek