Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 27

Test et débogage de flux IVR dans Architect

Recommended resources

Bonjour !

Dans la leçon précédente, nous avons construit un flux de SVI (Serveur Vocal Interactif) complet, capable de router les appelants vers les bonnes files d'attente en fonction de leurs choix. Cependant, comme tout processus de développement, la création d'un flux n'est complète qu'une fois qu'il a été testé. Une erreur de connexion, une variable mal configurée ou une logique incorrecte peut entraîner une expérience frustrante pour l'appelant.

L'objectif de cette leçon est donc de vous apprendre à tester et déboguer efficacement un flux SVI avec les outils de diagnostic d'Architect. Vous qui avez l'expérience de Cisco UCCE, vous savez à quel point il est crucial de disposer de bons outils pour valider la logique d'un script avant et après sa mise en production. Genesys Cloud propose deux approches puissantes et complémentaires pour cela :

  1. Le mode Debug : pour un test en direct pendant le développement.
  2. Le mode Replay : pour une analyse a posteriori d'une interaction réelle.

À la fin de cette leçon, vous saurez utiliser ces deux outils pour valenter vos flux et diagnostiquer rapidement d'éventuels problèmes.

1. Le Mode "Debug" : Tester en direct avant de publier

La première ligne de défense contre les erreurs est le test unitaire pendant la construction du flux. Le mode "Debug" d'Architect est conçu exactement pour cela. Il vous permet d'appeler une version "brouillon" de votre flux, qui n'est pas encore publiée ni accessible au public, afin de vérifier son comportement.

Pour comprendre les bases de cette fonctionnalité, je vous invite à lire un court article de la documentation Genesys Cloud.

Test a flow View summary

Cet article, 'Test a flow', explique le principe du mode 'Debug', comment l'activer et comment appeler votre flux pour le tester.

Lisez l'intégralité de cet article. Concentrez-vous sur la manière d'activer le mode 'Debug' via le menu 'Publish' et sur le format de l'adresse SIP à utiliser pour passer l'appel de test. Notez bien la remarque sur la gestion des espaces et des caractères spéciaux dans le nom du flux.

Comme vous l'avez lu, le mode Debug est simple mais efficace. Lorsque vous appelez le flux en mode debug, vous entendez non seulement les messages audio destinés à l'appelant, mais aussi des messages système supplémentaires (en anglais) qui vous indiquent quelle action est en cours d'exécution. C'est un excellent moyen de suivre le cheminement de l'appel en temps réel.

Mise en pratique : Testons notre SVI

Il est temps d'appliquer cette méthode à notre flux SVI.

  1. Ouvrez le flux SVI que nous avons finalisé dans la leçon précédente.
  2. Assurez-vous qu'il n'y a pas d'erreur de validation (Architect vous l'indiquerait par un avertissement).
  3. Cliquez sur la flèche à côté du bouton Publish en haut à droite, puis sélectionnez Debug. Une fenêtre de confirmation apparaîtra avec l'adresse SIP à appeler. Elle suivra le format : sip:VotreNomDeFlux-debug@localhost.
    • Attention : Si votre nom de flux contient des espaces, comme "Menu Principal SVI", l'adresse sera encodée : sip:Menu%20Principal%20SVI-debug@localhost. Copiez l'adresse fournie par Architect.
  4. Depuis votre interface agent Genesys Cloud, utilisez le softphone pour passer un appel vers cette adresse SIP.
  5. Suivez les instructions audio et testez les différents scénarios :
    • Faites un choix valide (ex: tapez 1 pour les Ventes). Vous devriez entendre le message de pré-transfert puis l'appel devrait (en théorie) être mis en attente.
    • Ne faites aucun choix et laissez le timeout se déclencher. Vérifiez que le message de relance est bien joué.
    • Faites un choix invalide (ex: tapez 9). Vérifiez que le message de saisie invalide est joué.

Cet exercice vous permet de valider auditivement que la logique que vous avez construite sur le canevas se comporte comme prévu du point de vue de l'appelant.

2. Le Mode "Replay" : Analyser une exécution passée

Le mode Debug est parfait pour le développement, mais que faire lorsqu'un problème survient sur un flux en production avec un appel réel ? Vous ne pouvez pas demander au client de rappeler sur une ligne de test. C'est là qu'intervient le mode Replay, un outil de diagnostic extrêmement puissant qui agit comme une "boîte noire" pour vos flux.

Le mode Replay vous permet de sélectionner une interaction passée (un appel, un email, etc.) et de rejouer, pas à pas, son parcours exact à travers le flux Architect.

Genesys Cloud Architect : Mode Relecture et Historique d'Exécution d'un Flux
Cette image montre l'interface du mode Replay. Notez la chronologie "Execution History" en bas, qui liste chaque action exécutée, et la mise en surbrillance du chemin pris par l'interaction dans le flux principal.

Pour explorer en détail les fonctionnalités de cet outil, je vous propose de consulter la documentation suivante.

Use replay mode to troubleshoot an Architect flow View summary

L'article 'Use replay mode to troubleshoot an Architect flow' est le guide de référence complet sur cet outil. Il détaille les contrôles de relecture, l'inspection des variables et d'autres panneaux utiles.

Lisez attentivement les sections décrivant les 'replay controls' (Play, Step In, Step Over, etc.) et les panneaux 'Data' et 'Communications'. Concentrez-vous sur la manière d'utiliser ces outils pour suivre l'exécution et inspecter l'état du flux à chaque étape.

Les composants clés du mode Replay :

  • Accès : Vous accédez généralement au mode Replay depuis la vue détaillée d'une interaction. Pour cela, allez dans Performance > Interactions, trouvez l'interaction que vous souhaitez analyser, cliquez dessus pour ouvrir sa vue détaillée, puis cherchez une option ou un lien pour voir l'exécution du flux.
  • Contrôles de Relecture (Replay Controls) : Comme dans un débogueur de code, vous pouvez :
    • Play/Pause : Lancer la relecture automatique.
    • Step Over : Aller à l'action suivante sans entrer dans les détails internes d'une tâche complexe.
    • Step In : Entrer dans une tâche ou un menu pour voir chaque étape interne.
    • Breakpoints : Placer des points d'arrêt pour que la relecture s'arrête automatiquement à des endroits spécifiques.
  • Panneau de Données (Data Panel) : C'est sans doute l'élément le plus important pour le débogage. À chaque étape de la relecture, ce panneau vous montre la valeur de toutes les variables du flux (Flow.variable, Task.variable, etc.). Si votre flux prend une mauvaise décision, c'est souvent à cause d'une valeur de variable inattendue.
  • Niveau de données d'exécution (Execution Data Level) : Un point crucial à savoir est que la quantité d'informations disponibles en mode Replay dépend d'un paramètre sur votre flux. Pour pouvoir voir les valeurs des variables, le niveau d'exécution doit être réglé sur "Detailed" ou "Diagnostic", et non sur "Base". C'est un paramètre à configurer dans les réglages du flux lui-même.

Scénario de débogage : Trouver l'erreur

Imaginons le scénario suivant : un responsable vous signale que plusieurs clients se sont plaints d'avoir été transférés au service "Facturation" alors qu'ils avaient choisi le "Support Technique" dans le SVI.

Voici comment vous utiliseriez le mode Replay pour diagnostiquer ce problème :

  1. Trouver une interaction problématique : Allez dans Performance > Interactions et filtrez les appels qui sont passés par votre flux SVI et ont atterri dans la file "Support Facturation". Trouvez un exemple récent.
  2. Lancer le mode Replay : Depuis les détails de cette interaction, lancez la relecture du flux.
  3. Suivre le chemin : Utilisez Step Over pour avancer rapidement jusqu'à l'action Menu Principal.
  4. Inspecter le choix : Avancez encore d'un pas. Le chemin de sortie pris par le menu sera mis en évidence. Vous verrez si la sortie correspondante au choix "Support Technique" (par ex., la sortie 2) a bien été empruntée.
  5. Vérifier la connexion : Suivez la ligne de connexion partant de cette sortie 2. Vous constaterez probablement qu'au lieu d'être connectée à l'action Transfer to ACD pour le "Support Technique", elle a été connectée par erreur à l'action Transfer to ACD pour la "Facturation".
  6. Correction : Vous pouvez alors retourner dans l'éditeur de flux, corriger la connexion, publier la nouvelle version et le problème est résolu.

Le mode Replay transforme le débogage d'un jeu de devinettes en une investigation méthodique et factuelle.

Conclusion

Vous maîtrisez maintenant les deux piliers du test et du débogage dans Genesys Cloud Architect.

Points clés à retenir :

  • Le mode Debug est votre outil de prédilection pendant le développement. Il permet de faire des tests auditifs en direct sur une version non publiée du flux.
  • Le mode Replay est votre outil d'investigation pour les flux en production. Il offre une analyse visuelle et détaillée, pas à pas, de la façon dont une interaction réelle a été traitée.
  • L'inspection des variables dans le panneau Data du mode Replay est fondamentale pour comprendre la logique conditionnelle et identifier les erreurs de données.
  • Un test rigoureux est une étape non négociable avant toute mise en production d'un flux.

Prochaine leçon :

Maintenant que nous savons construire et déboguer des SVI robustes basés sur des menus, nous allons enrichir la logique de nos flux. Dans la prochaine leçon, nous entrerons dans le module "Logique de Flux Avancée" et commencerons par explorer les actions de décision comme Switch et Decision. Ces outils vous permettront de créer des branchements conditionnels bien plus complexes et dynamiques que ce qu'un simple menu peut offrir, rendant vos compétences en débogage encore plus essentielles.