Partager via

Créer des applications Microsoft Graph interactives avec un flux en temps réel

  • Article

Cet article décrit un modèle d’intégration Microsoft Graph courant pour un scénario métier qui s’appuie sur les données et fonctionnalités du service de messagerie Microsoft 365. Il utilise les API Microsoft Graph pour lire des données, appeler des opérations de messagerie et recevoir des notifications de modification Microsoft Graph à l’aide de webhooks via le canal WebSocket. Ce scénario présente les exigences d’architecture suivantes :

  • Type d’intégration d’application.
  • Un flux de données bidirectionnel entre Microsoft 365 et l’application.
  • Un faible volume de données, car il sert un seul utilisateur.
  • Latence de données moyenne acceptable pour les notifications Push.

Ce modèle utilise plusieurs options d’intégration Microsoft Graph, notamment les API, les notifications de modification et, éventuellement, les API de suivi des modifications. Pour recevoir des notifications de modification via WebSocket, l’application utilise le Kit de développement logiciel (SDK) SignalR, qui extrait et simplifie la gestion de WebSocket.

Le diagramme suivant illustre l’architecture de cette solution.

Diagramme montrant comment le service de notification Microsoft Graph interagit avec Exchange, les API REST Microsoft Graph, une application avec webhook et Microsoft Entra ID pour l’authentification

Composants de la solution

L’architecture de la solution comprend les composants suivants :

  • Microsoft Entra ID, qui est nécessaire pour gérer l’authentification pour les API Microsoft Graph et prend en charge les autorisations déléguées et d’application pour activer le flux OAuth.
  • Les services de notification Microsoft Graph, qui gèrent les abonnements aux notifications et fournissent des notifications de modification aux applications clientes.
  • API RESTful Microsoft Graph accessibles via un seul point de terminaison : https://graph.microsoft.com.
  • Application mobile personnalisée qui implémente une logique personnalisée et des webhooks et communique avec Microsoft Graph.

Considérations

Les considérations suivantes prennent en charge l’utilisation de ce modèle d’intégration :

  • Disponibilité : l’application personnalisée doit être hautement disponible sur l’appareil de périphérie et peut prendre en charge un mode hors connexion lorsqu’une connexion Internet fiable n’est pas disponible.

  • Latence : les API HTTP RESTful De Microsoft Graph répondent généralement en une seconde, mais la latence globale dépend de la vitesse de connexion Internet. Les notifications Microsoft Graph sont générées dans les secondes suivant la modification, mais leur remise dépend de la connexion Internet, des contrats SLA des fournisseurs mobiles et de la disponibilité du webhook.

  • Scalabilité : les services Microsoft Graph sont des demandes et des notifications de support hautement évolutives, géodistribuables et de support pour des millions de clients.

  • Complexité de la solution : cette solution nécessite un code personnalisé pour orchestrer les API, gérer les abonnements aux notifications et recevoir des notifications de modification via des webhooks. Bien que cette solution ne nécessite pas d’élasticité, elle doit prendre en charge les utilisateurs dans différentes conditions réseau et gérer potentiellement une rafale de notifications de modification. Par conséquent, cette solution est très complexe.

Contenu connexe