リアルタイム フィードを使用して対話型 Microsoft Graph アプリを構築する
この記事では、Microsoft 365 電子メール サービスのデータと機能に依存するビジネス シナリオの一般的な Microsoft Graph 統合パターンについて説明します。 Microsoft Graph API を使用して、データの読み取り、電子メール操作の呼び出し、WebSocket チャネルを介した Webhook を使用した Microsoft Graph 変更通知の受信を行います。 このシナリオには、次のアーキテクチャ要件があります。
- アプリケーション統合の種類。
- Microsoft 365 とアプリ間の双方向データ フロー。
- 1 人のユーザーにサービスを提供する低いデータ ボリューム。
- プッシュ通知に許容される中程度のデータ待機時間。
このパターンでは、API、変更通知、必要に応じて変更追跡 API など、複数の Microsoft Graph 統合オプションが使用されます。 WebSocket 経由で変更通知を受け取るために、アプリは SignalR SDK を使用します。これにより、WebSocket 管理が抽象化され、簡略化されます。
次の図は、このソリューションのアーキテクチャを示しています。
ソリューション コンポーネント
ソリューション アーキテクチャには、次のコンポーネントが含まれています。
- Microsoft Entra ID。これは Microsoft Graph API の認証を管理するために必要であり、OAuth フローを有効にするために委任されたアクセス許可とアプリケーションのアクセス許可をサポートします。
- 通知サブスクリプションを管理し、クライアント アプリに変更通知を配信する Microsoft Graph 通知サービス。
- 単一のエンドポイントを介してアクセスされる Microsoft Graph RESTful API:
https://graph.microsoft.com。 - カスタム ロジックと Webhook を実装し、Microsoft Graph と通信するカスタム モバイル アプリ。
考慮事項
次の考慮事項は、この統合パターンの使用をサポートします。
可用性: カスタム アプリはエッジ デバイスで高可用性であり、信頼性の高いインターネット接続が利用できない場合はオフライン モードをサポートできます。
待機時間: Microsoft Graph RESTful HTTP API は通常、1 秒以内に応答しますが、全体的な待機時間はインターネット接続速度によって異なります。 Microsoft Graph 通知は変更後数秒で生成されますが、配信はインターネット接続、モバイル ベンダーの SLA、Webhook の可用性によって異なります。
スケーラビリティ: Microsoft Graph サービスは非常にスケーラブルで地理的に分散されており、何百万ものクライアントに対する要求と通知をサポートしています。
ソリューションの複雑さ: このソリューションでは、API の調整、通知サブスクリプションの維持、Webhook 経由での変更通知の受信を行うカスタム コードが必要です。 このソリューションでは弾力性は必要ありませんが、さまざまなネットワーク条件下のユーザーをサポートし、変更通知のバーストを処理する可能性があります。 したがって、このソリューションは非常に複雑です。