Hy everybody,
I regulary found statments with BREAK-POINT ID, ASSERT ID and LOG-POINT ID in SAP Standard Code and did some research on these ABAP statements. As i started to understand & use this concept, i found it very handy to debug code with BREAK-POINT ID and ASSERT ID statements. Especially because there are activation variants, that make it easy to control these statements even in larger product or custom developments. I wanted to share my experience with these statements with you and i hope this post is useful to interested people and beginners. As there is surely a lot written about those statements i posted it in my personal blog.
As i learn best with doing examples and test implementations i thougth i would be nice to provide a little demo programm for those statements including a little bit of explantion on their behaviour. So let's get started.
1) Initial configuration of transaction SAAB.
The transaction SAAB is used to create, change or delete Checkpoint Groups. A checkpoint group can be understand as a group of BREAK-POINT ID, ASSERT ID and LOG-POINT Expressions, that are grouped together.
For my exmaple program i created the Checkpoint Group: Z_TEST.
After creation you get the following overview.
At the highlighted spots you can set the settings for the behaviour of the statements BREAK-POINT ID, LOG-POINT ID and ASSERT ID. Be aware, that you have only two option for the assert statement in background processing. Either you log the asserts or you let it dump. If you are in change mode setting up the behaviour, when you click the save button you will be promted to select when the Checkpoint Group is active.
You have these option to activate the checkpoint group: for today, this week or till a specific date.
For my Testprogram & the following screens i've set the following options:
Breakpoint: inactiv
Logpoint: protocol
Assert: protocol
If you have successfully activated the checkpoint group you can see this information below the settings for Breakpoints, Logpoints and Assertions. To check the different behaviours of these options, you can change the settings in transaction SAAB to check out how the different settings behave.
2) Sample Program Code
To explain the checkpoint concept, i'v written a little demo report with following code:
DATA:
lv_a TYPE i VALUE '1',
lv_b TYPE i VALUE '2',
lv_c TYPE i VALUE '3'.
* Break-Point Grps Maintenance TC: SAAB
WRITE / 'BREAK POINT WITH ID z_test'.
WRITE /.
BREAK-POINT ID z_test.
WRITE / 'ASSERTIION SUBKEY subkey1 - Condition is not true, so Assertion is handled as configured in TC SAAB'.
WRITE / 'If the condition is not true, assert can act as a breakpoint, can be just logged, can be ignored or can result in a short dump'.
WRITE / 'ASSERT Statements require configuration for background processing. In background processing there are only the options, that the assert is logged or a short dump is raised'.
WRITE /.
ASSERT ID z_test SUBKEY 'subkey1' FIELDS lv_a lv_b CONDITION lv_a = lv_b."this assert is handled as configured, because condition is not true.
WRITE / 'ASSERTION SUBKEY subkey2 - Condition becomes true, so Assertion is handled as configured in TC SAAB'.
WRITE / 'If the condition is true, an assertion is neither logged nor will the breakpoint start also it will not result in a shortdump if SAAB is configured to abort at assert'.
WRITE /.
lv_b = 1.
ASSERT ID z_test SUBKEY 'subkey2' FIELDS lv_a lv_b CONDITION lv_a = lv_b.
WRITE / 'LOG-POINT ID SUBKEY logpoint1'.
LOG-POINT ID z_test SUBKEY 'logpoint1' FIELDS lv_a lv_b lv_c.
WRITE / 'A LOG-POINT ID statement will only give a log entry in TC SAAB if configured to be logged. Options for Log Points are to be logged or to be ignored'.
If you execute the program, depending on your settings in the checkpoint group, different behaviour may occur. I've described the bevaviour in the code comments and will not repeat it here. I think it's nice to test it out yourself.
3) Check the protocol in transaction SAAB
If you set the settings to protocol these different statements, the log can be found in the transaction SAAB. In the printscreen below, you can see, that the protocol is empty at the moment. With the marked radio buttons you can change the hierarchy in the log. try it out, its pretty much self explaning.
If the protocol is initial, run the demo programm and you can refresh the protocoll view. If you have it implemented correctly you should get a result as shown in the following printscreen.
Now let's hav a look at the protocol:
We see the checkpoint group Z_TEST with the two subkeys set in the coding (logpoint1, subkey1). The entry below logpoint1 is created due to the protocol setting of the LOG-POINT ID statement. The entry below subkey1 is created, because the first ASSERT ID statement in the demo program has a condition lv_a = lv_b - 1 = 2 witch is not true and therefore the ASSERT ID creates an entry in the log. With the fields addition you can pass variable values to the log. I've not checked what kind of variables can be added to log - this is something i will let you explore yourself. To see the details of the variables you passed in the FIELDS addition you can proceed as shown below.
Open the hierarchy to the last leaf and double click on the yellow marked line.
If you double clicked on that line, a screen as the following will appear. On this screen you have different information and i highlighted some of the useful ones for you.
So thats pretty much everything that needs to be explained for using checkpoint groups. I've only one thing left, that i would like to show, activation variants.
4) Activation Variants:
Lets get back to the first screen of transaction SAAB. I've created the activation variant Z_TEST.
You get a screen as following after creation of the checkpoint group.
This is pretty handy, because you can set specific objects and the behaviour of BREAK-POINT ID, LOG-POINT ID, ASSERT ID. Like this, you can for example create a variant that only triggers the checkpoint group for a specific class and so on. This is usefull if you want to check only parts of your developed code. You have also the option tho activate and deactivate the checkpoint group activation variant from this screen. The activation variant can be user specific or generally for the system. I'm sure you will find out how to do the required settings. You also have the possibility to jump into the protocoll of the checkpoint group from this screen.
Summary:
Checkpoint Groups are a nice feature from SAP to group BREAK-POINT ID, LOG-POINT ID and ASSERT ID statements into logical groups. I personally think, its a nice way for a developer to fasten up code analysis within the debugger, as you can group for example main functionality of your development into logical groups. I use them a lot if i have some userspecific selection or code that is critical to ensure proper business functionality. I'm sure you will find ways how to use checkpoint groups in your devopment process. I think checkpoint groups are a developer tool because for business users i would not recomend to show them the checkpoint group protocol - for business users i would prefer the well know application log.
If you have read until here, i would like you to thank you for your attention and hope that you liked the post. Feedback and comments are welcome.
I hope you can work with this post even if the printscreens are in german :smile:
Greetings,
Michael
I wish you all a nice day & have fun with SAP & ABAP.
- SAP Managed Tags:
1 Comment
