22. Step 0:
The right mind
set.
12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 22
23. 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 23
24. Debugging is not
easy!*
*But there are approaches and
practices to help.
12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 24
25. What do you
think / do?
12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 25
Debugging is easy, right? Everybody knows how to do it!
Simply set a break point in your tool of choice, execute the program and you are debugging.
If it is easy why do even seasoned developers getting lost in the debugger, pondering over an issue for hours or days without being close to a solution.
CRM Problem I was working on recently.
Context menu opens up in some search results but not in the agent inbox.
Think about a possible Fiori system architecture, SAP HANA XS in a side by side scenario (taken from help.sap.com)
Different languages (HTML5, ABAP, JavaScript)
Different protocols
Different systems
Different applications
Different frameworks
Different supporting processes
This is only on the highest level.
If I dig deeper in a SAP system (at least the once I currently work with: IS-U and CRM) I usually get the feeling similar to the this comic.
The question is: How to debug effectively:
If we focus on ABAP :
Different approaches for finding the source code where a message is raised
Features of the new ABAP debugger
Debugger variants
Saving parameters for se37 possible to use as test data for unit test?
Conditional break points and Watchpoints
Debugger scripting
ATC
Read on SCN; try out what you read
Similar for other languages
Recently I adopted the habit to reply to questions by colleague with a general response:
Have you already searched on SCN and in the SAP support portal?
In a lot of cases the answer is no.
However, in my opinion searching for hints in SCN and the SAP support portal should be the first step whenever you encounter a complex bug.
Although SAP software is highly customizable and probably no two installations are the same those searches usually result in valuable information.
Even if you won't find the complete solution you will at least get information in which areas the cause of the bug might be. And last, but not least, also an internet search usually turns up some interesting links.
Know how to search on the support portal
Google
First step is normally to reproduce the error in the QA system.
Once I’m able to reproduce the error I won’t start up the debugger immediately. Instead I start to reason about the problem. This I usually organize around some general questions.
What is the business process and the context causing the error? Do I understand the business process?
Without this it might be really difficult to indentifiy a bug
In the case of a dump this is pretty easy.
The details of the dump clearly show what happened and where it happened.
in the case of an error message
Is a long text with detailed explanations is available? Most error massages don't have an detailed description available. But if a detailed description is available it is usually quite helpful.
Even the error messages without detailed descriptions can be very helpful.
Learn the patterns in your application
pattern "...<some key value> not available." or "....<some key value> is not valid." missing customizing.
"The standard address of a business partner can not be deleted" problem in the process flow.
Not necessarily a trivial question
Recall the Fiori architecture diagram
Integrated CRM – ERP scenario
Once the system causing an error is identified, it is important to understand in which layer of the software the error occurs.
each layer has different responsibilities
provide the UI
perform validation checks
access the database)
For example, in a SAP CRM application the error could occur in
the BSP component building the UI,
the BOL layer
the GenIL layer
the underlying APIs.
Understanding on which layer an error occurs helps to take short cuts while debugging.
If the error occurs in the database access layer it's probably a good idea to not perform detailed debugging on the UI layer.
After answering the question mentioned in the previous section I usually have a first idea in which part of the software the error occurs.
navigating through the source code
try to come up with a first assumption what the program code is supposed to do
and which execution path leads to the error.
first assumption what I would expect to see in the debugger
Test my assumptions I have come up with so far.
might not be sensible approach in all cases.
After all the thinking it is time to get to work and start up the debugger. I try to thinks about debugging as performing an experiment.
simply performing the business process that causes the error.
Especially if an error occurs in a complex business process it might be better to find a way to test the assumptions without performing the whole complex process.
execute the "experiment" in order to test the assumptions. This basically is the normal debugging everyone is used to.
If the root cause of the problem is identified during debugging the cycle ends here.
If not, the final step of the cycle is to refine the assumptions based on the insights gained during the debugging. On the basis of the new assumptions we can redesign the experiment and start the cycle over again.
move forward in small increments.
change to many parameters between to debugging sessions very difficult to identify the cause of a different system behaviour.
E.g.error occurs during the address formatting for a business partner.
first test the code for the address formatting with a BP of type person
after that with a BP of type organization with the same address.
This will enable to check if the BP type is part of the formatting problem or not.
In order to decide if to step into a particular function or method or to step over it I use a simple heuristic that has proven very useful for me:
The more individual a function or method is the more likely is it to use <F5>
The more widely used a function or method is the more likely is it to use <F6>.
Using this heuristic basically leads to the following results:
I will almost always inspect custom code using <F5>. the only exception is that I'm sure the function or method is not the cause of the problem.
I will only debug SAP standard code if I wasn't able to identify the root cause of a problem in the custom code.
I will basically never debug widely used standard function modules an methods and instead focus on new ones (e.g. those delivered recently with a new EhP).
As an example consider an error in some SEPA (https://en.wikipedia.org/wiki/Single_Euro_Payments_Area) related functionality.
When debugging this error I would first focus on the custom code around SEPA.
If this doesn't lead to the root cause of the error I would start also debugging SEPA related standard functions and methods.
If I would encounter function modules like BAPI_BUPA_ADDRESS_GETDETAIL or GUID_CREATE in the process I would always step over them using <F6>. These function modules are so common that it is highly unlikely they are the root cause of the problem.
rare cases everything points to a function module or method like e.g. BAPI_BUPA_ADDRESS_GETDETAIL as the root cause of an error.
check the SAP support portal first before debugging these function modules or methods.
As these are widely used for quite some time it is highly unlikely I'm the first one encountering the given problem.
Only if everything else fails I would start debugging those function modules or methods as a last resort.
Different approaches:
Look at the call stack first. Find the enhancements, Z-Implementations
Binary debugging
SAP is not stupid nor mean
What is the underlying reason for some code
fosters better understanding
Most important technique sometimes is to step back