Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at firstname.lastname@example.org.
Recap from last Month
In last month’s blog we discussed why debugging is important for discovering root cause when SAP transactions are behaving badly. We also went through some ways to trigger debugging, and took a look at the debugger screen, navigation and Break-Points.
Debugging for Various Scenarios
This month we will look at one common scenario that may cause you to need the debugger. Let’s start with Standard SAP Messages.
Please understand that for teaching purposes, I am using a VERY SIMPLE example, but the idea behind it applies to more complex transactions as well. Let’s get started!
Your are executing a simple PO Browse using ME23 and you get an error message explaining that the PO you entered does not exist. You are not sure why this message has appeared, and there is no long text available in the message. (see Below)
You want to know why the SAP system has sent this error, so you need to debug the logic for this message. So lets use what we have learned. To activate the debugger enter transaction /h in the command prompt. Go ahead and enter your PO number and press Enter. We will be at the debugging screen (see below)
Now here is where a little ABAP knowledge pays off….
The message you see at the bottom of the screen was created by using the ABAP statement MESSAGE. If you were to have double clicked on the message you would have seen the screen below.
Now I do NOT want to get into teaching ABAP here, but lets look at this a little closer. First notice that I have boxed, in red, the PO number and shown you an “&”. I also split the message number into a Message Class and Message Number, this is to illustrate how the MESSAGE ABAP statement works. Let’s look at the transaction SE91 screen. In the class field put ’06’ and in the number field put ‘019’ and hit display. (see below)
You should see the screen below. Please note that the message looks just like our message, except it has a “&” where our PO number is. Well thats because the “&” is a placeholder and when the ABAP MESSAGE statement is coded by a developer, they substitute the object they are interested in when delivering the user the error.
OK, thats enough ABAP background. We have an error, we are in the debugger, lets continue. We think the error was issued by an ABAP MESSAGE statement. What can we do? Well wait a minute…. in the first blog I demonstrated how to use the menu option BREAKPOINTS=>Breakpoint at=>Breakpoint at Statement to stop (or Break) at the Authority Check ABAP statement. What if we used the same menu path, but entered the ABAP MESSAGE Statement instead. If this was what you were thinking, pat yourself on the back..your are right! See below.
Now hit the green check and the debugger will automatically stop or break whenever the ABAP MESSAGE command is executed. So all we need to do now is use the CONTINUE button or hit F8, and we should stop when our message is being issued. Go ahead and try it. Please note that you may NOT get the error message we care about immediately, you will have to keep hitting F8 until you see the message using our class (06) and number (019). But you will get there… see below
There is our message! OK now what… Well lets back up a few lines and see if we can determine why the developer choose to issue it. Well I can see we have an Open SQL SELECT STATEMENT against the table EKKO using a variable pi_ebeln. Lets take a look and see whats in that variable by double-clicking it. (see below)
That’s the PO number we entered. So maybe, the program tried to read the PO, remember ME23 is the display transaction, and couldn’t find it. Looks like the only way the code will issue the error is if the SY-SUBRC is NOT equal to zero. Thats it, the PO does not exist on table EKKO. Go ahead and hit F8 and you’ll see the transaction completes with the error.
Like I said earlier, this was a REALLY SIMPLE scenario. The concepts and ideas behind using the debugger will work for other scenarios. Now go out there and start debugging!
To read the first part of this Blog series click here Debugging ABAP for Functional Teams – Part 1.
If you would like a complete and detailed look at the SAP Debugger, then please view the prior blogs below. You will be a debugging expert in short order and wow your Functional associates with your skill and prowess!