Partager via


Créer des applications interactives à l’aide des API Microsoft Graph

Cet article décrit un modèle d’intégration Microsoft Graph courant pour un scénario métier qui nécessite une interface utilisateur capable de créer, mettre à jour et gérer des messages de canal en temps réel. Ce scénario dépend des services Microsoft 365 tels que l’envoi et la réception de messages de différentes équipes.

Ce scénario présente les exigences d’architecture suivantes :

  • Type d’intégration d’application, car il s’appuie sur des fonctionnalités Microsoft 365 complexes.
  • Flux de données bidirectionnel entre l’application et Microsoft 365.
  • Un faible volume de données par rapport aux systèmes automatisés basés sur des interations humaines uniques. Toutefois, en fonction du nombre d’utilisateurs, le volume de données peut être élevé.
  • Une opération de données en temps réel sur l’application, avec certaines opérations côté serveur asynchrones, telles que la remise d’e-mails à un client distant.

Le meilleur choix pour cette application consiste à utiliser les API HTTP RESTful De Microsoft Graph. L’application cliente répond aux actions de l’utilisateur et peut effectuer des demandes et traiter les données à une vitesse contrôlée par l’environnement client.

Le diagramme suivant illustre l’architecture de cette solution.

Diagramme montrant une application tierce qui s’authentifie avec Microsoft Entra ID et communique avec les API Microsoft Graph, qui interagissent via HTTP avec des applications telles que Teams, Planificateur, OneDrive et SharePoint.

Composants de la solution

L’architecture de la solution comprend les composants suivants :

  • Azure App Service, qui 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 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.
  • SQL Database est utilisé pour stocker les données et l’état de l’application ; ce composant est facultatif.
  • API RESTful Microsoft Graph, accessibles via un seul point de terminaison : https://graph.microsoft.com.
  • Application qui implémente une logique personnalisée.

Considérations

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

  • Disponibilité : l’application cliente interroge régulièrement les API Microsoft Graph pour obtenir des données. L’application cliente peut effectuer des requêtes et traiter les données à une vitesse contrôlée par l’environnement client.

  • Latence : l’application cliente interroge les API Microsoft Graph pour obtenir des données en temps réel. Toutefois, il peut y avoir une certaine latence en fonction des conditions réseau et de la charge sur le service Microsoft Graph.

  • Scalabilité : l’application cliente peut effectuer une mise à l’échelle horizontale en ajoutant d’autres instances au plan App Service. Les API Microsoft Graph peuvent gérer un grand nombre de demandes, mais elles ont également des limites et des stratégies de limitation pour empêcher les abus. L’application cliente doit implémenter une logique de nouvelle tentative et une interruption exponentielle pour gérer correctement les erreurs de limitation.

  • Complexité de la solution : bien que cette solution puisse utiliser le Kit de développement logiciel (SDK) Microsoft Graph, elle nécessite toujours un code personnalisé pour interroger et traiter les données. Si le volume de données est volumineux, le traitement séquentiel peut ne pas être suffisant et un traitement parallèle peut être nécessaire. Pour cette raison, cette solution présente un niveau de complexité moyen.