Создание интерактивных приложений Microsoft Graph с помощью веб-канала в режиме реального времени

В этой статье описывается распространенный шаблон интеграции Microsoft Graph для бизнес-сценария, в котором используются данные и функции службы электронной почты Microsoft 365. Он использует API Microsoft Graph для чтения данных, вызова операций электронной почты и получения уведомлений об изменениях Microsoft Graph с помощью веб-перехватчиков через канал WebSocket. Этот сценарий имеет следующие требования к архитектуре:

  • Тип интеграции приложения.
  • Двунаправленный поток данных между Microsoft 365 и приложением.
  • Низкий объем данных, так как он обслуживает одного пользователя.
  • Средняя задержка данных, допустимая для push-уведомлений.

В этом шаблоне используется несколько вариантов интеграции Microsoft Graph, включая API, уведомления об изменениях и, при необходимости, API отслеживания изменений. Для получения уведомлений об изменениях через WebSocket приложение использует пакет SDK SignalR, который абстрагирует и упрощает управление WebSocket.

На следующей схеме показана архитектура для этого решения.

Схема взаимодействия службы уведомлений Microsoft Graph с Exchange, REST API Microsoft Graph, приложением с веб-перехватчиком и Microsoft Entra ID для проверки подлинности.

Компоненты решения

Архитектура решения включает в себя следующие компоненты:

  • Microsoft Entra ID, которая необходима для управления проверкой подлинности api Microsoft Graph и поддерживает делегированные разрешения и разрешения приложений для включения потока OAuth.
  • Службы уведомлений Microsoft Graph, которые управляют подписками на уведомления и доставляют уведомления об изменениях в клиентские приложения.
  • Api RESTful Microsoft Graph, доступ к которым осуществляется через одну конечную точку: https://graph.microsoft.com.
  • Пользовательское мобильное приложение, реализующее пользовательскую логику и веб-перехватчики и взаимодействующее с Microsoft Graph.

Рекомендации

Использование этого шаблона интеграции поддерживается следующими рекомендациями.

  • Доступность. Пользовательское приложение должно быть высокодоступным на пограничном устройстве и поддерживать автономный режим, когда надежное подключение к Интернету недоступно.

  • Задержка. API RESTful HTTP Microsoft Graph обычно реагируют в течение секунды, но общая задержка зависит от скорости подключения к Интернету. Уведомления Microsoft Graph создаются в течение нескольких секунд после изменения, но их доставка зависит от подключения к Интернету, соглашений об уровне обслуживания мобильных поставщиков и доступности веб-перехватчиков.

  • Масштабируемость. Службы Microsoft Graph являются высокомасштабируемыми, географически распределенными и поддерживают запросы и уведомления для миллионов клиентов.

  • Сложность решения. Для этого решения требуется пользовательский код для оркестрации API, поддержки подписок на уведомления и получения уведомлений об изменениях через веб-перехватчики. Хотя это решение не требует эластичности, оно должно поддерживать пользователей в разных сетевых условиях и потенциально обрабатывать всплеск уведомлений об изменениях. Таким образом, это решение является очень сложным.