Spécifier les exigences du runtime de l’hôte Microsoft 365 dans le manifeste de l’application

Lorsque vous mettez à niveau votre application d’extension de message ou d’onglet personnel Microsoft Teams pour utiliser le manifeste d’application version 1.13 ou ultérieure, elle est disponible par défaut dans d’autres hôtes d’application Microsoft 365. Toutefois, si votre application inclut également des fonctionnalités qui ne sont pas encore prises en charge dans certains hôtes, il se peut qu’elle ne se charge que partiellement, ce qui entraîne des expériences utilisateur non planifiées.

Par exemple, prenons l’exemple d’une application qui est définie avec le schéma de manifeste d’application version 1.17 et qui inclut un bot et un onglet de configuration qui représente les paramètres du bot. L’application se charge dans Outlook et l’application Microsoft 365 (Office), mais expose uniquement l’onglet configuration du bot à l’utilisateur sans le bot lui-même.

Pour vous assurer que les expériences d’application de haute qualité atteignent votre base d’utilisateurs prévue, spécifiez les exigences d’exécution de votre application dans le manifeste de l’application. Cela vous permet d’adapter son comportement dans les hôtes Microsoft 365 applicables, ou de l’omettre de le faire apparaître dans des contextes que vous n’êtes pas prêt à prendre en charge.

La spécification des exigences d’exécution de votre application est utile dans les scénarios tels que :

• Dépendances unidirectionnel : lorsque le seul objectif d’une fonctionnalité d’application est de prendre en charge une autre fonctionnalité dans votre application, vous pouvez vous assurer qu’elle ne s’affiche que si la fonctionnalité d’application principale est chargée. Par exemple, si votre application inclut à la fois un onglet et une extension de message, et que l’onglet fonctionne comme une page de paramètres permettant aux utilisateurs de configurer la fonctionnalité d’extension de message, vous pouvez spécifier que l’onglet Paramètres ne se charge pas dans les hôtes qui ne prennent pas en charge votre extension de message.

• Dépendances mutuelles : Lorsque votre application a des fonctionnalités d’application spécifiques qui doivent être chargées ensemble pour fonctionner correctement, vous pouvez vous assurer que votre application est disponible uniquement dans les hôtes Microsoft 365 qui prennent en charge toutes les fonctionnalités. Par exemple, si les fonctionnalités d’extension d’onglet, de bot et de message fonctionnent toutes ensemble pour prendre en charge un scénario utilisateur principal dans votre application, vous pouvez spécifier que ces fonctionnalités sont toujours chargées ensemble, ou pas du tout.

• Exigences en matière de capacité : Lorsque votre application a des fonctionnalités avec des exigences d’exécution qui ne sont pas prises en charge sur des hôtes Microsoft 365 spécifiques, vous pouvez vous assurer que ces fonctionnalités sont omises de manière transparente (plutôt que chargées, mais non fonctionnelles) de votre expérience d’application s’exécutant sur ces hôtes. Par exemple, si votre application inclut une vue de tableau de bord basée sur des onglets d’éléments qui peuvent chacun être ouverts sous forme de boîte de dialogue, et que chaque boîte de dialogue contient des informations qui sont ensuite envoyées à un bot, vous pouvez spécifier que les dialogues basés sur un bot sont les principales fonctionnalités requises pour que votre application se charge dans un hôte donné.

Prise en charge de l’hôte Microsoft 365

Les applications hôtes Microsoft 365 suivantes prennent en charge la possibilité de spécifier des exigences d’exécution dans le manifeste de l’application :

Spécifier les relations entre les fonctionnalités de l’application (elementRelationshipSet)

Vous pouvez spécifier des relations entre les fonctionnalités individuelles de votre application en incluant un dans le manifeste de elementRelationshipSet votre application. Utilisez cet objet pour spécifier à la fois les dépendances unidirectionnel et les dépendances mutuelles entre les fonctionnalités de l’application.

Les fonctionnalités de manifeste d’application suivantes peuvent être spécifiées comme ayant des dépendances unidirectionnel ou mutuelles :

• Onglets : personnel (staticTabs) et configurable (configurableTabs)
• Extensions de message (composeExtensions), y compris les commandes individuelles
• Bots (bots)

Chaque fonctionnalité d’application est définie par la propriété nouvellement introduite, id, qui mappe à botId pour les bots, entityId pour les onglets statiques et id pour les onglets configurables et les extensions de message. Teams et les autres hôtes Microsoft 365 prennent en charge les applications qui contiennent un seul onglet configurable, une seule extension de message ou les deux. La id propriété pérennise votre application si la prise en charge de l’hôte s’étend pour prendre en charge plusieurs instances de ces fonctionnalités.

Dépendances unidirectionnel

Utilisez le oneWayDependencies tableau pour décrire les cas où un composant de votre application dépend d’un autre composant. Pour chaque objet du tableau, spécifiez le composant dépendant (element) et le composant dont il dépend (dependsOn). Vous pouvez également spécifier des commandes individuelles qui nécessitent la prise en charge de fonctionnalités d’application spécifiques. Si ces fonctionnalités ne sont pas prises en charge dans l’hôte d’exécution, elles ne sont pas mises à la disposition de l’utilisateur (bien que toutes les autres commandes s’exécutent).

L’extrait de code JSON suivant montre des commandes d’extension de message spécifiques qui ont une dépendance unidirectionnel sur un bot :

    "elementRelationshipSet": {
      "oneWayDependencies" : [
        {
          "element" : {
            "name" : "composeExtensions",
            "id" : "composeExtension-id",
            "commandIds": ["exampleCmd1", "exampleCmd2"]
          },
          "dependsOn" : [
              {"name" : "bots", "id" : "bot-id"}
            ]
        }
      ]
    }

Dépendances mutuelles

Utilisez le tableau pour regrouper les mutualDependencies fonctionnalités d’application qui doivent se charger ensemble pour prendre en charge la fonction prévue. Chaque objet du tableau représente un ensemble de fonctionnalités d’application dépendant mutuellement. L’extrait de code JSON suivant montre un bot, un onglet statique, une extension de message et un onglet configurable qui dépendent mutuellement les uns des autres :

    "elementRelationshipSet": {
      "mutualDependencies" : [
        [
                {"name" : "bots", "id" : "bot-id"}, 
                {"name" : "staticTabs", "id" : "staticTab-id"},
                {"name" : "composeExtensions", "id" : "composeExtension-id"},
                {"name" : "configurableTabs", "id": "configurableTab-id"}
        ]
      ]
    },

Spécifier les exigences d’exécution pour des fonctionnalités d’application spécifiques (requirementSet)

Dans les définitions de fonctionnalités d’application individuelles, vous pouvez spécifier des exigences de runtime TeamsJS spécifiques à l’aide d’un requirementSet. Cela garantit que la fonctionnalité d’application se charge uniquement dans les hôtes Microsoft 365 avec prise en charge des fonctionnalités critiques de TeamsJS.

Les fonctionnalités TeamsJS suivantes peuvent être spécifiées en tant qu’exigences d’exécution pour staticTabs, composeExtensionset bots:

• Boîtes de dialogue HTML (dialog.url)
• Boîtes de dialogue HTML pour Bot Framework (dialog.url.bot)
• Boîtes de dialogue carte adaptative (dialog.adaptiveCard)
• Boîtes de dialogue carte adaptative pour Bot Framework (dialog.adaptiveCard.bot)

L’extrait de code JSON suivant montre un onglet statique qui nécessite que son hôte prend en charge les dialogues HTML (appelés modules de tâche dans TeamsJS v1.x) appelés à partir d’onglets et de bots :

    "staticTabs": [
        {
            "entityId": "idForPage",
            "name": "Display name of tab",
            "contentUrl": "https://contoso.com/content?host=msteams",
            "contentBotId": "Specifies to the app that tab is an Adaptive Card Tab. You can either provide the contentBotId or contentUrl.",
            "websiteUrl": "https://contoso.com/content",
            "scopes": [
                "personal"
            ],
            "requirementSet": {
                "hostMustSupportFunctionalities": [
                  {"name": "dialogUrl"},
                  {"name": "dialogUrlBot"}
                ]
            }
        }
    ],

Exemples de code

Voir aussi

• Schéma du manifeste de l’application developer preview
• Étendre Teams applications à travers Microsoft 365
• Boîtes de dialogue de génération
• Utiliser TeamsJS pour différencier votre expérience d’application