Un dump vient de tomber sur votre transaction, ou un champ affiche un montant que personne ne s’explique. Comment voir ce que le programme fait vraiment, sans être développeur ? C’est exactement le travail de l’ABAP debugger, et il se pratique très bien en lecture.
Ce guide est écrit pour les consultants fonctionnels : quatre façons d’ouvrir le debugger, l’écran expliqué zone par zone, la navigation F5 à F8, puis les breakpoints et les watchpoints qui répondent à la vraie question : pourquoi cette valeur ?
- L’ABAP debugger se pratique en lecture : analyser un dump, comprendre la valeur d’un champ, suivre un programme existant.
- 4 accès :
SE80(Execute, Debugging),SM37avec la commandejdbg, un breakpoint dans l’éditeur, ou/hdans n’importe quelle transaction. - Navigation au clavier : F5 entre dans le détail, F6 exécute le bloc, F7 remonte, F8 file au prochain arrêt.
- Le breakpoint arrête le programme à un endroit ; le watchpoint l’arrête quand une variable change de valeur.
- En production : on observe, on ne modifie jamais une variable en debug. Reproduisez sur le système de test dès que possible.
À quoi sert l’ABAP debugger quand on n’est pas développeur
Le debugger a la réputation d’un outil de développeur. C’est vrai pour l’écrire, faux pour le lire. Dans la vraie vie de projet, trois situations le rendent indispensable à un profil fonctionnel : un dump à analyser, une valeur de champ inexplicable à tracer, et un programme existant dont personne ne sait plus exactement ce qu’il fait.
Le debugger moderne à deux process est le standard de longue date dans SAP GUI, et c’est lui que nous utilisons ici. Les développeurs travaillent aussi dans Eclipse avec les ABAP Development Tools, mais pour un consultant fonctionnel, le debugger GUI reste l’outil du quotidien : il s’ouvre depuis n’importe quelle transaction, sans installation.
Le dump SAP, votre premier point d’entrée
Commençons par l’écran que tout consultant a croisé : le runtime error, alias dump.
Le dump dit déjà beaucoup : la catégorie d’erreur, le nom du runtime error (ici une division par zéro), l’exception levée et le programme concerné. La section Error analysis raconte même le scénario. Mais le dump dit ce qui s’est passé, pas pourquoi la variable valait zéro à cet instant. C’est là que le debugger prend le relais.
4 façons d’ouvrir l’ABAP debugger
| Accès | Le geste | Quand l’utiliser |
|---|---|---|
/h dans une transaction | Taper /h dans la barre de commande, Entrée, puis dérouler l’action | Le quotidien : déboguer ce que vous êtes en train de faire |
| Breakpoint dans l’éditeur | Clic dans la colonne à gauche du code : un panneau STOP apparaît | Vous savez déjà où regarder dans le programme |
SE80 | Clic droit sur le programme, Execute, puis Debugging | Lancer un programme directement en mode debug |
SM37 + jdbg | Sélectionner un job terminé, taper jdbg dans la barre de commande | Rejouer un job d’arrière-plan pour voir ce qu’il a fait |
Le plus universel est /h : depuis n’importe quelle transaction, tapez-le dans la barre de commande et validez.
SAP confirme par un message discret, et le debugger s’ouvrira à votre prochaine action dans l’écran.
Deuxième accès fréquent : le breakpoint posé directement dans l’éditeur de programme. Un clic dans la colonne beige à gauche du code, un panneau STOP apparaît, et le debugger s’ouvrira à la prochaine exécution qui passe par cette ligne.
Pour lancer un programme entier en debug, passez par SE80 : clic droit sur le programme, Execute, puis Debugging.
Enfin, pour les jobs d’arrière-plan : dans SM37, sélectionnez un job terminé et tapez jdbg dans la barre de commande. SAP simule la réexécution du job en mode debug, précieux pour comprendre ce qu’un traitement de nuit a réellement fait. Le fonctionnement des jobs eux-mêmes mérite un guide dédié : voir la notion de job SAP.
Lire l’écran du debugger : 4 zones et 3 desktops
Le debugger s’ouvre sur un écran dense. Quatre zones suffisent à s’y retrouver.
En haut, les boutons d’exécution (Single Step, Execute, Return, Continue) pilotent l’avancement. Juste en dessous, les onglets Desktop 1 à 3 et Standard proposent des dispositions d’écran différentes des mêmes informations. À droite, la zone des variables. Au centre, le code source, avec une flèche jaune qui marque la position courante : la ligne désignée n’a pas encore été exécutée.
Les desktops méritent un essai : même contenu, dispositions différentes. Choisissez celui qui colle à votre usage et il restera votre écran par défaut.
Naviguer dans le code : F5 à F8 et Goto Statement
Quatre touches portent toute la navigation, et leur logique se retient en une phrase chacune.
- Single Step (F5) : exécute la prochaine opération, puis s’arrête. Si c’est un appel de routine, vous entrez dedans.
- Execute (F6) : exécute la prochaine opération, mais saute par-dessus les blocs. Une routine entière s’exécute d’un coup, sans y entrer.
- Return (F7) : termine le bloc en cours et remonte au code appelant.
- Continue (F8) : file jusqu’au prochain breakpoint ou watchpoint. S’il n’y en a plus, le programme se termine et le debugger se ferme.
En pratique de lecture : F6 pour avancer vite au niveau du programme principal, F5 quand vous voulez voir l’intérieur d’un bloc précis, F7 quand vous y êtes entré par erreur, F8 pour sauter d’un point d’intérêt au suivant.
Pour repositionner la lecture sans tout dérouler, le clic droit propose Goto Statement : le curseur d’exécution se déplace à l’opération choisie.
Suivre une variable : locales et globales
Nous voilà au cœur de l’usage du consultant fonctionnel : pourquoi ce champ a cette valeur. Dans le debugger, un double-clic sur n’importe quelle variable du code l’ajoute à la zone des variables, où sa valeur s’affiche en temps réel à chaque pas d’exécution.
SAP distingue deux familles. Les variables locales ne vivent que dans leur bloc : quand un programme appelle une routine, les variables de la routine n’existent que pendant son exécution, et l’onglet Locals les liste. Les variables globales, elles, sont accessibles partout dans le programme, et l’onglet Globals les regroupe toutes.
Breakpoints : arrêter le programme au bon endroit
Le breakpoint est un point d’arrêt : quel que soit le chemin pris par le programme, l’exécution s’arrête à cet endroit et le debugger vous rend la main. La pose la plus simple : un clic gauche dans la colonne à gauche de la ligne visée, directement pendant le debug.
Le clic droit au même endroit propose les différents types : le session breakpoint vit le temps de votre session de connexion, l’external breakpoint s’arme pour les appels venant de l’extérieur (web, RFC), et le debugger breakpoint ne survit qu’à la session de debug en cours. À cela s’ajoute le breakpoint statique qu’un développeur écrit dans le code lui-même.
Plus puissant encore, le menu Breakpoint at pose des arrêts par catégorie : à chaque occurrence d’une instruction donnée, à l’appel d’une méthode, ou à la levée d’une exception. Ce dernier cas est l’arme absolue pour rejouer un dump : breakpoint at exception, F8, et le debugger s’arrête pile à l’endroit où l’exception naît, comme le détaille la référence officielle des breakpoints et watchpoints.
Watchpoint : surveiller la valeur d’un champ
Le watchpoint inverse la logique : au lieu d’arrêter le programme à un endroit, il l’arrête quand une variable change de valeur. C’est la réponse directe à la question qui ouvre cet article.
-
1Ouvrir la création du watchpoint
Dans le debugger, bouton Watchpoint de la barre d’outils, ou clic droit sur la variable dans le code.
-
2Désigner la variable
Le dialog Create Watchpoint demande la variable à surveiller, sur la variable elle-même ou sur un attribut d’objet.
-
3Affiner si besoin
Une condition libre restreint l’arrêt : par exemple ne s’arrêter que quand la valeur dépasse un seuil donné.
-
4Laisser courir avec F8
Continue (F8) déroule le programme : à chaque modification de la variable, le debugger s’arrête et montre la ligne responsable.
Watchpoint posé sur le champ au montant mystérieux, F8, et le programme s’arrête exactement sur l’instruction qui l’alimente. En quelques minutes, vous savez quelle routine, quelle condition et quelles données ont produit la valeur : exactement ce qu’il faut pour ouvrir un ticket précis ou challenger une spécification, et la même technique sert à analyser un enregistrement SHDB qui se rejoue mal.
Le debugger permet techniquement de modifier la valeur d’une variable en cours d’exécution. Ne le faites jamais sur un système productif : vous fausseriez un traitement réel avec des conséquences imprévisibles. Sur PRD, on observe ; on reproduit ensuite le scénario sur le système de test pour expérimenter. Et certains profils d’autorisation l’interdisent de toute façon.
L’ABAP debugger n’est pas un outil de développeur que les fonctionnels emprunteraient en cachette : c’est l’outil de lecture du système, et il appartient à tous ceux qui doivent comprendre ce que SAP fait réellement. Apprenez les quatre accès, domptez F5 à F8, et gardez le watchpoint pour les grandes énigmes. Pour continuer côté outils du quotidien, le guide des jobs SAP complète naturellement celui-ci, et le parcours public Using ABAP Debugger prolonge le sujet côté officiel.
FAQ : vos questions sur l’ABAP debugger
Comment lancer le debugger SAP avec /h ?
Tapez /h dans la barre de commande de n’importe quelle transaction et validez : SAP affiche « Debugging switched on ». Le debugger s’ouvrira à votre prochaine action dans l’écran (Entrée, clic sur un bouton, validation).
Quelle est la différence entre un breakpoint et un watchpoint ?
Le breakpoint arrête le programme à un endroit précis du code, quel que soit son état. Le watchpoint l’arrête quand une variable surveillée change de valeur, où que cela se produise. Le premier répond à « que se passe-t-il ici ? », le second à « qui modifie cette valeur ? ».
Comment déboguer un job en arrière-plan terminé dans SM37 ?
Dans SM37, sélectionnez le job terminé avec sa case à cocher, tapez jdbg dans la barre de commande et validez. SAP simule la réexécution du job en mode debug, ce qui permet d’analyser pas à pas ce que le traitement a fait.
À quoi servent F5, F6, F7 et F8 dans le debugger ABAP ?
F5 (Single Step) exécute l’opération suivante en entrant dans les blocs ; F6 (Execute) exécute en sautant par-dessus les blocs ; F7 (Return) termine le bloc courant et remonte à l’appelant ; F8 (Continue) déroule jusqu’au prochain breakpoint ou watchpoint, ou jusqu’à la fin du programme.
Quelle différence entre variables locales et globales dans le debugger ?
Les variables locales n’existent que dans leur bloc (une routine, un function module) et ne sont visibles que pendant son exécution, dans l’onglet Locals. Les variables globales sont accessibles partout dans le programme et listées dans l’onglet Globals.
Peut-on utiliser le debugger SAP en production sans risque ?
En lecture, oui, avec les autorisations adéquates. La règle absolue : ne jamais modifier la valeur d’une variable en debug sur un système productif. Pour expérimenter, reproduisez le scénario sur le système de qualité.
À lire ensuite
Job SAP : le guide key user pour SM36, SM37 et le cycle de vie
Comprendre les jobs SAP : cycle de vie en 6 statuts, création propre dans SM36 (start conditions, classes A/B/C), surveillance SM37 et lecture du job log.
Michael A.
SAP Learning Hub : avis, prix et faut-il vraiment payer pour pratiquer ?
SAP Learning Hub vaut-il le coup en 2026 ? Avis produit : éditions actuelles, prix réel, système d'entraînement, certification et validité d'un an, et verdict par profil.
Michael A.
S/4HANA vs ECC : les différences clés pour votre carrière SAP
Quelle différence entre SAP ECC et S/4HANA ? Les différences clés expliquées simplement, le jargon décodé, la fin de maintenance d'ECC et ce que cela change pour votre carrière SAP.
Michael A.
Valorisation séparée SAP MM : concept et configuration
La valorisation séparée dans SAP MM : catégorie contre type, configuration dans OMWC, activation sur la fiche article et impact sur le prix moyen mobile.
Michael A.