Débogage de flux Architect : mode debug et logs.

1. Le mode "Debug" : Tester votre flux en direct

La première méthode, la plus simple, est une sorte de "test en direct". Elle vous permet d'appeler une version non publiée de votre flux pour l'entendre et l'expérimenter comme le ferait un client, avec en plus des informations de débogage audio.

Pour activer ce mode, il suffit de suivre quelques étapes.

Pour résumer le processus :

1. Ouvrez le flux que vous souhaitez tester dans Architect.
2. Assurez-vous qu'il n'y a pas d'erreurs de validation.
3. Dans le menu Publish, cliquez sur Debug.
4. Une boîte de dialogue confirmera que le mode debug est activé et vous fournira une adresse SIP, par exemple sip:Mon%20Flux%20Principal-debug@localhost.
5. Depuis votre client Genesys Cloud (WebRTC ou téléphone physique), passez un appel vers cette adresse SIP.

Lorsque vous appelez ce flux, vous entendrez non seulement les messages audio que vous avez configurés, mais aussi des annonces système (en anglais) qui décrivent ce que le flux est en train de faire. Par exemple : "Now executing action: Play Audio" ou "Evaluating decision. Result is: true". C'est un excellent moyen de repérer rapidement une erreur de branchement évidente.

Cas d'usage typique : Vous avez une action Switch qui doit diriger l'appelant en fonction de son choix DTMF (1, 2 ou 3). L'appelant appuie sur 2, mais atterrit sur la sortie par défaut. Le mode Debug vous annoncera peut-être : "Switch input value is 'not set'. Taking default path.". Vous saurez alors que la variable qui devait contenir le choix de l'appelant n'a pas été correctement capturée à l'étape précédente.

2. Le mode "Replay" : Décortiquer une exécution passée

Si le mode Debug est utile pour des tests rapides, le mode Replay est l'outil de choix pour les diagnostics complexes et détaillés. Il vous permet de "rejouer" l'exécution d'une interaction passée, étape par étape, en inspectant l'état de toutes vos variables à chaque instant. C'est comme avoir un enregistreur vidéo de l'exécution de votre logique.

Vous accédez généralement au mode Replay depuis la vue des détails d'une interaction (que nous avons explorée dans les leçons précédentes). Pour les interactions qui ont traversé un flux Architect, un lien est souvent disponible pour "rejouer" l'exécution du flux.

La maîtrise de cet outil passe par la compréhension de ses trois composantes principales.

Les contrôles de relecture

Au bas de l'écran, vous trouverez une barre d'outils similaire à un débogueur de code :

• Play/Pause : Rejoue l'exécution automatiquement.
• Step Over : Exécute l'action en surbrillance et passe à la suivante sans entrer dans les détails internes de l'action. C'est le bouton que vous utiliserez le plus souvent.
• Step In : Si l'action est une tâche réutilisable (Common Module), cela vous permet d'entrer à l'intérieur de cette tâche pour en suivre l'exécution.
• Step Out : Si vous êtes à l'intérieur d'une tâche, cela termine son exécution et vous ramène au flux principal.
• Breakpoints : Vous pouvez placer des points d'arrêt sur des actions spécifiques. La relecture s'arrêtera automatiquement lorsqu'elle atteindra un breakpoint, ce qui est très utile pour les flux longs et complexes.

Le panneau de données (Data Panel)

C'est sans doute la partie la plus importante du mode Replay. Ce panneau, généralement situé sur le côté, vous montre la valeur de toutes les variables du flux à l'étape d'exécution actuelle.

• Flow.variableName
• Task.variableName
• Call.Language, Call.Ani, etc.

C'est ici que vous trouverez la "boîte noire" de votre flux. Si une action Decision prend le mauvais chemin, vous pouvez vous arrêter juste avant, inspecter la variable qu'elle évalue dans le Data Panel, et comprendre instantanément pourquoi elle a pris cette décision.

Le niveau des données d'exécution

Un point crucial mentionné dans la documentation : la quantité de détails que vous pouvez voir dépend du niveau de journalisation des données d'exécution configuré pour le flux.

• Base : Le niveau par défaut. Il conserve le chemin d'exécution mais pas les valeurs des variables.
• Detailed ou Full : Ces niveaux conservent les valeurs des variables et sont nécessaires pour un débogage efficace.

Si vous entrez en mode Replay et que vous ne voyez aucune valeur dans le panneau de données, c'est probablement que le niveau de journalisation du flux était sur "Base" au moment de l'interaction. Vous pouvez le modifier dans les paramètres du flux pour les futures exécutions.

3. Scénario de débogage concret

Mettons ces connaissances en pratique avec un scénario courant.

Problème : Vous avez un flux qui utilise une action Evaluate Schedule pour vérifier les heures d'ouverture. Si le centre est ouvert, l'appel est transféré à la file "Ventes". Si c'est fermé, il va vers une messagerie vocale. Plusieurs clients se plaignent d'être envoyés vers la messagerie vocale en pleine journée.

Méthodologie de débogage avec le mode Replay :

1. Identifier une interaction : Dans Performance > Interactions, trouvez un appel qui a été incorrectement routé vers la messagerie vocale.
2. Lancer le Replay : Depuis les détails de cette interaction, ouvrez l'exécution du flux en mode Replay.
3. Naviguer dans le flux : Utilisez "Step Over" pour avancer pas à pas jusqu'à l'action Evaluate Schedule.
4. Inspecter l'entrée : Juste avant d'exécuter l'action, vérifiez la variable d'entrée dans le Data Panel. Est-ce que le bon planning est utilisé ?
5. Inspecter la sortie : Exécutez l'action Evaluate Schedule avec "Step Over". L'action suivante sur le chemin "Closed" est maintenant en surbrillance.
6. Analyser le résultat : Regardez à nouveau le Data Panel. La variable de sortie de votre action Evaluate Schedule (par exemple, Flow.IsOpen) est à false. C'est la cause directe du mauvais routage.
7. Poser le diagnostic : Le problème ne vient pas de la logique du flux (la condition If Flow.IsOpen fonctionne), mais des données sur lesquelles elle s'appuie. Le diagnostic est donc : "Le planning d'ouverture est mal configuré (probablement un problème de fuseau horaire ou de jours sélectionnés)".

Vous avez ainsi transformé un problème vague en une cause racine précise et exploitable, sans avoir à deviner ou à ajouter des logs temporaires dans votre flux.

Conclusion

Vous disposez maintenant des outils les plus puissants pour analyser et corriger la logique de vos flux Architect.

Points clés à retenir :

• Le mode Debug en direct est idéal pour des tests rapides et pour entendre le comportement d'un flux avant sa publication.
• Le mode Replay est l'outil de diagnostic détaillé qui permet de rejouer une exécution passée, de naviguer pas à pas et d'inspecter les valeurs de toutes les variables.
• Le panneau de données (Data Panel) en mode Replay est la clé pour comprendre pourquoi une décision a été prise dans votre flux.
• Assurez-vous que le niveau de journalisation de vos flux est réglé sur "Detailed" ou "Full" si vous prévoyez d'avoir besoin de déboguer leur logique.

Et ensuite ?
Maintenant que vous savez comment traquer les erreurs de logique, nous allons nous concentrer sur une source très fréquente de ces erreurs : les appels à des systèmes externes. Dans la prochaine et dernière leçon de ce module, nous verrons comment diagnostiquer un échec d'appel à une Data Action en analysant la réponse d'erreur, en utilisant les techniques de débogage que vous venez d'apprendre.