Freigeben über

Angeben der Microsoft 365-Hostruntime-Anforderungen im App-Manifest

  • Artikel

Hinweis

Die Möglichkeit, Microsoft 365-Hostruntime-Anforderungen im App-Manifest (früher als Teams-App-Manifest bezeichnet) anzugeben, befindet sich in der öffentlichen Entwicklervorschau.

Wenn Sie Ihre persönliche Registerkarte oder Nachrichtenerweiterungs-App von Microsoft Teams auf die Verwendung der App-Manifestversion 1.13 oder höher aktualisieren, ist sie standardmäßig auf anderen Microsoft 365-Anwendungshosts verfügbar. Wenn Ihre App jedoch auch Funktionen enthält, die auf bestimmten Hosts noch nicht unterstützt werden, wird Ihre App möglicherweise nur teilweise geladen, was zu ungeplanten Benutzeroberflächen führt.

Betrachten Sie beispielsweise eine App, die mit der App-Manifestschemaversion 1.17 definiert ist und einen Bot und eine Konfigurationsregisterkarte enthält, die die Einstellungen des Bots darstellt. Die App würde in Outlook- und Microsoft 365 (Office)-App geladen, aber nur die Registerkarte für die Botkonfiguration für den Benutzer ohne den Bot selbst verfügbar machen.

Geben Sie die Laufzeitanforderungen Ihrer App im App-Manifest an, um sicherzustellen, dass qualitativ hochwertige App-Oberflächen die gewünschte Benutzerbasis erreichen. Auf diese Weise können Sie das Verhalten in entsprechenden Microsoft 365-Hosts anpassen oder das Auftreten in Kontexten auslassen, die Sie nicht unterstützen möchten.

Das Angeben der Laufzeitanforderungen Ihrer App ist z. B. in folgenden Szenarien nützlich:

  • Unidirektionale Abhängigkeiten: Wenn der einzige Zweck einer App-Funktion darin besteht, eine andere Funktion in Ihrer App zu unterstützen, können Sie sicherstellen, dass sie nur angezeigt wird, wenn die primäre App-Funktion geladen ist. Wenn Ihre App beispielsweise sowohl eine Registerkarte als auch eine Nachrichtenerweiterung enthält und die Registerkarte als Einstellungsseite fungiert, auf der Benutzer nachrichtenerweiterungsfunktionen konfigurieren können, können Sie angeben, dass die Registerkarte "Einstellungen" nicht in Hosts geladen wird, die Ihre Nachrichtenerweiterung nicht unterstützen.

  • Gegenseitige Abhängigkeiten: Wenn Ihre App über bestimmte App-Funktionen verfügt, die zusammen geladen werden müssen, um ordnungsgemäß zu funktionieren, können Sie sicherstellen, dass Ihre App nur in Microsoft 365-Hosts verfügbar ist, die alle Funktionen unterstützen. Wenn beispielsweise Tabstopp-, Bot- und Nachrichtenerweiterungsfunktionen zusammenarbeiten, um ein kernes Benutzerszenario in Ihrer App zu unterstützen, können Sie angeben, dass diese Funktionen immer oder gar nicht zusammen geladen werden.

  • Funktionsanforderungen: Wenn Ihre App Über Funktionen mit Laufzeitanforderungen verfügt, die auf bestimmten Microsoft 365-Hosts nicht unterstützt werden, können Sie sicherstellen, dass diese Funktionen nahtlos weggelassen werden (anstatt geladen, aber nicht funktionsfähig) in Ihrer App-Erfahrung, die auf diesen Hosts ausgeführt wird. Wenn Ihre App beispielsweise eine registerkartenbasierte Dashboard Ansicht von Elementen enthält, die jeweils als Dialog geöffnet werden können, und jeder Dialog Informationen enthält, die dann an einen Bot übermittelt werden, können Sie angeben, dass botbasierte Dialoge Kernfunktionen sind, die erforderlich sind, damit Ihre App auf einem bestimmten Host geladen werden kann.

Microsoft 365-Hostsupport

Die folgenden Microsoft 365-Hostanwendungen unterstützen die Möglichkeit, Laufzeitanforderungen im App-Manifest anzugeben:

Microsoft 365-Hostanwendung Web Desktop Mobilgeräte
Teams ✔️ ✔️ ✔️
Outlook ✔️ ✔️ (Nur neues Outlook) ✔️
Microsoft 365 (Office)
Microsoft 365 Copilot

Angeben von Beziehungen zwischen App-Funktionen (elementRelationshipSet)

Sie können Beziehungen zwischen den einzelnen Funktionen Ihrer App angeben, indem Sie ein elementRelationshipSet in Ihr App-Manifest einschließen. Verwenden Sie dieses Objekt, um sowohl unidirektionale alsauch gegenseitige Abhängigkeiten zwischen App-Funktionen anzugeben.

Die folgenden App-Manifestfunktionen können als unidirektionale oder gegenseitige Abhängigkeiten angegeben werden:

  • Registerkarten: persönlich (staticTabs) und konfigurierbar (configurableTabs)
  • Nachrichtenerweiterungen (composeExtensions), einschließlich einzelner Befehle
  • Bots (bots)

Jede App-Funktion wird durch die neu eingeführte Eigenschaft definiert, iddie für Bots, entityId für statische Registerkarten und id für konfigurierbare Registerkarten und Nachrichtenerweiterungen zugeordnet botId wird. Teams und andere Microsoft 365-Hosts unterstützen Apps, die entweder eine einzelne konfigurierbare Registerkarte, eine einzelne Nachrichtenerweiterung oder beides enthalten. Die id -Eigenschaft ist zukunftssicher für Ihre App, wenn die Hostunterstützung erweitert wird, um mehrere Instanzen dieser Funktionen zu ermöglichen.

Wichtig

Stellen Sie sicher, dass die beziehungen, die Sie erstellen, den folgenden Validierungsregeln entsprechen:

  1. Elemente, die unter elementRelationshipSet angegeben sind, müssen definitionen im App-Manifest enthalten. Beispielsweise führt ein element oder commandId im Abschnitt eines oneWayDependencies Objekts, das dependsOn keine entsprechende Definition im App-Manifest aufweist (mit einem übereinstimmenden id Wert), zu einem Manifestvalidierungsfehler. Die id -Eigenschaft muss in einer configurableTab oder einer composeExtension angegeben werden, um in erkannt elementRelationshipSetzu werden.
  2. Ein bestimmter Satz von Funktionen kann nur durch oder mutualDependencyoneWayDependencygruppiert werden, aber nicht durch beide. Beispielsweise führt die Angabe einer unidirektionalen Abhängigkeit (A hängt von B ab) und einer gegenseitigen Abhängigkeit (A und B hängen voneinander ab) zu einem Manifestvalidierungsfehler, da die A-Beziehung von B abhängig zweimal dargestellt wird.
  3. Zyklische unidirektionale Abhängigkeiten sind nicht zulässig. Beispielsweise führt die Angabe von A von einer B-Beziehung und einer B-Beziehung abhängig von A zu einem Manifestvalidierungsfehler.

Unidirektionale Abhängigkeiten

Verwenden Sie das oneWayDependencies -Array, um Fälle zu beschreiben, in denen eine Komponente Ihrer App von einer anderen Komponente abhängt. Geben Sie für jedes Objekt im Array die abhängige Komponente (element) und die Komponente an, von der sie abhängt (dependsOn). Sie können auch einzelne Befehle angeben, die Unterstützung für bestimmte App-Funktionen erfordern. Wenn diese Funktionen auf dem Laufzeithost nicht unterstützt werden, werden sie dem Benutzer nicht zur Verfügung gestellt (obwohl alle anderen Befehle ausgeführt werden).

Der folgende JSON-Codeausschnitt zeigt bestimmte Nachrichtenerweiterungsbefehle, die eine unidirektionale Abhängigkeit von einem Bot aufweisen:

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

Gegenseitige Abhängigkeiten

Verwenden Sie das mutualDependencies -Array, um App-Funktionen zu gruppieren, die zusammen geladen werden müssen, um die beabsichtigte Funktion zu unterstützen. Jedes Objekt im Array stellt einen Satz von sich gegenseitig abhängigen App-Funktionen dar. Der folgende JSON-Codeausschnitt zeigt einen Bot, eine statische Registerkarte, eine Nachrichtenerweiterung und eine konfigurierbare Registerkarte, die sich gegenseitig voneinander abhängig sind:

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

Angeben von Laufzeitanforderungen für bestimmte App-Funktionen (requirementSet)

Innerhalb einzelner App-Funktionsdefinitionen können Sie bestimmte TeamsJS-Laufzeitanforderungen mithilfe eines requirementSetangeben. Dadurch wird sichergestellt, dass die App-Funktion nur in Microsoft 365-Hosts mit Unterstützung für die kritischen TeamsJS-Funktionen geladen wird.

Die folgenden TeamsJS-Funktionen können als Laufzeitanforderungen für staticTabs, composeExtensionsund botsangegeben werden:

Der folgende JSON-Codeausschnitt zeigt eine statische Registerkarte, für die der Host HTML-Dialoge (in TeamsJS v1.x als Aufgabenmodule bezeichnet) unterstützt, die von Registerkarten und Bots aufgerufen werden:

    "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"}
                ]
            }
        }
    ],

Codebeispiele

Beispielname Beschreibung JavaScript
Anforderungsziel: Unidirektionale Abhängigkeit Beispiel-App, die zeigt, wie unidirektionale Abhängigkeitsbeziehungen zwischen App-Funktionen angegeben werden. View
Zielgruppenadressierung für Anforderungen: Gegenseitige Abhängigkeit Beispiel-App, die zeigt, wie gegenseitige Abhängigkeitsbeziehungen zwischen App-Funktionen angegeben werden. Anzeigen

Siehe auch