Debugging SAP ABAP : méthode projet, outils et cas réels

En projet SAP, le debugging n’est pas un exercice scolaire. C’est un outil de résolution rapide, de sécurisation des corrections et de compréhension réelle du standard SAP. En entretien technique, la capacité à diagnostiquer un bug vaut souvent plus qu’un discours théorique.

L’objectif est simple : isoler le point d’entrée, comprendre la valeur qui déclenche l’erreur, et confirmer la solution avec des preuves reproductibles.

Mental model de debug
Symptôme
  |-> Point d’entrée
  |-> Données d’entrée
  |-> Branche de code
  |-> Cause racine
  v
Correction testée

SAP propose le debugger classique et le New Debugger. Le second est la référence en S/4HANA : vues variables plus riches, navigation dans les classes et activation plus stable des breakpoints.

Les breakpoints sont la base. En projet, les bons réflexes sont : choisir le type adapté et le bon utilisateur pour l’exécution.

• Transactions utiles : /h pour activer le debug, /n pour relancer.
• Utiliser les breakpoints conditionnels pour filtrer une clé précise.

Les watchpoints déclenchent le debug lorsqu’une variable change de valeur. Très utile pour traquer un écrasement ou un mapping erroné.

"Exemple de watchpoint
lv_status = 'ERR'.
* Mettre un watchpoint sur lv_status
* Condition: lv_status = 'ERR'

• Mettre le watchpoint sur un champ clé (statut, clé technique).
• Vérifier qui écrit la valeur et à quel moment.

En entretien, on attend une explication claire du choix F5/F6 selon la complexité de la méthode.

Sur un report ou une transaction classique, le plus efficace est de placer un breakpoint au point d’entrée logique (START-OF-SELECTION, PAI, module de fonction clé).

• Limiter les données de test pour réduire la complexité.
• Vérifier les paramètres d’entrée et le sélection screen.
• Isoler les modules fonctionnels critiques via SE37.

Les jobs batch sont un cas récurrent en projet. On utilise SM37 pour retrouver le job, puis SM50 pour attacher le debugger au work process.

Pas-à-pas batch
SM37 -> sélection du job
  |-> Job actif
  |-> SM50 : sélection du WP
  |-> Debugger attaché

• Prévoir un variant de job réduit pour le debug.
• Vérifier les autorisations du user batch.

Les RFC passent souvent par un user technique. Le debug externe est indispensable pour capturer l’appel réel.

• Configurer le breakpoint externe sur l’utilisateur RFC.
• Tester la destination dans SM59 avant de debugger.
• Analyser les inputs dans SE37.

L’IDoc est un flux critique. Le debug se fait souvent au niveau du module de fonction d’inbound ou d’outbound.

Sur Fiori, le debug passe par le service OData. Le breakpoint externe doit viser l’utilisateur front. Le point d’entrée est souvent dans la classe DPC_EXT.

• Vérifier l’appel via /IWFND/MAINT_SERVICE.
• Debug dans la méthode GET_ENTITYSET ou CREATE_ENTITY.
• Valider les logs Gateway si besoin.

L’objectif est d’identifier l’enhancement actif. Le debugger permet de voir la chaîne d’appel et d’isoler l’implémentation.

• Utiliser les points d’arrêt dans les classes BAdI actives.
• Exploiter les outils d’enhancement dans SE80.

Un bug qui n’existe pas en DEV provient souvent de données, autorisations, customizing ou versions de code différentes.

• Comparer les versions transportées.
• Vérifier les autorisations user.
• Comparer la donnée réelle via SE16N.

• Travailler avec un jeu de données minimal.
• Documenter le point d’entrée et la cause racine.
• Supprimer les breakpoints statiques avant livraison.
• Ne pas déboguer en PROD sans accord formel.

• Un bon debug commence par le bon point d’entrée.
• Les breakpoints externes sont essentiels pour RFC/Fiori.
• Les transactions WE* et SM* sont vos alliés au quotidien.