La bible du debugger ABAP !

(Source)

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

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.

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.

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

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.

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.

• 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 !!

• 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.

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).

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

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

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.

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

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).

• 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.

Source

1. 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.
2. 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).
3. Poser des points d'arrêt dans ces FM (peut être fait directement depuis le debugger)
4. 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.

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

• https://www.sap-help.net/Page/
• http://sapignite.com/how-to-debug-sap-rfc-background-job-update-fm-etc/