Microsoft Graph API を使用して対話型アプリを構築する
この記事では、チャネル メッセージをリアルタイムで作成、更新、管理できる UI を必要とするビジネス シナリオの一般的な Microsoft Graph 統合パターンについて説明します。 このシナリオは、さまざまなチームからのメッセージの送受信など、Microsoft 365 サービスによって異なります。
このシナリオには、次のアーキテクチャ要件があります。
- 複雑な Microsoft 365 機能に依存しているため、アプリケーション統合の種類。
- アプリと Microsoft 365 の間の双方向データ フロー。
- 単一の人間の介入に基づく自動システムと比較して、データ量が少ない。 ただし、ユーザーの数によっては、データ ボリュームが大きい場合があります。
- リモート クライアントに電子メールを配信するなど、サーバー側の非同期操作を伴う、アプリでのリアルタイム データ操作。
このアプリケーションの最適な選択は、Microsoft Graph RESTful HTTP API を使用することです。 クライアント アプリはユーザーのアクションに応答し、クライアント環境によって制御される速度で要求を行い、データを処理できます。
次の図は、このソリューションのアーキテクチャを示しています。
ソリューション コンポーネント
ソリューション アーキテクチャには、次のコンポーネントが含まれています。
- Azure App Service。これにより、インフラストラクチャを管理することなく、任意のプログラミング言語で Web アプリ、モバイル バックエンド、RESTful API を構築およびホストできます。 自動スケーリングと高可用性を提供し、Windows と Linux の両方をサポートし、GitHub、Azure DevOps、または任意の Git リポジトリからの自動デプロイを可能にします。
- Microsoft Entra IDは、Microsoft Graph API の認証を管理するために必要であり、OAuth フローを有効にするために委任されたアクセス許可とアプリケーションのアクセス許可をサポートしています。
- SQL Databaseは、アプリケーション データと状態を格納するために使用されます。このコンポーネントは省略可能です。
- 単一のエンドポイントを介してアクセスされる Microsoft Graph RESTful API:
https://graph.microsoft.com。 - カスタム ロジックを実装するアプリ。
考慮事項
次の考慮事項は、この統合パターンの使用をサポートします。
可用性: クライアント アプリは、データの Microsoft Graph API を定期的にポーリングします。 クライアント アプリは、要求を行い、クライアント環境によって制御される速度でデータを処理できます。
待機時間: クライアント アプリは、Microsoft Graph API に対してリアルタイムでデータを照会します。ただし、ネットワークの状態と Microsoft Graph サービスの負荷によっては、待機時間が発生する可能性があります。
スケーラビリティ: クライアント アプリは、App Service プランにインスタンスを追加することで水平方向にスケーリングできます。 Microsoft Graph API は多数の要求を処理できますが、不正使用を防ぐための調整制限とポリシーもあります。 調整エラーを適切に処理するには、クライアント アプリで再試行ロジックと指数バックオフを実装する必要があります。
ソリューションの複雑さ: このソリューションでは Microsoft Graph SDK を使用する場合がありますが、データをポーリングして処理するにはカスタム コードが必要です。 データ ボリュームが大きい場合は、シーケンシャル処理だけでは十分でない可能性があり、並列処理が必要な場合があります。 このため、このソリューションには中程度の複雑さがあります。