ABAP Debugging Tips

ABAP Debugging Tips

La bible du debugger ABAP !

Breakpoints

Static breakpoints

Instruction BREAK-POINT : non user-specific.
Instruction break <username> : user-specific.

Dynamic breakpoints

Persistance des breakpoints

Les breakpoints dynamiques disparaissent dans tous les cas en fin de session. Ils sont également nettoyés en général en fin de transaction. Cependant, ils peuvent être enregistrés : clic sur le bouton Save du debugger. Ils persistent alors jusqu'en fin de session.

Effets

Les breakpoints dynamiques interrompent en général l'exécution du programme avant l'instruction sur laquelle ils sont placés, sauf dans le cas des exceptions. Dans ce cas là, ils arrêtent l'exécution après que l'exception soit levée.

Groupes de contrôle

En utilisant l'option ID <group> sur les instructions BREAK-POINT, ASSERT ou LOG-POINT on en contrôle l'activation via la SAAB.

Logging

Il est possible de logger dans un but de debug grâce aux 3 instructions.

```
BREAK-POINT log_text.
```
Va logger log_text en SM21. (NB : log_text doit être de type C, de longueur 40 max.)
ASSERT et LOG-POINT vont logger dans le journal SAAB si le groupe a activé le logging pour chaque instruction.

Sauter des itérations

Il est possible de sauter n itérations d'un break-point dans le debugger (onglet break-point). Cela peut-être utile sur un break-point localisé dans une loop.

Practical debugging

Debugger tips

Revenir en arrière (new debugger only) : placer le curseur sur la ligne souhaitée et tapper [Shift + F12].
Placer des breakpoints sur des types d'instruction (statement, CALL FUNCTION, exception, etc) : dans le debugger, menu Breakpoints > Breakpoint at.
Placer un breakpoint en graphique : double-clic sur la ligne (mais en dehors des instructions).
Pour modifier une valeur de variable dans l'ancien debugger, modifier la valeur puis, ne surtout pas appuyer sur <enter>, mais cliquer sur le petit bouton Edit à côté du champs !!

Commandes

F5 : exécute l'instruction courante et passe à l'instruction suivante (dans les boucles, l'exécution repasse toujours une dernière fois sur l'instruction du bloc avant de sortir), entre dans les sous-instructions.
F6 : exécute l'instruction courante et passe à l'instruction suivante, n'entre pas dans les sous-instructions.
F7 : exécute toutes les instructions restantes du bloc courant, s'arrête à la fin du bloc courant.
F8 : exécute toutes les instructions jusqu'au break-point suivant ou à la fin de l'exécution.

Activation du debug

/h

Le debug s'active de façon classique en client lourd via la commande /h dans le transaction prompt avant d'exécuter du code (F8, appui sur un bouton, envoi de <enter>, etc).

Breakpoint

Lorsque le noyau SAP rencontre un breakpoint (qu'il soit statique ou dynamique), il ouvre spontanément la fenêtre de debug.

Drag'n'drop

En drag'n'dropant un fichier texte spécifique (ci-dessous) dans une fenêtre SAP, on active le mode debug. Cela est très pratique pour les fenêtres qui n'ont pas de transaction prompt comme les popups par exemple.

debug.ini

[FUNCTION]
Command=/H
Title=Debugger
Type=SystemCommand

Debug de background process (job)

Le debugger n'agît que sur le process courant. Il ne rentrera pas dans les instructions qui vont s'exécuter dans un process différent (typiquement : un job submit). Pour debugger de tels jobs, exécuter le programme jusqu'au job submit, mais s'arrêter avant (sur) le job close. A ce niveau, se rendre en SM37, sélectionner le job plannifié voulu et entrer la commande jdbg dans le command prompt.

Debug de background process (SE38)

Pour débugger un programme lancé en background depuis la SE38, poser un breakpoint dans le form (LBTCHENQ)DEQ_JOB.

Debug de fonctions RFC

Une astuce pour debugger un appel de fonction RFC :

Ajouter une boucle infinie dans le module fonction. Ex :

DATA indx TYPE i VALUE 0.
WHILE indx < 1.
ENDWHILE.

Cela permet de récupérer le process dialog correspondant en SM50. Le sélectionner dans la liste et cliquer sur Program/Session → Program → Debugging.
Il ne reste plus qu'à sortir de la boucle pour continuer le debug (passer indx à une valeur > 0).

Debug de background (via enhancement)

Implémenter et activer un enhancement infini (exemple ci-dessous) à l'endroit souhaité.
```
data x.
while x is initial.
endwhile.
```
Récupérer l'exécution en BTC en SM50 pour débugger.

Debug d'objets particuliers

Génération d'idocs par Output Message

Source

Créer (par répétition ou sur un nouveau cas de test) un nouvel output message mais en modifiant les condition records afin de ne pas l'envoyer immédiatement (4) : en choisissant l'option 1.
Récupérer le ou les FM suceptibles de générer l'idoc désiré (un F4 en SE37 sur IDOC_OUTPUT_<message_type>* devrait remonter une sélection pas trop mauvaise (<message_type> est le type de message comme dans le partner profile / outbound parameters).
Poser des points d'arrêt dans ces FM (peut être fait directement depuis le debugger)
Lancer le programme RSNAST00 en débug en précisant les bons paramètres afin de choper le message que l'on vient de créer.

Détecter le mode débug en ABAP

TABLES: abdbg.
IF abdbg-srepid IS NOT INITIAL.
  " Gotcha!
ENDIF.

Table of Contents