Considérez ces phrases :
Un ABAPeur écrit du code
Un ABAPeur malin écrit du code documenté
Un bon ABAPeur malin écrit du code documenté et dont l’état d’exécution peut être vérifié
Un très bon ABAPeur malin écrit du code documenté et dont l’état d’exécution peut être vérifié même en production.

Le langage ABAP est un bon langage. Simple, concis, puissant. Par endroit élégant même.
L’environnement d’exécution aussi. Un bon debugger, des points d’arrêt, …

Pratique, les points d’arrêt. Je me ballade dans mon code, je trouve un endroit intéressant, un petit clique sur ‘STOP’, je lance le programme, et voilà, il s’arrête.
Et si mon programme est super compliqué ? Très long ?
Et si je sais, moi programmeur, que s’il y a des problèmes, ça risque fort d’être juste LA ? Ben je mets un break point. Assez simple. Une instruction ABAP simple : BREAK-POINT.

Si je veux que le break point ne soit actif que pour moi, je fais plus simple. Je fais BREAK WALKER. (BREAK {user} ).

C’est pas mal. Ca m’aide à tomber juste au bon endroit pour debugger mon programme.

Mais je peux aussi faire valider son état. Je peux utiliser les assertions. Si je veux être sûr que l’utilisateur ne saisit pas plus de 1000 lignes dans ma facture (un vieux bug dans les versions anciennes de R/3) je peux écrire quelque chose du genre : ASSERT nb_lignes <>dans le code ABAP, et d’activer le checkpoint associé.

Ceci est possible à l’aide des LOG-POINT. Dans la transaction SAAB, si un programme avec un checkpoint atteint une instruction LOG-POINT, une entrée sera créée dans un log spécifique.

Mais le point fort, c’est qu’on peut aussi écrire dans le log des valeurs de variables :
LOG-POINT ID {checkpoint} FIELDS Field1, Field2, …, FieldN

De cette façon, on peut voir l’évolution de nos variables.

Le seul problème, c’est que, pour économiser l’espace disque, SAP agrège les entrées dans le log pour un seul LOG-POINT – on ne verra que la dernière entrée. Dommage.

Enfin, sauf si on utilise la dernière option de LOG-POINT, l’option SUBKEY. SUBKEY permet de modifier la clé de l’entrée dans la table de log (ce qui bien sûr a pour effet de créer une nouvelle ligne à chaque appel.

Imaginons le code suivant, par exemple :
DO 100 TIMES.
LOG-POINT ID TOTO FIELDS sy-index.
ENDDO.

Dans le log, on verra que le log point a été atteint, 100 fois, et la valeur associée à l’enregistrement sera 100 (la dernière valeur vue).

Si par contre on écrit :
DO 100 TIMES.
LOG-POINT ID TOTO SUBKEY sy-index FIELDS sy-index.
ENDDO.

On aura 100 entrées dans le log.

Dernier point, l’impact sur la performance. SAP nous assure que ces instructions, si le checkpoint n’est pas actif, n’auront AUCUN impact sur la vitesse d’exécution du programme. Pour ma part, je n’ai pas fait de tests…


Warning: getimagesize(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/blog.censio.fr/wp-content/themes/DarlingTemplate/single.php on line 57

Warning: getimagesize(https://france-7e70.kxcdn.com/wp-content/themes/DarlingTemplate/img/tromb/mwalker.png): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/blog.censio.fr/wp-content/themes/DarlingTemplate/single.php on line 57

Laisser un commentaire