Obtenir des mises à jour en temps réel pour les modifications de données à l’aide de Microsoft Graph
Cet article décrit un modèle d’intégration Microsoft Graph courant pour un scénario métier qui offre des améliorations de collaboration d’entreprise permettant aux applications mobiles de recevoir un flux en lecture seule de messages partagés à partir de Microsoft Teams en quasi-temps réel.
Ce scénario est un cas d’usage non interactif qui s’appuie sur des modifications de données déclenchées par des événements externes et qui présente les exigences d’architecture suivantes :
- Type d’intégration de données.
- Flux de données sortants des limites Microsoft 365 vers l’application.
- Un faible volume de données par interaction humaine, mais un volume de données potentiellement élevé en fonction du nombre d’utilisateurs.
- Latence des données en quasi-temps réel pour générer un flux à jour.
La meilleure option d’intégration pour ce scénario consiste à utiliser des notifications de modification Microsoft Graph, qui peuvent fournir des notifications d’événements ainsi que le contenu d’un message partagé et implémenter des webhooks. L’application cliente fournit une clé secrète client et une clé de chiffrement et expose un point de terminaison HTTP où le service de notification Microsoft Graph publie des modifications. L’application cliente peut accepter et répondre rapidement aux requêtes Microsoft Graph synchrones et peut être mise à l’échelle pour gérer les événements déclenchés par d’autres clients qui génèrent des messages. Ce type d’interaction d’application est appelé mode push.
Le diagramme suivant illustre l’architecture de cette solution.
Composants de la solution
L’architecture de la solution comprend les composants suivants :
- Azure App Service vous permet de créer et d’héberger des applications web, des back-ends mobiles et des API RESTful dans votre langage de programmation préféré, sans gérer l’infrastructure. Il offre une mise à l’échelle automatique et une haute disponibilité, prend en charge Windows et Linux, et permet des déploiements automatisés à partir de GitHub, d’Azure DevOps ou de n’importe quel dépôt Git.
- 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.
- L’application de fonction, qui est un composant serverless qui vous permet de mettre à l’échelle un volume élevé de notifications et a une logique métier pour traiter les notifications et les envoyer à un service de destination.
- File d’attente de stockage simple, qui vous permet de se débarrasser de la charge du service d’application en rendant les notifications persistantes avant le traitement asynchrone par un instance d’une application de fonction.
- Azure Application Gateway, qui fournit des fonctionnalités de routage et de sécurité web.
- Service de notification Microsoft Graph, qui gère les abonnements aux notifications et remet des notifications de modification aux clients.
Considérations
Les considérations suivantes prennent en charge l’utilisation de ce modèle d’intégration :
Disponibilité : Microsoft Graph appelle le webhook client chaque fois qu’un nouveau message est publié dans un canal partagé ou une conversation. Le webhook doit avoir une haute disponibilité tout au long de la journée ou même pendant 24 heures complètes.
Latence : le webhook doit accuser réception des demandes de notification Microsoft Graph dans un délai de trois secondes. Si Microsoft Graph ne reçoit pas de code de classe 200 dans ce délai, il renvoie la notification de modification plusieurs fois, pendant quatre heures maximum.
Scalabilité : le webhook client doit pouvoir être mis à l’échelle pour un volume élevé de notifications à tout moment de la journée. Pour ce faire, il peut ajouter d’autres instances au service d’application et instancier d’autres instances d’application de fonction pour mettre à jour rapidement le service de destination.
Complexité de la solution : la solution webhook nécessite également du code personnalisé pour gérer les abonnements et des clés de chiffrement pour traiter les données. Cette solution est très complexe en raison du nombre de composants impliqués et des exigences de scalabilité et de disponibilité.