Microsoft Graph を使用してデータ変更のリアルタイム更新プログラムを取得する
この記事では、モバイル アプリがMicrosoft Teamsからほぼリアルタイムで共有メッセージの読み取り専用フィードを受信するためのエンタープライズ コラボレーションの強化を提供するビジネス シナリオの一般的な Microsoft Graph 統合パターンについて説明します。
このシナリオは、外部イベントによってトリガーされるデータの変更に依存する非対話型のユース ケースであり、次のアーキテクチャ要件があります。
- データ統合の種類。
- Microsoft 365 境界からアプリへの送信データ フロー。
- 人間の操作あたりのデータ量は少ないが、ユーザーの数によってはデータ量が多くなる可能性がある。
- 最新のフィードを生成するためのほぼリアルタイムのデータ待機時間。
このシナリオに最適な統合オプションは、Microsoft Graph の変更通知を使用することです。これにより、イベント通知と共有メッセージの内容を配信し、Webhook を実装できます。 クライアント アプリは、クライアント シークレットと暗号化キーを提供し、Microsoft Graph 通知サービスが変更を投稿する HTTP エンドポイントを公開します。 クライアント アプリは、同期 Microsoft Graph 要求を受け入れて迅速に応答でき、メッセージを生成する他のクライアントによってトリガーされるイベントを処理するようにスケーリングできます。 この種類のアプリ操作は、プッシュ モードと呼ばれます。
次の図は、このソリューションのアーキテクチャを示しています。
ソリューション コンポーネント
ソリューション アーキテクチャには、次のコンポーネントが含まれています。
- Azure App Serviceを使用すると、インフラストラクチャを管理することなく、任意のプログラミング言語で Web アプリ、モバイル バックエンド、RESTful API を構築およびホストできます。 自動スケーリングと高可用性を提供し、Windows と Linux の両方をサポートし、GitHub、Azure DevOps、または任意の Git リポジトリからの自動デプロイを可能にします。
- Microsoft Entra ID。これは Microsoft Graph API の認証を管理するために必要であり、OAuth フローを有効にするために委任されたアクセス許可とアプリケーションのアクセス許可をサポートします。
- 関数アプリは、大量の通知をスケーリングできるサーバーレス コンポーネントであり、通知を処理して宛先サービスに送信するビジネス ロジックを備えています。
- Simple Storage Queue。関数アプリのインスタンスによる非同期処理の前に通知を永続化することで、アプリ サービスからの負荷を削減するのに役立ちます。
- Azure Application Gateway。Web セキュリティとルーティング機能を提供します。
- 通知サブスクリプションを管理し、クライアントに変更通知を配信する Microsoft Graph 通知サービス。
考慮事項
次の考慮事項は、この統合パターンの使用をサポートします。
可用性: Microsoft Graph は、共有チャネルまたはチャットで新しいメッセージが発行されるたびに、クライアント Webhook を呼び出します。 Webhook には、1 日を通して、または完全な 24 時間の高可用性が必要です。
待機時間: Webhook は、3 秒以内に Microsoft Graph 通知要求を確認する必要があります。 この時間内に Microsoft Graph が 200 クラス コードを受け取らない場合、変更通知は最大 4 時間、複数回再送信されます。
スケーラビリティ: クライアント Webhook は、1 日の任意の時点で大量の通知をスケーリングできる必要があります。 これを行うには、アプリ サービスにインスタンスを追加し、より多くの関数アプリ インスタンスをインスタンス化して、移行先サービスを迅速に更新します。
ソリューションの複雑さ: Webhook ソリューションでは、サブスクリプションを維持するためのカスタム コードと、データを処理するための暗号化キーも必要です。 このソリューションは、関連するコンポーネントの数とスケーラビリティと可用性の要件により、非常に複雑です。