Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Six kinds of debugging tips to find the source code where the message is raised

JerryWang
Advisor
Advisor
‎11-15-2013 5:10 AM




I would like to share with you my debugging tip in my daily life, which makes my life much easier. In case you found your own tip are not listed here, please kindly comment it so that it could benefit more people here :smile:


I will use a simple example to demonstrate. Input an invalid name in SE38 and click display button. An message is displayed in the bottom. I will show you how to find the exact line of code which raises this information.



note: some of the approaches listed here might not be efficient for this very case, I just list all of my tips here for completeness. I do believe each tip could be useful in certain case.



Approach1 - Use "Where Used List" function in ABAP workbench


click on the green icon and we can find message class ID: DS, number 017



SE91, use where use list:



OOPS, so many hits...



Then I have to manually filter them one by one to find the correct one. Double click one by one. I ignore all entries with type MESSAGE E since in my case the message type is not E, but S. After one minute I confirm the following one is the one I try to find.



yes it is confirmed by debugging:



Summary: the drawback of A1 is that as you see, if there are many where used list results say a hundred, it still takes you some time to manually find the correct one.



Approach2 - Use Watch-point to observe sy-msgid in ABAP debugger


type /h in command area, and click display button to trigger debugger.



Create a watch point with below two conditions. After that click F8, the debugger will stop automatically at the correct line you want. This approach just took me 20 seconds to finish the job.



For detailed screenshot about how to create a watch point in Debugger, see picture provided by Jim Tasker:




How to switch into debugging mode for a modal( pop up ) window


Since the command line is not available if there is a modal( pop up window) involved, in this case please refer to SAP Note 118184 about how to switch into debugging mode or refer to this wiki.



Approach3 - Leverage the breakpoint type "ABAP Commands" to debug more efficiently


Launch the debugger just the same as A2, create a dynamic breakpoint with ABAP command = MESSAGE. The debugger will again stops at the correct line.


With this approach again I only spent 20 seconds.



Or you can use menu via Breakpoints->Breakpoint at->Breakpoint at messages to achieve the same result.



Summary: if the scenario you want to debug is quite complex, for example deep callstack with several components involved, the debugger might stops at the ABAP code with MESSAGE keyword frequently. You must still manually check whether the code is just the one you are looking for at each stop. However it is still much more efficient than you debug manually one by one.



Approach4 - source code scan


Tcode SE93, find the package name of SE38:



Then use report RS_ABAP_SOURCE_SCAN and maintain the search criteria below. The reason why I do not use program name RSABAPPROGRAM is that it is just a wrapper report. The actual implementation of SE38 is not put within it.



We only have 4 results.



You can use an alternative tcode CODE_SCANNER which can achieve the same result:




From my point of view, I do like this A4. I can not remember how many times it has helped with my debugging life. What's more, it would be used not only as a debugging tip, but also one way of studying other people's code. Suppose you are curious of how a certain function is implemented by a software component, it is a good starting point to think of a meaningful search keyword and specify the package of that software component and go deep into the result code.



Approach5 - ABAP Runtime Analysis Tool SAT shows its power


tcode SAT, create a new variant, ensure the radio box item "Aggregation - None" is selected.



Then launch the SE38 within SAT by clicking "Execute" button.



repeat your steps as usual - input an non-exist report and click display button to see the message. After that click back or quit button in SE38. SAT will automatically be opened to show you all runtime trace information. It will take some time - you can see the progress information in the bottom:



click tab "Call Hierarchy", click find button. Input Statement = MESSAGE and go. You will see two search results.



double click on the hit list row and then you can see the source code.


Summary: if the scenario you are tracing with SAT is complex, you will get a huge trace file.  Although you can specify an extremely big size in trace file, according to my real experience, you will fail to open the result trace file when it exceeds 1 G, at least in my application server.




Approach6 - Have you used ST05 like this way


First you open SE38, type and invalid program name.


Open a second session, switch on your ST05 with default settings.


Go back to your SE38 window, click display button.


Go back to your ST05 trace, deactivate and display trace result:


We know that the PROGDIR table stores the header information of report. It makes senses for ABAP editor to check whether the program name is valid by search it in that table, doesn't it? So the undoubted next step would be the raise of a message if database search fails. Click the "Display ABAP call location" button to go to the source code:



We see the logic is that first try to search in DB with inactive version, if failed, try with active version.



So hopefully the code we are trying to find is just in the very neighborhood of the SQL statement in line 774 and 779. Fortunately in this case, yes it is in line 813.




Deal with those messages raised in ABAP webdynpro / CRM Webclient UI


If the message is not raised in SAP GUI but from ABAP webdynpro or CRM webclient UI, all of these six approaches still work.


This blog is focusing on how to efficiently locate the source code where the message is raised in CRM Webclient UI environment.



Use SAT to trace web application


The approach 5 has made good use of powerful tool SAT. Please keep in mind that SAT could not only trace the transactions running in SAP GUI but also work for Web application. For more detail please read this nice document Measure Performance and Analyze a Web UI Transaction using SE30 from bhushan.dharmik5.



Other Blogs / Wikis in SCN which could make your debugging more efficient


These blogs / wikis do not talk about the dedicated solution to find message raising location, but contain generic tips which would accelerate your debugging and make your life easier.



Troubleshooting an unfamiliar ABAP issue by Noel Connolly


Three ways to achieve conditional break point in your ABAP program - Asked by my colleagues, so I write it :smile:


How to leverage breakpoint with Exception type - A real example


This tip has actually the similar logic as Approach3, the only difference is another type of ABAP breakpoint is used.

How to efficiently debug in ERP and CRM application


When I am a beginner  in CRM and have to debug CRM business transaction application to resolve ticket reported, I felt really frustrated since although I have used ALL OF THE SIX approaches I described here, still the breakpoint could not be triggered :sad: Finally I realized that just works as designed. I share you with my tips gained through painful debugging in that area and hope they are helpful.

Summary


In my previous work I used to struggle with some tricky case where I don't know how to start my debugging at all. The A6 I call it "ST05 weapon" do prevent me from working over late into the night. Even for the most sophisticated application, I can switch on ST05, repeat the application again, and analyze the trace result to judge which line is useful to start debugging. So I like this overwhelming tool. You may say that it would not help if there is completely no database access for the application to be debugged. Well I would say that would be a rare case at least in my own working area.


Do you have additional tips not included in this article? Please kindly share with us 🙂

56 Comments
Labels in this area
Popular Blog Posts