サブスクリプションと変更通知の消失を減らす
サブスクリプションの有効期間中に、Microsoft Graph から特別な種類の通知が送信され、サブスクリプションの欠落や変更通知のリスクを最小限に抑えることができます。 これらの通知はライフサイクル 通知と呼ばれます。
ライフサイクル イベントには、次の 3 種類があります。
- reauthorizationRequired 通知
- サブスクリプション が削除された 通知
- 見逃した 通知
これらのイベントを無視すると、変更通知フローが中断される可能性があります。イベントを処理するには、アプリにロジックを実装して継続的な変更通知フローを再開します。
この記事では、Microsoft Graph の変更通知のライフサイクル通知について説明し、通知を処理するためのガイダンスを提供します。
サポートされているリソース
任意のリソースの種類でサブスクリプションを作成するときに lifecycleNotificationUrl を 指定できますが、ライフサイクル通知は現在、次のリソースの種類でのみサポートされています。
- reauthorizationRequired 通知 - すべてのリソース
- subscriptionRemoved 通知 - Outlook メッセージ、Outlook イベント、Outlook 個人用 連絡先、Teams chatMessage
- 不在通知 - Outlook メッセージ、Outlook イベント、Outlook 個人用 連絡先
ライフサイクル通知を受信するようにサブスクリプションを構成する
ライフサイクル通知を受信するには、サブスクリプションの作成時に有効な ライフサイクルNotificationUrl エンドポイントを指定する必要があります。
次のサブスクリプション作成要求は、 notificationUrl エンドポイントと lifecycleNotificationUrl エンドポイントの両方を定義します。
POST https://graph.microsoft.com/v1.0/subscriptions
Content-Type: application/json
{
"changeType": "created,updated",
"notificationUrl": "https://webhook.azurewebsites.net/api/resourceNotifications",
"lifecycleNotificationUrl": "https://webhook.azurewebsites.net/api/lifecycleNotifications",
"resource": "/users/{id}/messages",
"expirationDateTime": "2020-03-20T11:00:00.0000000Z",
"clientState": "<secretClientState>"
}
lifecycleNotificationUrl エンドポイントは notificationUrl と同じにすることができます。
lifecycleNotificationUrl プロパティを持たない既存のサブスクリプションは、ライフサイクル通知を受け取りません。 lifecycleNotificationUrl プロパティを追加するには、サブスクリプションの作成時にプロパティを指定しながら、そのような既存のサブスクリプションを削除し、新しいサブスクリプションを作成する必要があります。
Webhooks 配信チャネルを使用する場合は、 両方のエンドポイントを検証する必要があります。
ライフサイクル通知の構造
ライフサイクル通知ペイロードは、 changeNotificationCollection と関連する changeNotification リソースの種類の構造に従います。
{
"value": [
{
"subscriptionId":"<subscription_guid>",
"subscriptionExpirationDateTime":"2019-03-20T11:00:00.0000000Z",
"tenantId": "<tenant_guid>",
"clientState":"<secretClientState>",
"lifecycleEvent": "subscriptionRemoved or missed or reauthorizationRequired"
}
]
}
ライフサイクル通知の種類を表す lifecycleEvent には subscriptionRemoved
、 missed
または reauthorizationRequired
を指定できます。
ライフサイクル通知には、特定のリソースに関する情報は含まれません。これは、リソースの変更ではなく、サブスクリプションの状態の変更に関連するためです。 変更通知と同様に、ライフサイクル通知はまとめてバッチ処理し、それぞれ異なる lifecycleEvent 値を持つコレクションとして受信できます。 バッチ内の各ライフサイクル通知を適切に処理します。
ライフサイクル通知を処理し、変更通知のフローを再開すると、変更通知は notificationUrl へのフローを開始します。
reauthorizationRequire 通知に応答する
reauthorizationRequired
ライフサイクル イベントでは、Microsoft Graph でアプリがサブスクリプションを再認証する必要があるときにアラートが表示されます(たとえば、次の場合)。
- アクセス トークンの有効期限が切れようとしている場合。
- サブスクリプションの 有効期限が切れようとしている場合。
- テナント管理者がリソースを読み取るアプリのアクセス許可を取り消したとき。
これらの条件のいずれかが満たされる前に、Microsoft Graph は承認チャレンジを lifecycleNotificationUrl に送信します。
次のコード サンプルは、Microsoft Graph 変更通知サービスがこれらの通知の間隔を計算する方法を示しています。
//The following code is for illustrative purposes only
var TokenTimeToExpirationInMinutes=(TokenExpirationTime-CurrentTime)/4;
if((TokenTimeToExpirationInMinutes)<=180 && TokenTimeToExpirationInMinutes>60){
//Microsoft Graph will send reauthorizationRequired notification
TokenTimeToExpirationInMinutes=TokenTimeToExpirationInMinutes/2;
}
elseif(TokenTimeToExpirationInMinutes<60 && TokenTimeToExpirationInMinutes>=0){
//Microsoft Graph will send reauthorizationRequired notification every 15 mins
TokenTimeToExpirationInMinutes=TokenTimeToExpirationInMinutes-15;
} else {
//Microsoft Graph will stop sending reauthorizationRequired notifications
}
アクティブな、有効期限が切れていないサブスクリプションの承認チャレンジのフローは、次のようになります。
Microsoft Graph によりサブスクリプションの再認証が要求されます。
理由はリソースによって異なる場合があり、時間の経過と伴って変化する可能性があります。 サブスクリプションを維持するには、その原因に関係なく、再認証イベントに応答する必要があります。
Microsoft Graph により承認チャレンジ通知が lifecycleNotificationUrl に送信されます。
変更通知のフローはしばらく続く可能性があり、追加の応答時間が与えられます。 ただし、ユーザーが必要なアクションを実行するまで、最終的には変更通知の配信は一時停止されます。 変更通知の配信が一時停止したときに発生するリソースの変更に関する通知と、アプリがサブスクリプションを正常に再作成した時刻は失われます。 このような場合、 アプリでは、差分クエリを使用するなど、これらの変更を個別にフェッチする必要があります。
必要なアクション
応答コードを使用して POST 呼び出しに応答することで、ライフサイクル通知の受信を
202 - Accepted
確認します。ライフサイクル通知の真正性を検証します。
次の手順に進むために有効なアクセス トークンがアプリにあることを確認します。
次の 2 つの API のいずれかを呼び出します。 API 呼び出しが成功した場合、変更通知のフローが再開されます。
有効期限を
/reauthorize
延長せずにサブスクリプションを再認証するには、アクションを呼び出します。POST https://graph.microsoft.com/v1.0/subscriptions/{id}/reauthorize
サブスクリプションを再認証して同時に更新するには 、 通常の "更新" アクションを実行します。
PATCH https://graph.microsoft.com/v1.0/subscriptions/{id} Content-Type: application/json { "expirationDateTime": "2019-09-21T11:00:00.0000000Z" }
アプリがリソースへのアクセスを許可されなくなった場合、更新が失敗する可能性があります。 その後、アプリが新しいアクセス トークンを取得してサブスクリプションを正常に再認証することが必要になる場合があります。
これらのアクションはいつでも再試行できます。アクセスの条件に変更があった場合は、成功する場合があります。
追加情報
承認チャレンジは、サブスクリプションの有効期限が切れる前にサブスクリプションを更新する必要性に取って代わるわけではありません。 アクセス トークンとサブスクリプションの有効期限のライフサイクルは同じではありません。 アクセス トークンは、サブスクリプションの前に有効期限が切れる可能性があります。 アクセス トークンを更新するために、エンドポイントを定期的に再認証する準備をすることが重要です。 エンドポイントを再認証した場合、サブスクリプションは更新されません。 ただし、 サブスクリプションを更新 すると、エンドポイントも再認証されます。
承認チャレンジの頻度は、変更される場合があります。
承認チャレンジの頻度を想定しないでください。 これらのライフサイクル通知では、アクションを実行するタイミングが示されるため、再認証が必要なサブスクリプションを追跡する必要はありません。 すべてのサブスクリプションに対して数分に 1 回から、一部のサブスクリプションではほとんど承認の課題に対処する準備をしてください。
SubscriptionRemoved 通知に応答する
subscriptionRemoved
ライフサイクル イベントは、Microsoft Graph がサブスクリプションを削除したときにアラートを生成します。 このような場合、関連リソースの変更通知を引き続き受信する場合は、サブスクリプションを再作成する必要があります。
有効期間の長いサブスクリプションがある場合でも、リソース データへのアクセス条件は時間の経過と同時に変化する可能性があります。 たとえば、アプリがユーザーを再認証する必要があるサービス内のイベントが発生する可能性があります。 このような場合、Microsoft Graph から サブスクリプションの更新通知が送信されます 。
次のフローは、 subscriptionRemoved イベントのフローを示しています。
サービスは、Microsoft Graph からサブスクリプションを削除する必要があることを検出します。
これらのイベントに対して設定された頻度はありません。 イベントが頻繁に発生するリソースもあれば、ほとんど発生しないリソースもあります。
Microsoft Graph は
subscriptionRemoved
ライフサイクル通知を lifecycleNotificationUrl (指定されている場合) に送信します。ライフサイクル通知が送信された期間から、アプリがサブスクリプションを
subscriptionRemoved
正常に再作成した時点まで、ライフサイクル通知は使用できません。 アプリは、それらの変更を独自にフェッチする必要があります。
必要なアクション
応答コードを使用して POST 呼び出しに応答することで、ライフサイクル通知の受信を
202 - Accepted
確認します。ライフサイクル通知の真正性を検証します。
次の手順に進むために有効なアクセス トークンがアプリにあることを確認します。
新しいサブスクリプションを作成します。
このアクションは失敗する可能性があります。これは、システムによって実行される承認チェックによって、リソースへのアプリ アクセスが拒否される可能性があるためです。 サブスクリプションを正常に再認証するために、アプリが新しいアクセス トークンを取得することが必要な場合があります。 アクセス条件に変更があった場合などは、これらのアクションはいつでも再試行できます。
新しいサブスクリプションを作成した後、リソース データを同期して、見逃した変更通知を特定できます。たとえば、 デルタ クエリを使用します。
受信できなかった通知への応答
missed
ライフサイクル イベントでは、一部の変更通知が配信されていない可能性があることを警告します。 たとえば、 調整が原因です。
必要なアクション
- 応答コードを使用して POST 呼び出しに応答することで、ライフサイクル通知の受信を
202 - Accepted
確認します。 - ライフサイクル通知の真正性を検証します。
- リソースの完全なデータ再同期を実行して、通知として配信されなかった変更を特定します。たとえば、 デルタ クエリを使用します。