Troubleshooting an unfamiliar ABAP issue

Skip to end of metadata

Created by Noel Connolly, last modified on Sep 05, 2013
Go to start of metadata
Purpose
The purpose of this page is to explain how function module SAPGUI_PROGRESS_INDICATOR can be utilised as a method
to troubleshoot areas you are unfamiliar with.

Overview
A troubleshooter has been defined as a person who locates the cause of trouble and removes or treats it. The SAP system
is vast; this poses a problem for a troubleshooter as it makes it more difficult to pinpoint the cause of trouble.

With experience, a troubleshooter is likely to become familiar with certain code on the SAP system but remain unfamiliar
with other parts. For example, a troubleshooter could be very familiar with the SD availability check functionality and know
exactly the correct locations to set breakpoints to debug & troubleshoot the problem. However, the same troubleshooter may
not be familiar at all with the SD credit management functionality and does not know where to begin regarding a credit
management problem.

The nature of the SAP world means that a troubleshooter could be asked to debug a problem in an area where they are not
familiar with the code. One method of guiding the troubleshooter towards the correct location is to set a breakpoint at
function module SAPGUI_PROGRESS_INDICATOR.

An Example
A troubleshooter with in depth knowledge of SD is asked to troubleshoot a PP issue. Unfortunately, the troubleshooter does
not possess any PP knowledge. The troubleshooter is provided a description of the problem and the steps to reproduce:

Description: When creating a process order, not of all the components are coming into the process order.

Steps to reproduce: Transaction COR1: Enter the material, plant, order type, Quantity and hit enter (See figures 1 & 2). Go
to component overview and you will see only 1 component when there should be 2 (figure 3).
Figure 1: Reproducing the issue (COR1)
Figure 2: In the component overview, there is only 1 component, not 2 as expected
Figure 3: "Copy Master Recipe" in GUI toolbar
Figure 4: "Copy Material List" in GUI toolbar
Figure 5: "Schedule Order" in GUI toolbar

After entering the quantity & pressing enter, the system executes all the relevant code. During this time, it provides the user
with updates on what it is doing. In this example, we see updates such as Copy master recipe, Copy material list for &
Schedule Order (See figures 3, 4 & 5). By looking at these updates, it should be apparent to the troubleshooter when the
problem occurs. In the above example, it is clear the issue does not occur during Schedule Order; instead it is likely it
occurs during Copy material list.

By setting a breakpoint at SAPGUI_PROGRESS_INDICATOR (figure 6), we can get the system to stop at the Copy
material list stage. The system will stop in the call stack somewhere related to the "Copy Material List" stage. See figure 7.
Here, we can see that function CO_SD_RESB_FROM_BOM_CREATE would be a good place to start our troubleshooting.
Figure 6: Set breakpoint at FM SAPGUI_PROGRESS_INDICATOR
Figure 7: The breakpoint will be hit and from the call stack, you should be relatively close to where the problem is located.

The text to be displayed is sent to the import parameter "TEXT".

Conclusion
The advantage of this approach is that it saves the troubleshooter time in searching for relevant code. The
SAPGUI_PROGRESS_INDICATOR breakpoint gives a good indication that the problem is located somewhere around this
code. It prevents the troubleshooter from blindly setting breakpoints at random function modules and hoping for the best.
The above example represents one very specific issue in the SAP system but the logic of setting a breakpoint at FM
SAPGUI_PROGRESS_INDICATOR can be applied across many various scenarios.