Freigeben über


Erstellen interaktiver Microsoft Graph-Apps mit Echtzeitfeed

In diesem Artikel wird ein gängiges Microsoft Graph-Integrationsmuster für ein Geschäftsszenario beschrieben, das auf Daten und Funktionen des Microsoft 365-E-Mail-Diensts basiert. Es verwendet Microsoft Graph-APIs, um Daten zu lesen, E-Mail-Vorgänge aufzurufen und Microsoft Graph-Änderungsbenachrichtigungen mithilfe von Webhooks über den WebSocket-Kanal zu empfangen. Für dieses Szenario gelten die folgenden Architekturanforderungen:

  • Ein Anwendungsintegrationstyp.
  • Ein bidirektionaler Datenfluss zwischen Microsoft 365 und der App.
  • Ein geringes Datenvolumen, da es einem einzelnen Benutzer dient.
  • Eine mittlere Datenlatenz, die für Pushbenachrichtigungen akzeptabel ist.

Dieses Muster verwendet mehrere Microsoft Graph-Integrationsoptionen, einschließlich APIs, Änderungsbenachrichtigungen und optional apIs für die Änderungsnachverfolgung. Zum Empfangen von Änderungsbenachrichtigungen über WebSocket verwendet die App das SignalR SDK, das die WebSocket-Verwaltung abstrahiert und vereinfacht.

Das folgende Diagramm zeigt die Architektur für diese Lösung.

Diagramm, das zeigt, wie der Microsoft Graph-Benachrichtigungsdienst mit Exchange, Microsoft Graph-REST-APIs, einer App mit Webhook und Microsoft Entra ID für die Authentifizierung interagiert

Lösungskomponenten

Die Lösungsarchitektur umfasst die folgenden Komponenten:

  • Microsoft Entra ID, die zum Verwalten der Authentifizierung für die Microsoft Graph-APIs erforderlich ist und delegierte Berechtigungen und Anwendungsberechtigungen unterstützt, um den OAuth-Fluss zu aktivieren.
  • Microsoft Graph-Benachrichtigungsdienste, die Benachrichtigungsabonnements verwalten und Änderungsbenachrichtigungen an Client-Apps übermittelt.
  • Restful-APIs von Microsoft Graph, auf die über einen einzelnen Endpunkt zugegriffen wird: https://graph.microsoft.com.
  • Eine benutzerdefinierte mobile App, die benutzerdefinierte Logik und Webhooks implementiert und mit Microsoft Graph kommuniziert.

Überlegungen

Die folgenden Überlegungen unterstützen die Verwendung dieses Integrationsmusters:

  • Verfügbarkeit: Die benutzerdefinierte App sollte auf dem Edgegerät hochverfügbar sein und kann einen Offlinemodus unterstützen, wenn keine zuverlässige Internetverbindung verfügbar ist.

  • Latenz: Restful-HTTP-APIs von Microsoft Graph reagieren in der Regel innerhalb einer Sekunde, aber die Gesamtlatenz hängt von der Geschwindigkeit der Internetverbindung ab. Microsoft Graph-Benachrichtigungen werden innerhalb von Sekunden nach der Änderung generiert, aber ihre Übermittlung hängt von der Internetverbindung, den SLAs für mobile Anbieter und der Webhookverfügbarkeit ab.

  • Skalierbarkeit: Microsoft Graph-Dienste sind hochgradig skalierbar, geografisch verteilt und unterstützen Anforderungen und Benachrichtigungen für Millionen von Clients.

  • Lösungskomplexität: Diese Lösung erfordert benutzerdefinierten Code, um APIs zu orchestrieren, Benachrichtigungsabonnements zu verwalten und Änderungsbenachrichtigungen über Webhooks zu empfangen. Obwohl diese Lösung keine Elastizität erfordert, muss sie Benutzer unter unterschiedlichen Netzwerkbedingungen unterstützen und möglicherweise einen Burst von Änderungsbenachrichtigungen verarbeiten. Daher ist diese Lösung hochkomplex.