Vue d’ensemble des compétences

  • Article

S'APPLIQUE À : SDK v4

Vous pouvez étendre un bot à l'aide d'un bot de compétence. Une compétence peut être consommée par divers autres bots, ce qui en facilite la réutilisation, et vous pouvez ainsi créer un bot orienté utilisateur et l'étendre en consommant vos propres compétences ou des compétences tierces.

  • Une compétence est un bot capable d'effectuer un ensemble de tâches pour un autre bot : un bot peut être à la fois une compétence et un bot accessible par l'utilisateur.
  • Un consommateur de compétences est un bot qui peut appeler une ou plusieurs compétences. Un consommateur de compétences orienté utilisateur est également appelé bot racine.
  • Un manifeste de compétence est un fichier JSON qui décrit les actions que la compétence peut effectuer, ses paramètres d’entrée et de sortie, ainsi que ses points de terminaison.
    • Les développeurs qui n’ont pas accès au code source de la compétence peuvent utiliser les informations du manifeste pour concevoir leur consommateur de compétences.
    • Le schéma de manifeste de compétence est un fichier JSON qui décrit le schéma du manifeste de compétence.
    • Découvrez comment implémenter une compétence et comment écrire un manifeste de compétence pour des exemples de manifestes de compétence.

En d’autres termes, l’utilisateur interagit directement avec le bot racine et le bot racine délègue une partie de sa logique de conversation à une compétence.

La fonctionnalité de compétences est conçue avec les objectifs ci-dessous :

  • Les compétences et les consommateurs communiquent via HTTP à l'aide du protocole de Bot Framework.
  • Un consommateur de compétences peut consommer plusieurs compétences.
  • Un consommateur de compétences peut consommer n’importe quelle compétence, quel que soit le langage utilisé pour implémenter la compétence. Par exemple, un bot C# peut consommer une compétence implémentée à l'aide de JavaScript.
  • Une compétence peut également être un consommateur de compétences et appeler d’autres compétences.
  • Les compétences prennent en charge l'authentification utilisateur ; toutefois, l'authentification utilisateur est locale pour la compétence et ne peut pas être transférée à un autre bot.
  • Les compétences peuvent fonctionner avec l’adaptateur Bot Framework et des adaptateurs personnalisés.

Ce diagramme montre quelques-unes des permutations possibles.

Illustration of permutations between skill consumers and skills.

Architecture conceptuelle

Une compétence et un consommateur de compétences sont des bots distincts que vous publiez indépendamment.

  • Un consommateur de compétences nécessite une logique supplémentaire pour la gestion d'une compétence, par exemple pour savoir quand appeler ou annuler la compétence, etc. En plus des objets de bot et d’adaptateur habituels, le consommateur comprend quelques objets liés aux compétences, utilisés pour échanger des activités avec la compétence. Un consommateur de compétences implémente au moins deux points de terminaison HTTP :
    • Un point de terminaison de messagerie reçoit des activités de l'utilisateur ou de la chaîne. Il s'agit du point de terminaison de messagerie habituel que tous les bots implémentent.
    • Point de terminaison de l'hôte de compétence pour recevoir des activités d'une compétence. Il s'agit d'une URL de rappel, url de service à laquelle la compétence répond. (Le consommateur de compétences doit associer le code qui reçoit la demande de méthode HTTP de la compétence à l'aide d'un gestionnaire de compétence.)
  • Une compétence nécessite une logique supplémentaire pour envoyer une activité endOfConversation lorsqu'elle est terminée, afin que le consommateur de compétences sache quand arrêter le transfert des activités à la compétence.

Ce diagramme décrit le flux d’activités de l’utilisateur vers le bot racine vers une compétence, et inversement.

Illustration of how activities flow from the user to the skill and back again.

  1. L’adaptateur du bot racine reçoit les activités de l’utilisateur et les transmet au gestionnaire d’activités du bot racine. (Les activités de l'utilisateur sont reçues au point de terminaison de messagerie du bot racine.)
  2. Le bot racine utilise un client HTTP de compétence pour envoyer une activité à la compétence. Le client obtient les informations de la conversation consommateur-compétence à partir d'une définition de compétence et d'une fabrique d'identifiants de conversation de compétence. Il s’agit notamment de l’URL du service que la compétence utilisera pour répondre à l’activité.
  3. L’adaptateur de la compétence reçoit les activités du consommateur de compétences et les transmet au gestionnaire d’activités de la compétence. (Les activités du consommateur sont reçues au point de terminaison de messagerie du bot de compétences.)
  4. Lorsque la compétence répond, le gestionnaire de compétence du bot racine reçoit l’activité. Il obtient les informations la conversation racine-utilisateur à partir de la fabrique d’ID de conversation de compétence. Il transfère ensuite l’activité à l’adaptateur du bot racine. (Les activités de la compétence sont reçues par le point de terminaison de l'hôte de la compétence du bot racine).
  5. L’adaptateur du bot racine génère en interne un message proactif pour reprendre la conversation avec l’utilisateur.
  6. L’adaptateur du bot racine envoie tous les messages de la compétence à l’utilisateur.

Ces objets aident à gérer les compétences et à router le trafic des compétences :

  • Une compétence Bot Framework décrit les informations de routage pour une compétence et peut être lue à partir du fichier de configuration du consommateur de compétences.
  • Un client HTTP de compétence envoie des activités à une compétence.
  • Un gestionnaire de compétence reçoit des activités d’une compétence.
  • La fabrique d’ID de conversation de compétence effectue une conversion entre la référence de la conversation utilisateur-racine et la référence de la conversation racine-compétence.
  • Le service Bot Connector fournit une authentification de canal et de bot-à-bot. À l'aide d'un objet de configuration d'authentification, vous pouvez ajouter la validation des revendications à une compétence ou consommateur de compétences pour limiter les applications ou les utilisateurs ayant accès.

Les objets client de compétence et gestionnaire de compétence utilisent tous deux la fabrique d’ID de conversation pour effectuer une conversion entre la conversation que le bot racine utilise pour interagir avec l’utilisateur et la conversation que le bot racine utilise pour interagir avec la compétence.

Manifestes de compétences

Un manifeste de compétence est un fichier JSON qui décrit les actions que la compétence peut effectuer, ses paramètres d'entrée et de sortie, ses points de terminaison de la compétence ainsi que les modèles de distribution de la compétence.

Pour plus d'informations sur le schéma du manifeste de compétence, consultez comment écrire un manifeste de compétences.

Communication de bot-à-bot

Il est important de comprendre certains aspects de cette conception, quel que soit le bot que vous concevez.

Actions de compétence

Certaines compétences peuvent effectuer plusieurs tâches ou actions. Par exemple, une compétence de tâche peut permettre de créer, mettre à jour, voir et supprimer des activités accessibles en tant que conversations discrètes.

Références de conversation

La conversation utilisateur-racine est différente de la conversation racine-compétence.

La fabrique d’ID de conversation permet de gérer le trafic entre un consommateur de compétences et une compétence. La fabrique effectue une conversion entre l’ID de la conversation que la racine a avec l’utilisateur et celle qu’elle a avec la compétence. En d’autres termes, elle génère un ID de conversation pour une utilisation entre la racine et la compétence, et récupère l’ID de la conversation utilisateur-racine d’origine à partir de l’ID de la conversation racine-compétence.

Coordination entre serveurs

Les bots racine et de compétences communiquent via HTTP. Ainsi, l’instance du bot racine qui reçoit une activité d’une compétence peut ne pas être la même que celle qui a envoyé l’activité de lancement ; en d’autres termes, il est possible que des serveurs différents gèrent ces deux requêtes.

  • Enregistrez toujours l’état dans le consommateur de compétences avant de transférer une activité à une compétence. Cela garantit que l’instance qui reçoit le trafic d’une compétence peut reprendre là où l’instance précédente s’est arrêtée avant d’appeler la compétence.
  • Lorsque le gestionnaire de compétence reçoit une activité d’une compétence, il la convertit en une forme appropriée pour le consommateur de compétences et la transmet à l’adaptateur du consommateur.

Consommateur de compétences et état de compétence

Le consommateur de compétences et la compétence gèrent leur propre état séparément. Toutefois, le consommateur crée l’ID de conversation qu’il utilise pour communiquer avec la compétence. Cela peut avoir un effet sur l’état de la conversation dans la compétence.

Important

Comme indiqué précédemment, lorsque le consommateur de compétences délègue une activité utilisateur à une compétence, une autre instance du consommateur peut recevoir la réponse de la compétence. Le consommateur doit toujours enregistrer l’état de la conversation immédiatement avant de transférer une activité à une compétence.

Authentification de bot-à-bot

Vous n'avez pas besoin d'un identifiant d'application et d'un mot de passe pour tester une compétence ou un consommateur de compétences localement dans le Bot Framework Emulator. Un abonnement Azure est toujours nécessaire pour déployer votre compétence sur Azure.

L’authentification au niveau du service est gérée par le service Bot Connector. Le framework utilise des jetons de porteur et des ID d’application de bot pour vérifier l’identité de chaque bot. (Le Bot Framework utilise un objet de configuration d'authentification pour valider l'en-tête d'authentification sur les demandes entrantes.)

Important

Pour ce faire, tous les bots déployés (le consommateur de compétences et toutes les compétences qu'il consomme) doivent disposer d'identifiants d'application valides.

Validation des revendications

Vous devez ajouter un validateur de revendications à la configuration de l'authentification. Les revendications sont évaluées après l’en-tête d’authentification. Levez une erreur ou une exception dans votre code de validation pour refuser la demande.

Remarque

Le bot effectue la validation des revendications s'il a un identifiant d'application et un mot de passe ; dans le cas contraire, la validation des réclamations n'est pas faite.

Nombreuses sont les raisons pour lesquelles vous pouvez souhaiter refuser une demande par ailleurs authentifiée :

  • Quand le consommateur de compétences doit accepter le trafic uniquement des compétences avec lesquelles il a pu initier une conversation.
  • Quand une compétence fait partie d'un service payant et que les utilisateurs ne figurant pas dans la base de données ne doivent pas y avoir accès.
  • Quand vous souhaitez restreindre l’accès à la compétence à des consommateurs de compétences spécifiques.

Important

Si vous ne fournissez pas de validateur de revendications, votre bot génère une erreur ou une exception lors de la réception d'une activité d'un autre bot, qu'il s'agisse d'une compétence ou d'un consommateur de compétences.

Débogage des conversations de compétences

Étant donné que le trafic entre les compétences et les consommateurs de compétences est authentifié, il existe des étapes supplémentaires lors du débogage de ces bots.

Dans le cas contraire, vous pouvez déboguer un consommateur de compétences ou une compétence comme vous déboguez d'autres bots. Pour plus d'informations, consultez Débogage d'un bot et Débogage avec Bot Framework Emulator.

Informations supplémentaires

Pour l'utilisateur, il s'agit d'une interaction avec le bot racine. Du point de vue de la compétence, le consommateur de compétences est le canal sur lequel elle communique avec l’utilisateur.