ABAP Testing and Troubleshooting ...

With this blog I’d like to share my point of view on definition and usage of checkpoint-groups. I won’t focus on configuration of checkpoints groups nor using with break-points, log-points and assertions, because these topics are widely discussed in SCN.

This is the reporting of what we (my colleague Sergio Ferrari and myself ) found in a productive system of a customer.

Once you read the official documentation and surfed thru’ the various blogs and wiki pages, you would realize the advantage of the adoption of this tool: improvements in the quality of ABAP codes and correctness of programs, etc ...

This is truth, however…with some gaps. Do you want to know why?

The issue…

I have to be honest; until I had a challenging problem with a standard program, I never used checkpoint groups even for self written ABAP applications.

During the last project I had to fix a bad behavior in a very complex standard transaction and this experience made me aware that everything would be much easier if I activated a checkpoint-group.

The problem I had was strange and had all the characteristics of a program’s bug, but instead of requesting the support of the OSS, I made sure that the origin of that issue was due to any customization as an enhancement implementation, an exit routine or even a repair to the standard.

A voice in mind start repeating: “Ok Andrea ... no problem. Just starting from the transaction, get the custom code, activate a break point then check, using the debugger, if the custom code is the cause of the problem …”

It wasn’t so easy!

We mixed data coming from different trace tools generating an accurate list of the custom routines called during the transaction processing ; using this list we activated a lot of break-points (1 break for each custom routine) in order to check that the custom code didn’t influence the normal flow of the standard transaction...

Well, if I set a checkpoint group and added a BREAKPOINT ID statement in all the custom routines, my analysis would be very easy!

Lesson Learned

I spent a lot of time in reading ABAP code and debugging applications and I can assure, that SAP standard code makes a wide use of the checkpoints groups.

In my opinion this is one key to good, robust and efficient programming; very often we are tempted to quickly code a new functionality without looking forward…

Although we wrote one of the most beautiful ABAP program in the world, what could we use in order to analyze the program in case of problems?

Checkpoint group as a standard of custom developments ;-)

Try to look forward and imagine that maybe someone else will have to solve an issue of an application written by us.…

Why don’t we start using the checkpoint groups as a standard?

Beware of the LOG-POINTS

As we already know, the LOG-POINTs can be used to collect the values of some variables in order to allow the developers to analyze their content and solve the problems but… once activated do not forget to turn them off!!!

It can happen that, for any reason, the value of the profile parameter abap/aab_log_field_size_limit has been set to 0 (no restriction) by system administrators (see docu), checkpoints have been activated and an huge amount of collected log records was never cleaned-up.

Once LOG-POINTs are activated, log data are collected in tables SRTM_SUB and SRTM_DATAX; over time, these two tables contain so many records that transactions /nSAAB and /nSRTM became no more useful; any query on checkpoint group logs takes very long runtime and even worst they never end so that it is not possible to delete the logs.

Generally a checkpoint wouldn’t be active for such a long time and create so many entries, but this can happen; we discovered at one customer more than 40 millions of records in table SRTM_SUB.

Unfortunately SAP doesn’t provide a report which would delete such large numbers of entries in batch and the easiest solution would be that the DBA team truncates the two mentioned database tables (SRTM_DATAX and SRTM_SUB).

These tables are used only for checkpoints (trx SAAB) and won't lose any productive data when truncating these tables.

Is everything under control?

One thing that I don’t like in this tool is that once you activate a checkpoint group you must also remember to deactivate it.

Yes it’s real; SAP doesn’t provide a mechanism for automatically deactivate a checkpoint group nor a concept of time validity, especially for the LOG-POINTS.

1. How could I check how many checkpoints groups are active in my system?

The first method is absolutely standard; you can get a list of all the active checkpoints groups directly from the SAAB transaction by selecting the menu: Activation> Display> ALL

However, if you need to perform this simple but useful check as a scheduled background job , I implemented a simple report and code snippet can be found here.

2. How could I delete the active checkpoints groups?

All the checkpoint activation can be deleted from the SAAB transaction by selecting the menu: Activation> Delete> ALL

3. How could I delete the records in the log tables?

The easiest solution would be that the DBA team truncates the SRTM_DATAX and SRTM_SUB tables , but we love abap programming so the following snippet could be useful

Hope this helps ;-)

The Beginning...

The TIP: Editing any table in SAP!!! posted by Kevin Wilson a few days ago about the chance to modify the content of SAP tables using the SE16N transaction reminded me the importance of properly managing these tasks in a productive environment:

System settings (e.g. SCC4/SE06)
Permissions to perform certain actions and / or transactions.

Just to stay on the subject, I would like to share with the great SDN community a pearl which is based upon one of the peculiarities introduced by the new ABAP debugger.

My colleague Sandro Garofano (he's really a PI Guru) asked me: <<Hey Andrea, can you change the variable SY-UNAME while debugging?>>

Knowing the classic debugger and imagining to have the same behavior even with the new one, I answered with no doubt: <<Absolutely NOT!>>

Sandro then closed the conversation by adding: <<... Anyway, we did a test; if you change the content of the system variable sy-uname, the new debugger maintains the value ... Try it!>>

Later that Day: The test

In order to create the test case in my trial system I tried to display the users that have changed the field net weight of a particular material.

The first thing I did was identify a material code in the material master

then I've created a simple ABAP report which uses the Bapi method BAPI_MATERIAL_SAVEREPLICA in order to change the net weight value of the material.

In the ABAP program, I used a static BREAK-POINT statement, which activated the debugger immediately before the execution of the BAPI method and this, allowed me to change the value of the field SY-UNAME. Of course the new debugger was activated.

The value of the system field SY-UNAME that I replaced while debugging was not restored by the system as shown by the following program log ...

..and the result is that the user SPIDERMAN changed the material!

Now we have two options:

The first is that SPIDERMAN really exists and he logged on the system just to change the material, once heroes had something more important to take care of...
The second one , the ABAP debugger was changed and SPIDERMAN is still busy with other stuffs

Later that day, too much later: another test

I was still wondering about SPIDERMAN in the night and I couldn't sleep.

So I connected to the same system and performed the same test but this time I used the classical debugger, but now, as supposed, the change was registered with my user-id because the replacement of the system fields was not allowed

In fact, with the old debugger, the system resets the value immediately after pressing the key F5 (Single Step Key) and before the execution of the following statement.

So the execution log of the sample program looked like:

and this time SPIDERMAN was not able to change the material!

So the old debugger behavior didn't allow SPIDERMAN to edit the material or just SPIDERMAN was taking care of some enemies during the night?

The question

The morning after, waking up as a SAP consultant, my first question was: shall the behavior of the new debugger be considered as a new feature or is it a bug in the debugger?

Important aspects of the kernel and differences in behavior between the new and the classical debugger

The SYST fields are not write protected, so it's possible to change their value either in the debugger or by a corresponding ABAP statement in an application .

The second chance is less worrying; in ABAP you could make a good MOVE ‘GOBLIN' TO SY-UNAME with the same effect, but this action requires changes to the program, the creation of a transport request and then an import into the productive system.

However the system fields SYST are reset by the kernel when a screen change happens ad this is the major reason for the difference in behavior between the new and the old debugger.

The old debugger runs in the same process as the application, and the debugger screens are inserted between the application screens; so any debugger step involves a screen change which resets the SYST fields and this is the reason why SY-UNAME reverts to its old value in the old debugger.

The new debugger,instead, is a two-process debugger. This means that debugger steps do not involve a screen change in the application which is under debugger control. Therefore the SYST fields are not being reset.

Security Risk

From a security point of view, replacing the value of the field SY-UNAME didn't give me the authorizations of the new person, because the roles are cached in memory and the authority-checks continue to fire against this cache of true identity; this means that I'll never have the SPIDERMAN's superpowers :-(

The only possible risk is that an audit trail could be altered by this way of replacing the system field SY-UNAME while debugging, so SPIDERMAN could results as a real employee...

Lesson learned:

As for the open source , the software is more secure if there are fewer secrets. So It is important to take the necessary precautions.

Due to the fact that with the new debugger, changed system variables are not restored, functionalities like SE16N are even more dangerous and it's more and more important to disable them in any productive environment.

Unfortunately this is not always true so, as SPIDERMAN knows very well, with great power comes great responsibility...

Special thanks:

I would like to thank my colleague @ Techedge Sergio Cipolla for supporting the idea and for giving me the passion to blog on SDN