Instructions relatives au débogage

S'APPLIQUE À : SDK v4

Les bots sont des applications complexes, avec de nombreuses parties travaillant ensemble. Comme pour toutes les applications complexes, des bogues intéressants ou des comportements inattendus peuvent se produire.

Il peut parfois s’avérer difficile de déboguer votre robot. Chaque développeur a son propre moyen préféré d’accomplir cette tâche. Les instructions ci-dessous sont des suggestions qui s’appliquent à la plupart des bots.

Après avoir vérifié que votre bot fonctionne, l’étape suivante consiste à la connecter à un canal. Pour ce faire, vous pouvez déployer votre bot sur un serveur intermédiaire et créer votre propre client de ligne directe pour que votre bot se connecte. Pour plus d’informations, consultez Connecter un bot à une ligne directe.

La création de votre propre client vous permet de définir les fonctionnements internes du canal et de tester la façon dont votre bot répond à certains échanges d’activités. Une fois que la connexion à votre client est établie, exécutez vos tests pour configurer l’état de votre robot et vérifier vos fonctionnalités. Si votre robot utilise une fonctionnalité comme des données vocales, il est possible de la vérifier à l’aide de ces canaux.

L’utilisation de Bot Framework Emulator et de Chat Web via Portail Azure ici peut fournir plus d’informations sur la façon dont votre bot effectue tout en interagissant avec différents canaux.

Le débogage de votre robot fonctionne de la même manière que les autres applications multithreads en permettant de définir des points d’arrêt ou d’utiliser des fonctions telles que la fenêtre immédiate.

Les bots suivent un paradigme de programmation par événement qui peut être difficile à rationaliser si vous ne le connaissez pas bien. Des bogues inattendus peuvent se produire lorsque votre robot est sans état, en multithreads et qu’il traite des appels async/await. Bien que le débogage de votre bot fonctionne de la même manière que les autres applications multithreads, nous vous proposerons quelques recommandations, outils et ressources pour vous aider.

Présentation des activités de bot avec l’émulateur

Votre robot traite différents types d’activitésen plus de l’activité normale de message. Le fait de comprendre ces activités vous aidera à coder votre robot de façon efficace et vous permettra de vérifier que les activités envoyées et reçues par votre robot correspondent bien à ce qu’elles devraient être. L’utilisation de l’émulateur vous montre ce que sont ces activités, quand elles se produisent et les informations qu’elles contiennent. Pour plus d’informations, consultez Déboguer avec l’émulateur.

Enregistrer et récupérer des interactions utilisateur avec les transcriptions

Le stockage de transcriptions blob Azure fournit une ressource spécialisée dans laquelle vous pouvez à la fois stocker et récupérer des transcriptions qui contiennent des interactions entre vos utilisateurs et votre bot.

De plus, une fois que les interactions d’entrée de l’utilisateur ont été stockées, vous pouvez utiliser l’explorateur du stockage Azure pour afficher manuellement les données contenues dans les transcriptions qui sont stockées dans votre magasin d’objets blob. L’exemple suivant ouvre l'« Explorateur stockage » à partir des paramètres de « mynewtestblobstorage ». Pour ouvrir une entrée utilisateur enregistrée, sélectionnez : Blob Container > ChannelId TranscriptId > ConversationId >

Cette opération ouvre l’entrée de la conversation utilisateur stockée au format JSON. L’entrée utilisateur est conservée avec la clé « text : ». Pour plus d’informations sur la création et l’utilisation d’un fichier de transcription de bot, consultez Déboguer votre bot à l’aide de fichiers de transcription.

Fonctionnement du middleware

L’intergiciel peut ne pas être intuitif lors de la première tentative d’utilisation, en particulier en ce qui concerne la poursuite ou le court-circuitage de l’exécution. L’intergiciel peut s’exécuter en début ou en fin de tour en appelant le délégué next() qui détermine le moment où l’exécution est transmise à la logique du robot.

Si vous utilisez plusieurs éléments d’intergiciel et que c’est la façon dont votre pipeline est orienté, le délégué peut passer l’exécution à un autre élément de middleware. Des détails sur le pipeline de l’intergiciel du robot permettent de clarifier cette idée.

Si le next() délégué n’est pas appelé, il s’agit du routage de court-circuit. Cette situation se produit lorsque l’intergiciel répond à l’activité en cours et détermine qu’il n’est pas nécessaire de transmettre l’exécution.

Comprendre quand, et pourquoi, les court-circuits d’intergiciels peuvent aider à indiquer quel élément d’intergiciel doit venir en premier dans votre pipeline. En outre, comprendre ce qu’il faut attendre est important pour les intergiciels intégrés fournis par le SDK ou d’autres développeurs. Certaines personnes trouvent utile de créer leur propre intergiciel afin de gagner en pratique avant de se lancer avec l’intergiciel intégré.

Pour plus d’informations sur la façon de déboguer un bot à l’aide d’un intergiciel d’inspection, consultez Déboguer un bot avec middleware d’inspection.

Comprendre l’état

La conservation de la trace de l’état est une partie importante de votre robot, en particulier pour les tâches complexes. En règle générale, la bonne pratique consiste à traiter les activités le plus rapidement possible et à laisser le traitement se terminer afin de conserver l’état. Les activités peuvent être envoyées à votre bot en quasi-même temps et peuvent introduire des bogues déroutants en raison de l’architecture asynchrone.

Plus important encore, assurez-vous que la conservation de l’état correspond à vos attentes. Selon l’endroit où se trouve votre état conservé, les émulateurs de stockage pour Cosmos DBet Azure Table Storage vous permettent de le vérifier avant d’utiliser le stockage en production.

Comment utiliser les gestionnaires d’activités

Les gestionnaires d’activités peuvent ajouter une couche de complexité supplémentaire, notamment parce que chaque activité s’exécute sur un thread indépendant (ou web worker selon le langage utilisé). Selon ce que font vos gestionnaires, cela peut entraîner des problèmes où l’état actuel n’est pas ce que vous attendez.

L’état intégré est enregistré en fin de tour, mais toutes les activités générées par ce tour sont exécutées indépendamment de son pipeline. Cela ne nous affecte généralement pas, mais si un gestionnaire d’activité change d’état, nous avons besoin de l’état enregistré pour maîtriser cette modification. Dans ce cas, le pipeline du tour peut rester en attente sur l’activité pour que le traitement se termine avant la fin de façon à s’assurer qu’il enregistre le bon état pour ce tour.

La méthode send activity et ses gestionnaires posent un problème unique. Le simple fait d’appeler send activity à partir d’un gestionnaire on send activities provoque une duplication infinie des threads. Il est possible de contourner ce problème, notamment en ajoutant des messages aux données sortantes ou en les écrivant dans un autre emplacement, tel que la console ou un fichier, afin d’éviter que votre bot ne plante.

Débogage d’un bot de production

Lorsque votre bot est en production, vous pouvez déboguer votre bot à partir de n’importe quel canal à l’aide de Dev Tunnels. La connexion transparente de votre bot à plusieurs canaux est une fonctionnalité clé disponible dans Bot Framework. Pour plus d’informations, consultez Déboguer un bot à partir de n’importe quel canal à l’aide de devtunnel et déboguer une compétence ou un consommateur de compétences.

Étapes suivantes

Ressources supplémentaires

• Débogage dans Visual Studio
• Débogage, traçage et profilage de l’infrastructure du robot
• Utilisez l’attribut ConditionalAttribute pour les méthodes que vous ne souhaitez pas inclure dans le code de production
• Utilisez des outils comme Fiddler pour afficher le trafic réseau
• Résoudre les problèmes généraux ainsi que les autres articles de résolution des problèmes de cette section.