Combiner des bots avec des onglets

Important

Cet article est basé sur le SDK v3 Bot Framework. Si vous recherchez la documentation actuelle version 4.6 ou ultérieure du SDK, consultez la section relative aux bots de conversation.

Les bots et les onglets fonctionnent bien ensemble et sont souvent combinés en un seul service back-end. Cette section décrit les meilleures pratiques et les modèles courants d’utilisation des onglets et des bots ensemble.

Association d’identités d’utilisateurs entre le bot et l’onglet

Par exemple : supposons que votre application d’onglet utilise un système d’ID propriétaire pour sécuriser son contenu. Supposons que vous avez également un bot qui peut interagir avec l’utilisateur. En règle générale, vous souhaiterez afficher dans l’onglet du contenu spécifique à l’utilisateur d’affichage. La difficulté est que l’ID d’utilisateur dans votre système est probablement différent de l’ID Microsoft Teams’utilisateur. Comment associer ces deux identités ? En règle générale, l’approche recommandée consiste à signer l’utilisateur avec le bot à l’aide du système d’identité utilisé pour fournir l’authentification pour le contenu de l’onglet. Vous pouvez l’implémenter via l’action de connexion, qui connecte généralement l’utilisateur via un flux OAuth.

Ce flux fonctionne mieux si votre fournisseur d’identité implémente le protocole OAuth 2.0. Vous pouvez ensuite associer l Teams’utilisateur principal aux informations d’identification de l’utilisateur à partir de votre propre service d’identité.

Association d’identités

Vous pouvez utiliser des onglets pour afficher plus de contenu qu’il ne peut y en avoir dans une carte ou fournir un moyen d’effectuer des tâches complexes de remplissage de formulaire à l’aide de la zone de dessin de l’onglet. Par exemple, pensez à naviguer vers l’onglet lorsque l’utilisateur clique sur la carte à partir de votre bot. Pour ce faire, vous devez encoder le message de votre bot pour inclure une URL de lien profond, soit par le biais du code, soit comme cible de l’action openUrl.

Les liens profonds reposent sur un entityId, qui est une valeur opaque qui matric une entité unique dans votre système. Lorsque l’onglet est créé, vous stockez dans l’idéal un état simple, par exemple, un indicateur sur votre système arrière indiquant que l’onglet a été créé dans le canal. Lorsque votre bot construit un message, il peut cibler l’entityId associé à cet onglet.

Notes

dans les conversations personnelles, étant donné que les onglets sont « statiques » et installés avec l’application, vous pouvez toujours supposer leur existence et construire des liens profonds en conséquence.

Envoi de notifications pour les mises à jour d’onglets

Il est souvent possible d’avertir l’utilisateur final chaque fois qu’une mise à jour ou une action de l’utilisateur se produit dans un onglet. Un exemple de scénario consiste à affecter une tâche ou un ticket à un membre de l’équipe, puis à avertir ce membre de l’équipe.

Il existe deux façons d’atteindre ce scénario :

  1. Si vous souhaitez avertir un canal entier, votre bot peut publier de manière asynchrone un message sur le canal. Il n’existe aucun moyen pour un bot de créer de manière proactive la conversation d’onglet si elle n’a pas été créée avec l’onglet.

  2. Si vous souhaitez uniquement avertir le destinataire ou les parties concernées impliquées dans l’action, votre bot peut envoyer un message de conversation personnelle à l’utilisateur. Vous devez d’abord vérifier si une conversation personnelle existe entre votre bot et l’utilisateur. Si ce n’est pas le cas, vous CreateConversation pouvez appeler pour lancer la conversation personnelle.

Dans les deux cas, utilisez judicieusement les notifications d’événement et ne mettez jamais l’utilisateur en courrier indésirable avec des mises à jour inutiles.