Introduction
En tant que développeur Salesforce, on s’est forcément confronté à des cas plus ou moins complexes de recherche de bug dans du code apex. Dans cet article nous allons faire un petit rappel d’un outil qui permet de réaliser le débogage : Apex Replay Debugger.
C’est quoi Apex Replay Debugger ?
Le premier réflexe dans la résolution d’un bug informatique est d’obtenir et d’analyser les logs. Même avec des années d’expérience, il peut s’avérer difficile d’interpréter ces logs, surtout s’il y a plus d’un millier de lignes. Apex Replay Debugger est un outil, ou plus précisément une extension de l’éditeur de code « Visual Studio Code », qui permet d’inspecter les logs pour éviter de les interpréter manuellement. On peut définir des points d’arrêt, afficher et survoler les variables pour voir leur valeur actuelle (plus besoin de remplir le code d’instructions System.debug pour connaître la valeur des variables).
Comment utiliser Apex Replay Debugger ?
Point d’arrêt (Breakpoint)
L’outil va parser un fichier log du début jusqu’à la fin, entre-temps on peut mettre des points d’arrêt à définir sur les lignes de code, le développeur peut inspecter les valeurs des variables à chaque point d’arrêt. Il suffit pour cela de cliquer sur la ligne souhaitée tout à gauche, et un point rouge va apparaître pour marquer le point.
Point de contrôle (Checkpoint)
On peut également mettre des points de contrôle qui sont équivalents aux points d’arrêt mais qui fournissent plus d’informations sur les variables dont les variables de contexte des triggers. Pour définir un point de contrôle, se mettre sur la ligne souhaitée et choisir dans la palette de commande SFDX : Toggle Checkpoint.
Une fois le point de contrôle défini, on peut voir un indicateur sous forme de stop à côté du numéro de la ligne choisie.
Pour finir, il faut notifier Salesforce qu’on a créé des points de contrôle en choisissant la commande dans la palette : SFDX: Update Checkpoints in Org (à relancer à chaque modification de code ou ajout/suppression de point de contrôle)
Lancer le debugger sur un fichier log
Il y a différents moyens de récupérer les logs d’une exécution, par exemple via téléchargement sur developer console, ou via visual studio code avec la commande palette : SFDX: Get Apex Debug Logs. Pour que le log soit analysable par le debugger, il doit être généré avec le niveau de détail FINEST pour code Apex et FINER ou FINEST pour Visualforce. Il faut également s’assurer que l’exécution va passer dans les lignes de code sur lesquels un point d’arrêt ou de contrôle a été mis.
Sur le fichier log ouvert sur Visual Studio Code, faire un clic droit puis SFDX: Launch Apex Replay Debugger with Current File.
Un bar d’outil de debogage va apparaître, et quand on clique sur play 
, l’outil va parser le log jusqu’au prochain point d’arrêt ou de contrôle, on peut alors voir dans le panneau à gauche dans Visual Studio Code les valeurs des variables, mais également en survolant directement la variable dans le code.
Apex replay Debugger VS System.debug
On vient de voir la puissance de l’outil Debugger, on serait même tenter de dire au revoir au fameux « System.debug » qui permet d’écrire dans le journal de log. Mais …, il y a tout de même des cas où mettre un System.debug peut s’avérer bien plus utile. Pour n’en citer que quelques-uns :
- quand une variable contient un String un peu long, ou une collection contenant plusieurs éléments, on perd des informations à cause de troncage ou de non affichage. Un System.debug n’aurait pas eu cette limite sur la taille de String. Il peut aussi afficher tout le contenu d’une collection contenant plusieurs éléments après un « serialize ».
- quand une variable de collection est modifiée, ce n’est pas considéré comme une assignation de variable (VARIABLE_ASSIGNMENT). Par conséquent, la modification ne s’affiche pas dans la section des variables. Ce qui n’est pas très pratique si on veut voir comment la collection a évolué suite à un traitement. Là aussi un System.debug aurait fait l’affaire.
Il y a bien sur d’autres considérations à prendre en compte dans la documentation de Salesforce, n’hésitez pas à le lire.
Pour conclure, Apex Replay Debugger est un outil de débogage puissant qui permet d’analyser les logs plus facilement, et peut être utilisé conjointement avec le System.debug. Si on devait faire une priorisation, ce serait Breakpoint puis Checkpoint et à la fin System.debug.
Si vous avez manqué l’article de Salem, c’est par ici !
