Sometimes it can take hours to figure out a simple error or miscalculation in an SAP program simply because the program is too complex and lengthy. Usually, a standard SAP program calls another program, function module, or subroutine, which then calls another, and so on. Reaching to the exact point of error sometimes becomes very challenging, especially when you don’t receive an error message and you have to find the miscalculation manually.

Using the checkpoint groups, I will take you on a tour of the tools you can use to troubleshoot errors. Let’s first analyze what the breakpoint is and how it can be beneficial.

Use Checkpoint Groups for Breakpoints

If you use BREAK-POINT or BREAK user_name statements in your program, it always stops and enters into debugging mode, even if you don’t want to debug. This creates a hassle for the developers and users, especially in a productive environment. Imagine if a developer wants to analyze a complex scenario in a productive environment using BREAK-POINT. If the developer has to assign BREAK user_name to a different user, then the developer has to change the code and transport it again. Therefore, you can only use breakpoint statements in test mode, and not in productive mode.

With the release of checkpoint groups, SAP has resolved this problem. Now developers can define checkpoint groups and use them in the programs, even in the productive system. You can set checkpoint groups for breakpoints, logpoints, and assertions. Furthermore, you can set the checkpoint groups for breakpoints to inactive or break without changing the ABAP code. Another benefit of checkpoint groups is that you can assign them to any user without amending the code.

To use checkpoint groups, you need to have authorization for transaction SAAB and ABAP debugging. The authorization object the system checks for checkpoint groups is S_DEVELOP with the object type ACID (checkpoint group) and the activities 01 for create, 02 for edit, 03 for display, and 06 for delete.

Many SAP standard programs are now equipped with checkpoint groups. To see available checkpoint groups in a program, enter into debugging mode by entering /h in the command field. Browse to the Break./Watchpoints tab and on this screen go to the Checkpoint Activations tab (Figure 1).

Figure 1

You can view all the checkpoint groups available in the program on the Checkpoint Activations tab

If a developer wants to use a checkpoint group for debugging to analyze an SAP program or process, a developer only needs to assign his user to the checkpoint group and set it to break. To use a checkpoint group, the developer must have debugging authorization with activity type 02 (edit).

Use transaction SAAB to define and maintain checkpoint groups. First, assign a name to the new checkpoint group, such as Z_TEST_GROUP (Figure 2). Click the Add button and a pop-up window appears where you can enter a meaningful description (Figure 3).

Figure 2

Name your new checkpoint group

Figure 3

Add a description for your checkpoint group

Checkpoint groups are transportable repository objects, so you should assign them to a package and a transport request. You should follow standard naming conventions when choosing a title for the checkpoint group (i.e., they must be within the customer namespace and start with Y or Z).

A checkpoint group is called in the ABAP program using the statement BREAK-POINT ID checkpoint_group in which checkpoint_group is the name of the checkpoint group. In my example, this would be BREAK-POINT ID z_test_group.

To set a checkpoint group as break or inactive, in transaction SAAB, click the activation icon. If the checkpoint group is set as break, this means it is active and will break or enter into debugging when the system reaches the BREAK-POINT statement during program execution. Choose Break to make the checkpoint group active (Figure 4).

Figure 4

Set the Breakpoints to Break to activate the checkpoint group

Click the User button to assign users to the checkpoint group. A pop-up window appears in which you can add and delete users (Figure 5). By default, the user who created the checkpoint group is assigned to the group. If you want to add a user, click the add icon in the upper-left corner. A pop-up window appears in which you can enter a valid username. Similarly, to delete a user, place the cursor of on the username and click the remove icon.

Figure 5

Add users to the newly defined checkpoint group

Analyze Background Jobs Using Logpoint

One big disadvantage of using breakpoints is that you cannot use them in background processing. To resolve this issue, SAP introduced logpoints. With the help of a checkpoint group, you can define logpoints in programs. You can store the variable values in a log that you can display through transaction SAAB. 

You define logpoints using the statement LOG-POINT ID checkpoint_group. You can add FIELDS after the statement to store the fields’ values for later analysis (Figure 6).

Figure 6

Logpoint statement with FIELDS addition

To activate the logpoint setting, select Log in the Logpoints section in Figure 4. Whether you execute the program in the foreground or background, the system stores the snapshot at the logpoint. You can then display the stored log on the Log tab in the checkpoint group screen in transaction SAAB (Figure 7).

Figure 7

List of logs generated for a checkpoint group

You can view the list of logs generated for a checkpoint group on the Log tab. The list is sorted by date and time. Double-click the line with a date and time stamp to display logs in which you can examine the variable values at the logpoint (Figure 8).

Figure 8

Log details showing variable values at the point the LOG-POINT statement appears in the program

Use Assertions for Breaking and Logging

Breakpoints and logpoints are unconditional. For example, you cannot make these statements work only when a specific variable is null. Alternatively, assertions are conditional — you can use a logical expression to make it break or log.

Combining assertions with checkpoint groups enables you to analyze a complex scenario in the productive environment. Using the assertion program, you can set breakpoints and logpoints without changing the code.

An assertion statement used with a checkpoint group can perform the following operations:

• Inactive
• Break/Log
• Break/Abort
• Log
• Abort

To use assertion with a checkpoint group, use ASSERT ID in your statement (Figure 9).

Figure 9

Use an assert with a checkpoint group

When you set an assertion as a break in the checkpoint group, the system asks what to do in background processing, for example (Figure 10). You can change this option at any time.

Figure 10

Select the option to use for background processing

With the Log setting in Figure 10, when the system comes across an ASSERT statement in background processing, the system behaves like a conditional logpoint. This means that the system only logs when the condition mentioned with the ASSERT statement is met. The system stores the log for later inspection.

Variable contents at the point of the ASSERT statement are stored as logs. These logs can be helpful for developers because they allow them to analyze programs without issuing an error to the user. The developer can see the background logs through transaction SAAB as mentioned in the logpoint section.

If you set background processing to Abort in Figure 10, the system issues an ABAP dump and stops executing the program. In this case, you can inspect the code through dump analysis. This method is recommended when the developer is doing unit testing. It can also be used if the developer wants to issue an error when a particular condition in the program is not met.  

If an additional field is used with the ASSERT statement, the system shows the first eight field contents in the Error analysis section of the ABAP dump (Figure 11). By viewing the values of these variables, developers can analyze what went wrong. An ABAP dump is helpful for a developer for error analysis as he can know at what point in the program the dump was created. ABAP dumps also contain the values of some system variables at that point in time.

Figure 11

ABAP dump generated when an assertion is failed

By setting the assertions as Log, the system does not break in the foreground and stores the log whenever the condition is successful (Figure 10). Note that you can view a log generated either through the ASSERT or LOG-POINT statement on the Log tab in transaction SAAB.

Storing Activation Using Activation Variants

Using activation variants, you can store and reuse complex, user-specific activation settings. You can access the activation variant through transaction SAAB (Figure 12). The Variant section is available on the main screen in the transaction SAAB. You can set the variant to active or inactive.

Figure 12

Create an activation variant

By clicking the create icon in the Variant section, a number of activation settings become available on the Definition tab of the main screen. As you can see in Figure 13, you can store different variations of checkpoint groups in the activation variant. You can view the logs generated through these variants on the Log tab.

Figure 13

Activation settings available on the Definitions tab

By clicking the copy icon, you can list the checkpoints available in another variant, package, application component, program, class, and function group (Figure 14).

Figure 14

Options available after clicking the copy icon

When you choose the Variant option from the list, the system asks for the variant name (Figure 15). The developer can then choose the checkpoint group and click the OK button to copy the object name to his activation variant (Figure 16). In this way, the developer can copy the objects used in other activation variants, including SAP standard variants. This feature makes variant activation reusable.

Figure 15

After choosing the Variant option, enter the name of the variant

Figure 16

List of development objects and checkpoint groups in the variant

After the developer has copied or defined checkpoint groups in the definition screen, he can activate the variant in Figure 13. Activation settings offer three options: personal activation, activation per user, and activation per server. These options are available by clicking the activate icon in the definition screen as shown in Figure 17. To set the activation variant, users should have authorization object S_DEVELOP with the object type AVAR.

Figure 17

Three types of activation settings

The Personal Activation and Activation per User options activate the checkpoint group based on usernames. If you select Activation per Server, the system lists all the available application servers and activates the checkpoint groups in the variant for the server you choose. If you want to activate the checkpoint group for all users or all servers, use an asterisk (*).

Khalid Sarfaraz

Khalid Sarfaraz has more than seven years of experience as a senior SAP development consultant with companies in Pakistan and the Middle East. He is a certified development consultant for ABAP Workbench and SAP NetWeaver AS 6.20. Khalid has developed and maintained a number of customized reports, forms, screens, and applications with a main focus on performance, reusability, maintenance, and documentation. He also offers expertise in SAP Workflow development and administration.

You may contact the author at khalid.sarfaraz@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.