====== ABAP Debugging Tips ====== La [[http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2010/11/10/new-abap-debugger-tips-and-tricks|bible]] du debugger ABAP ! ===== Breakpoints ===== (//[[http://help.sap.com/saphelp_nw70/helpdata/EN/c6/617cbee68c11d2b2ab080009b43351/content.htm|Source]]//) ==== Static breakpoints ==== * Instruction ''BREAK-POINT'' : non user-specific. * Instruction ''break '' : 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 '' 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 '''', 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 '''', 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. [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 [[abap:job|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 == [[http://scn.sap.com/people/gajendra.bhakuni/blog/2007/04/23/debugging-outbound-idoc-output-control-scenarios|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_*'' devrait remonter une sélection pas trop mauvaise ( 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. ===== Resources ===== * [[https://www.sap-help.net/Page/]] * [[http://sapignite.com/how-to-debug-sap-rfc-background-job-update-fm-etc/]]