Middlewares

S’APPLIQUE À : Kit de développement logiciel (SDK) v4

Les middlewares sont simplement une classe qui se trouve entre l’adaptateur et la logique de votre bot, et qui est ajoutée à la collection de middlewares de votre adaptateur durant l’initialisation. Le Kit de développement logiciel (SDK) vous permet d’écrire vos propres intergiciels ou d’ajouter des intergiciels créés par d’autres. Toute activité qui entre dans votre bot ou qui en sort transite par votre intergiciel.

L’adaptateur traite et dirige les activités entrantes via le pipeline d’intergiciel de bot vers la logique de votre bot, puis revient à nouveau. Comme chaque activité entre et sort du bot, chaque middleware peut effectuer une inspection ou une action sur l’activité, avant comme après l’exécution de la logique de bot.

Avant de passer au middleware, il est important de comprendre les bots en général et comment ils traitent les activités.

Utilisations des middlewares

La question se pose souvent : « Quand dois-je implémenter des actions en tant qu’intergiciels et utiliser ma logique de bot normale ? » L’intergiciel vous offre des possibilités supplémentaires d’interagir avec le flux de conversation de vos utilisateurs avant et après chaque tour de la conversation. Un intergiciel vous permet également de stocker et de récupérer des informations concernant la conversation et d’appeler une logique de traitement supplémentaire quand cela est nécessaire. Vous trouverez ci-dessous des scénarios communs qui présentent les situations où un intergiciel peut être utile.

Inspection et action sur chaque activité

Nombreux sont les cas où votre bot doit intervenir sur chaque activité, ou sur chaque activité d’un certain type. Par exemple, vous pouvez enregistrer chaque activité de message que votre bot reçoit ou fournir une réponse de secours si le bot n’a pas généré de réponse à ce tour. L’intergiciel est un excellent endroit pour ces processus, avec sa capacité à agir à la fois avant et après l’exécution du reste de la logique du bot.

Modification ou amélioration du contexte de tour

Certaines conversations peuvent être beaucoup plus fructueuses si le bot a plus d’informations que ce qui est fourni dans l’activité. Dans ce cas, les intergiciels peuvent examiner les informations d’état de conversation dont ils disposent jusqu’ici, interroger une source de données externe et l’ajouter à l’objet de contexte de tour avant de transmettre l’exécution à la logique du bot.

Le SDK définit un middleware de journalisation qui peut enregistrer des activités entrantes et sortantes, mais vous pouvez également définir votre propre middleware.

Pipeline de middlewares de bot

Pour chaque activité, l’adaptateur appelle les intergiciels dans l’ordre dans lequel vous les avez ajoutés. L’adaptateur transmet l’objet de contexte pour le tour et un délégué next, puis le middleware appelle le délégué pour passer le contrôle au middleware suivant dans le pipeline. Les middlewares peuvent également effectuer des opérations une fois que le délégué next a retourné le contrôle avant la fin de la méthode. Vous pouvez considérer que chaque objet de middleware a une occasion unique d’agir par rapport aux objets de middleware qui le suivent dans le pipeline.

Par exemple :

• Le gestionnaire de tour d’un premier objet middleware exécute du code avant d’appeler suivant.
  • Le deuxième gestionnaire d’intergiciels exécute le code avant d’appeler suivant.
    • Le gestionnaire de tour du bot s’exécute et retourne.
  • Le gestionnaire de tour d’un deuxième objet middleware exécute tout code restant avant de retourner.
• Le gestionnaire de tour d’un premier objet middleware exécute tout code restant avant de retourner.

Si l’intergiciel n’appelle pas le délégué suivant, l’adaptateur n’appelle aucun des gestionnaires d’intergiciels ou de tour de bot suivants, et les courts-circuits du pipeline.

Une fois le pipeline de middlewares de bot terminé, le tour prend fin et le contexte de tour se retrouve hors de l’étendue.

Les middlewares ou le bot peuvent générer des réponses et inscrire des gestionnaires d’événements de réponse, mais n’oubliez pas que les réponses sont gérées dans des processus distincts.

Ordre des middlewares

Étant donné que l’ordre dans lequel les middlewares sont ajoutés détermine l’ordre dans lequel ils traitent une activité, il est important de décider de la séquence d’ajout des middlewares.

Notes

Vous disposerez ainsi d’un modèle commun qui fonctionne pour la plupart des bots, mais veillez à prendre en compte la façon dont chaque middleware est susceptible d’interagir avec les autres en fonction de votre situation.

Middleware qui prend en charge les tâches de niveau le plus bas que chaque bot doit d’abord ajouter à votre pipeline d’intergiciels. Citons par exemple la journalisation, la gestion des exceptions et la traduction. Commandez-les en fonction de vos besoins, par exemple si vous souhaitez que le message entrant soit traduit en premier, avant que les messages ne soient stockés, ou si le stockage des messages doit se produire en premier, ce qui peut signifier que les messages stockés ne seraient pas traduits.

L’intergiciel spécifique au bot doit être ajouté à votre pipeline d’intergiciels en dernier, intergiciel que vous implémentez pour effectuer un traitement sur chaque message envoyé à votre bot. Si vos middlewares utilisent des informations d’état ou d’autres informations définies dans le contexte de bot, ajoutez-les au pipeline de middlewares après les middlewares qui modifient l’état ou le contexte.

Court-circuitage

Une idée importante au sujet des intergiciels et des gestionnaires de réponses est le court-circuitage. Un middleware (ou un gestionnaire de réponses) doit transmettre l’exécution en appelant son délégué suivant si l’exécution doit se poursuivre à travers les couches qui le suivent. Si le délégué suivant n’est pas appelé dans ce middleware (ou gestionnaire de réponse), les courts-circuits de pipeline associés et les couches suivantes ne sont pas exécutés. Cela signifie que toute la logique de bot et tous les intergiciels dans le pipeline sont ignorés. Il existe une différence subtile entre votre intergiciel et votre gestionnaire de réponse qui court-circuite un tour.

Lorsque l’intergiciel court-circuite un tour, votre gestionnaire de tour de bot n’est pas appelé, mais tout le code d’intergiciel exécuté avant ce point dans le pipeline s’exécute toujours jusqu’à la fin.

Pour les gestionnaires d’événements, l’appel suivant signifie que l’événement est annulé, ce qui est très différent de la logique de l’intergiciel. En ne traitant pas le reste de l’événement, l’adaptateur ne l’envoie jamais.

Conseil

Si vous court-circuitez un événement de réponse, tel que SendActivities, assurez-vous qu’il s’agit du comportement que vous envisagez. Sinon, cela peut compliquer la correction des bogues.

Gestionnaires d’événements de réponse

En plus de la logique d’application et d’intergiciel, vous pouvez ajouter des gestionnaires de réponse (parfois également appelés gestionnaires d’événements ou gestionnaires d’événements d’activité) à l’objet de contexte. Ces gestionnaires sont appelés quand la réponse associée se produit sur l’objet de contexte actuel, avant l’exécution de la réponse proprement dite. Ces gestionnaires sont utiles quand vous savez que vous souhaitez faire quelque chose, avant ou après l’événement réel, pour toute activité de ce type pour le reste de la réponse actuelle.

Avertissement

Veillez à ne pas appeler une méthode de réponse d’activité à partir de son propre gestionnaire d’événements de réponse, par exemple, en appelant la méthode d’envoi d’activité depuis un gestionnaire écoutant les envois d’activité. Cela peut générer une boucle infinie.

Rappelez-vous que chaque nouvelle activité obtient un nouveau thread sur lequel s’exécuter. Quand le thread destiné à traiter l’activité est créé, la liste des gestionnaires de cette activité est copiée sur ce nouveau thread. Aucun gestionnaire ajouté après ce point n’est exécuté pour cet événement d’activité spécifique. Les gestionnaires inscrits sur un objet de contexte sont gérés de la même façon que l’adaptateur gère le pipeline d’intergiciels. Concrètement, les gestionnaires sont appelés dans l’ordre dans lequel ils sont ajoutés, et l’appel du délégué suivant transmet le contrôle au gestionnaire d’événements inscrit suivant. Si un gestionnaire n’appelle pas le délégué suivant, aucun des gestionnaires d’événements suivants n’est appelé, les courts-circuits d’événements et l’adaptateur n’envoie pas la réponse au canal.

Gestion de l’état dans le middleware

Une méthode courante pour enregistrer l’état consiste à appeler la méthode Enregistrer les modifications à la fin du gestionnaire de tour. Voici un diagramme avec un focus sur l’appel.

Le problème avec cette approche est que toutes les mises à jour d’état effectuées à partir d’un intergiciel personnalisé qui se produisent après le retour du gestionnaire de tour du bot ne seront pas enregistrées dans un stockage durable. La solution consiste à déplacer l’appel vers la méthode d’enregistrement des modifications une fois que le middleware personnalisé a terminé en ajoutant une instance du middleware d’enregistrement automatique des modifications au début de la pile de middleware, ou au moins avant toute partie du middleware pouvant mettre l’état à jour. L’exécution est illustrée ci-dessous.

Ajoutez les objets de gestion d’état qui nécessitent une mise à jour dans un objet de jeu d’états de bot, puis utilisez-les quand vous créez votre middleware d’enregistrement automatique des modifications.

Ressources supplémentaires

Vous pouvez observer l’intergiciel d’enregistreur d’événements de transcription, tel qu’il est implémenté dans le kit SDK Bot Framework [C# | JS].