Viewing Logs

Logpoints are commonly used for writing a log entry when the relevant ABAP program reaches a certain point.

Remember The flow of a typical logging process includes the following steps:

In the source code of the program, position the cursor at the code line you wish to analyze in detail.
Set the logpoint at the selected source code line and specify the logpoint parameter.
Run the relevant ABAP program if this has not yet already been done.
Collect the currently available logs from all servers of the system.
View the relevant log entries.

The two simple examples below show how the resulting log entries are to be interpreted.

Example 1: User-Defined Logpoint Properties

Let’s assume that the position to be examined in the program is a DO statement with which squares of numbers are to be issued.

REPORT Z_DEMO_SIMPLE_LP.

DATA square TYPE i.

...

DO 10 TIMES.

  square = ipow( base = sy-index exp = 2 ).
  cl_demo_output=>write( |{ sy-index } { square }| ).

ENDDO.

...

As Activity, we select the option User-Defined Logging, and specify the Key Definition, Field Values and Optional Condition as follows:

Figure 1: User-defined logpoint

Due to the condition defined in the example, the result of the log is limited to two entries, which are represented by the key values [8] and [9]. The results display contains as uppermost node the Generation Time to which the values of the key are assigned (through the variable SY-INDEX). For each key value you have, in turn, the defined Field Values (SY-INDEX and SQUARE), whose results are issued in the Field Value column.

Figure 2: Resulting log entries

Example 2: Using Logpoints for Call Stack Analysis

The following program demonstrates the call of one and the same routine over two different call paths. With this simple example, you learn how these different call paths are mirrored in the log results and how you can use the log information for the call stack analysis.


REPORT Z_DEMO_CALL_STACK.

DO 10 TIMES.

  CASE sy-index.

    WHEN 1.
      PERFORM delegate_call.

    WHEN OTHERS.
      PERFORM do_something.

  ENDCASE.

ENDDO.

FORM do_something.

  MESSAGE 'Subroutine sucessfully executed' TYPE 'S'.
  ENDFORM.

FORM delegate_call.

  PERFORM do_something.

ENDFORM.

As Activity we choose the option Log Call Stacks and add the Optional Condition, as follows, in order to restrict the number of result entries:

Figure 3: Log Call Stacks

As our result we get two different stacks, which represent the different call paths. In the first case (SY-INDEX = 1) 3 stack entries are counted, while for the other values (SY-INDEX > 1) 2 entries are counted. This corresponds exactly to the two call chains for the routine called in the example routine. As we limit the log events to 6 by using the condition SY-INDEX < 7 , we get a maximum number of 6 log events per program execution.

Figure 4: Log entries with 2 different call stacks

Note The prefined activity Log Call Stacks implicitely uses the built-in function STACK_HASH( ) as a key value. As STACK_HASH( ) delivers a different hash values for all different call stacks, only log events with different call stacks are aggregated.

Restriction Much like for static logpoints, the size of each data object stored in one single trace event of dynamic logpoints is limited by the profile parameter abap/aab_log_field_size_limit. The value of the profile parameter specifies the size in bytes. The default value is 1.024 bytes. When a log entry is generated, the content of each data object is truncated when this limit is reached. This restriction affects Field Values in Logpoints of large structures and long strings.