Debugging for Functional Consultants

[former_member195383]

Introduction to Debugging

SAP consists for various transactions codes and data. Data are stored in the tables and the transaction codes have ABAP programs at the back end. Literal meaning of debugging is ,to make something(a program in current discussion) bug-free. But that is just one aspect of debugging.

Through debugging, we can analyze a program, understand the flow logic and most importantly find out the root cause to any issue .Although Debugging is the obvious task of an ABAP consultant, the debugging knowledge would be of great help to functional consultants. It will save their time for analysis and issue resolution , reduce over-dependence of ABAP team , help in effort estimation.

Let's look at the different aspects of debugging. We will divide the discussion in to the below parts.

1. Programs in SAP ABAP

2. Initiating the Debugging

3. Breakpoints

4. General tips

1. Programs in SAP ABAP

As functional consultants, we deal with many transaction codes and behind each transaction code, there is a ABAP source code. It can be either SAP delivered or customized code, written by ABAP consultant for specific need.

When we execute the program, the control runs through the program and delivers the output. When we debug, the control remains in our hand and runs through the program line by line, thereby allowing us to find out a specific bug, or clarity about a specific logic.

2. Initiating the Debugging

Debugging can be initiated in two ways.

a. Using /h command and executing the transaction.

b. Putting a break-point, at a particular line of the program and executing

the transaction.

As functional consultants , we would be mostly using the 1st option. The 2nd option is used, generally by ABAPers, where they want to see the behavior of a particular section of the code. Let's see examples of each of the above mentioned methods.

Example

a. Using /h command and executing the transactions

Below is the initial screen of a transaction.

First step is to use the command '/h'.

A message will be displayed in the bottom of the screen.

The resulting Screen will be as below.

We can see the current control with the yellow arrow.

• As we press ‘F5’, the control proceeds further.
• If we press F8, two things can happen

          1. If any Break-point is there, the control will directly flow there.(Break-Points have been discussed in more detailed way in coming slides)

          2. If no break-point is there, the debugging will end and the program will get executed.

• As we move along the program, we may encounter, Subroutines/function modules, which are nothing but a piece of code within the program, which take inputs and provide a specific output.
• If we Keep pressing on F5, we will go inside the Subroutines/function modules and go through each line.
• If we have yet not entered Subroutines/function modules , then by pressing F6 , we will skip going through the code piece and the Subroutines/function module will be completely executed.
• If we have entered Subroutines/function modules , then by pressing F7 , we will come out of the code piece and the Subroutines/function module will be completely executed.

b. Putting a break-point, at a particular line of the program and executing the transaction

This can be done by going in to the source code editor (SE38/37 etc.) and putting the break point at the desired line. Cursor can be put on the particular line , at which we need the control to stop and click on the break point button(highlighted in the below screenshot).This will create the breakpoint in the program.

When we execute the program, the control will go to that point and stop.

3. Break-Points

Break-point is the point where the Program execution comes to a halt and from there on we can continue debugging or straight away execute the program , by pressing F8.

There are various ways, through which we can put a break-point in a program . Two mostly used ways are as below.

1. During Debugging the program

2. Before Debugging/Executing the program

Lets discuss about each of the ways.

1. During Debugging of the program

During debugging break point can be put in two ways.

a. Jumping to a specific processing block

This is one of the important methods and by far the most useful for functional consultants.

Generally we tend to debug, when we encounter an error message. In that case, we can put the breakpoint, exactly at the point , where the error originated. And once we execute the program, that will take us straight to that point.

Let's take an example of the current program. It takes the input as an AL11 path. The path must be a valid one. If we put an invalid one, it would ideally end in error. Suppose We encounter such an error, while executing the transaction in question.

Above is the initial screen and upon execution, we got the below error.

1st thing to do after this is double clicking the error message which will give us the message class and the message number In the screen below AD is the message class and 010 is the message number and the message, being in red, indicates that it's an error message.

We start the debugging, by using /h and then, we put this message class and number in the debugging screen as mentioned in the following screenshot.

Now executing the program(F8) will take us to the exact point of error, where we can analyze the reason of the error. In this specific case, the IF statement below says, if the 1st two characters (OFILE_SAVE+0(2)) is not '\\', then issue an error. The input that we provided in the selection screen started with '//' , and hence it resulted in error. That's how, we find out the reason of an error, in this method.

b. Using the stop icon, during debugging

Once the debugging screen appears, breakpoint can be put by using the highlighted breakpoint option.

2. Before Debugging/Executing the program

This can be done by putting a breakpoint in the source code editor (SE38/37 etc.). When we execute the program, the control will go to that point and stop.

In SE38, Cursor can be put on the particular line , at which we need the control to stop and click on the break point button(highlighted in the below screenshot).

Next when we execute the program or transaction, the control stops at this point.

4. General Tips:

Given below are some general tips, suggestions and terminologies involved in debugging.

• Debugging with the new Debugger Opens a new session. Hence , before debugging, ensure that we have enough room for the same, else, automatically the old debugger opens.
• During Debugging, if at any point, we want to see the source-code, we can do so in the following way.

     

• During debugging, we come across select statements, which are nothing but the statements, which fetch data from database table and store in the internal table in the run-time. If we click on the table icon(highlighted in the below screenshot) , It opens up the table in the next window. We can download the table data in an excel format for our analysis.

       

Below are few important parameters and terminologies with respect to debugging.

• SY-SUBRC : It's an indicator, that shows , whether the execution of a “Select statement” , “Function Module”, “Subroutine” , “Method”, is successful or not. When sy-subrc is 0, it indicates that the execution is successful.
• Variable : It’s a temporary storage parameter, that holds a value during the program run-time.
• Constant: As the name suggests, it holds a constant value, which is hard-coded in the program.
• Tables : When the control passes through a select statement, up on successful execution, the table(internal table) gets filled in the run-time.
• Structures : Structure is different than a table. Its just a template, but not a table.

These were some basic information, which can be handy to the functional consultants. Debugging has far more aspects and we can explore more of them, as we continue to be involved in more of debugging. Your comments and suggestions are most welcome.