Microsoft Graph : synchroniser avec delta queries et change notifications

L’essentiel

Delta query est un modèle pull: le client parcourt les pages initiales, conserve @odata.deltaLink puis demande uniquement les changements. Les suppressions apparaissent selon la ressource et doivent être appliquées au store local.

Change notifications est un modèle push via webhook, Event Hubs ou Event Grid. Une subscription a une durée, doit être renouvelée et peut produire des lifecycle notifications telles que reauthorizationRequired, subscriptionRemoved ou missed.

La notification n’est pas une transaction exactly-once. Je valide authenticité et clientState, réponds rapidement, déduplique, puis utilise delta pour rattraper tout manque.

Delta query est un modèle pull: le client parcourt les pages initiales, conserve @odata.deltaLink puis demande uniquement les changements. Les suppressions apparaissent selon la ressource et doivent être appliquées au store local.

Pourquoi cette technologie existe

Le premier appel delta retourne des pages et finalement un deltaLink opaque. Je suis nextLink puis stocke deltaLink avec la partition, la version de schéma et l’heure.

Un token delta peut expirer ou devenir invalide. Le client accepte alors un resync complet contrôlé plutôt que d’ignorer définitivement les changements.

Une subscription définit resource, changeType, notificationUrl ou canal, expiration et éventuellement lifecycleNotificationUrl. Les durées maximales varient par ressource.

Delta queries et notifications Graph s’appuie sur la chaîne Resource → Subscription → Queue → Delta. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont ressource supportant delta/notifications, permissions minimales, endpoint HTTPS public ou Event Hubs/Grid, stockage chiffré des cursors. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Delta token invalide, Webhook non validé et Notifications dupliquées. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Resource ouvre la séquence: Produit créations, modifications et suppressions. Subscription prend ensuite le relais: Push signale rapidement un changement. Le traitement se poursuit avec Queue, où Valide, déduplique et absorbe les pics. Enfin, Delta ferme la boucle: Réconcilie le store avec deltaLink. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Delta token invalide » conduit d’abord à vérifier Status et cursor metadata, car la cause possible est Expiration/changement. Pour « Webhook non validé », la preuve utile devient Request et réponse. Les cas « Notifications dupliquées » et « SubscriptionRemoved » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Delta queries et notifications Graph expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions ressource supportant delta/notifications, permissions minimales, endpoint HTTPS public ou Event Hubs/Grid, stockage chiffré des cursors doivent être réunies en même temps. La validation porte ensuite sur Effectuer sync delta initial, Conserver nextLink/deltaLink atomiquement, Créer subscription et valider endpoint et Tester duplicate et out-of-order. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Le premier appel delta retourne des pages et finalement un deltaLink opaque. Je suis nextLink puis stocke deltaLink avec la partition, la version de schéma et l’heure.

Un token delta peut expirer ou devenir invalide. Le client accepte alors un resync complet contrôlé plutôt que d’ignorer définitivement les changements.

Une subscription définit resource, changeType, notificationUrl ou canal, expiration et éventuellement lifecycleNotificationUrl. Les durées maximales varient par ressource.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose ressource supportant delta/notifications, permissions minimales, endpoint HTTPS public ou Event Hubs/Grid, stockage chiffré des cursors, queue et déduplication. Ces conditions permettent de distinguer une limite de Delta queries et notifications Graph d’un scénario simplement non éligible.

• ressource supportant delta/notifications
• permissions minimales
• endpoint HTTPS public ou Event Hubs/Grid
• stockage chiffré des cursors
• queue et déduplication
• rotation clientState/credentials
• runbook resync

Cycle de fonctionnement, étape par étape

Le cycle de Delta queries et notifications Graph traverse Resource → Subscription → Queue → Delta. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Delta queries et notifications Graph, les étapes « Identifier les composants », « Suivre le flux », « Lire les états », « Valider le fonctionnement » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé et frontières de responsabilité

Le premier appel delta retourne des pages et finalement un deltaLink opaque. Je suis nextLink puis stocke deltaLink avec la partition, la version de schéma et l’heure.

Un token delta peut expirer ou devenir invalide. Le client accepte alors un resync complet contrôlé plutôt que d’ignorer définitivement les changements.

Une subscription définit resource, changeType, notificationUrl ou canal, expiration et éventuellement lifecycleNotificationUrl. Les durées maximales varient par ressource.

• ressource supportant delta/notifications
• permissions minimales
• endpoint HTTPS public ou Event Hubs/Grid
• stockage chiffré des cursors

Mise en œuvre, exploitation et cas limites

Le webhook répond au validationToken lors de la création puis vérifie clientState et jetons/signatures requis. Il accuse réception rapidement et traite ensuite dans une queue.

Les notifications peuvent être dupliquées, retardées ou manquées. L’idempotence utilise ressource, changeType, séquence/heure et état courant, jamais l’hypothèse exactly-once.

Lors de missed ou subscriptionRemoved, je renouvelle/récrée et lance un delta ou resync pour la fenêtre. Le monitoring alerte avant expiration et sur la profondeur de queue.

• Tester missed/subscriptionRemoved
• Renouveler avant expiration
• Comparer store à un full sync témoin

Méthode de validation à l’échelle du parc

Pour delta queries et notifications graph, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Les mesures portent sur Effectuer sync delta initial. Conserver nextLink/deltaLink atomiquement. Créer subscription et valider endpoint. Tester duplicate et out-of-order. Elles sont définies avant le pilote de Delta queries et notifications Graph afin que les seuils ne soient pas déplacés après l’observation.

Les cas « Delta token invalide », « Webhook non validé », « Notifications dupliquées », « SubscriptionRemoved » servent de scénarios négatifs. Ils vérifient que l’échec reste visible, localisable et associé à une correction précise.

La généralisation de Delta queries et notifications Graph tient compte de deltaLink est opaque et sensible, durées varient par ressource, ne pas traiter lourdement dans webhook, beta uniquement avec dérogation. Chaque vague se ferme après lecture de ces points et validation du retour à l’état connu.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Effectuer sync delta initial. Conserver nextLink/deltaLink atomiquement. Créer subscription et valider endpoint. Tester duplicate et out-of-order. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Delta queries et notifications Graph, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
 $uri='https://graph.microsoft.com/v1.0/users/delta?$select=id,displayName,userPrincipalName'
 do {
   $page=Invoke-MgGraphRequest -Method GET -Uri $uri
   $page.value | Select-Object id,displayName,userPrincipalName
   $uri=$page.'@odata.nextLink'
   if(-not $uri){$deltaLink=$page.'@odata.deltaLink'}
 } while($uri)
 [pscustomobject]@{DeltaLinkReceived=[bool]$deltaLink}
}
catch { Write-Error "Delta Graph impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de Delta queries et notifications Graph relie Resource, Subscription, Queue, Delta. Les heures et identifiants communs indiquent si les informations décrivent la même tentative.

Les états sont lus à partir de Effectuer sync delta initial. Conserver nextLink/deltaLink atomiquement. Créer subscription et valider endpoint. Tester duplicate et out-of-order. Cette séquence sépare une absence de configuration d’un traitement en attente ou d’un échec confirmé.

Les causes « Expiration/changement », « validationToken/TLS », « At-least-once », « Autorisation/lifecycle » restent des hypothèses jusqu’à ce que la preuve indiquée dans la matrice les confirme.

• Effectuer sync delta initial.
• Conserver nextLink/deltaLink atomiquement.
• Créer subscription et valider endpoint.
• Tester duplicate et out-of-order.
• Tester missed/subscriptionRemoved
• Renouveler avant expiration
• Comparer store à un full sync témoin

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Effectuer sync delta initial, Conserver nextLink/deltaLink atomiquement, Créer subscription et valider endpoint et Tester duplicate et out-of-order. Ces contrôles relient la configuration du service au résultat réellement observé.

• Effectuer sync delta initial.
• Conserver nextLink/deltaLink atomiquement.
• Créer subscription et valider endpoint.
• Tester duplicate et out-of-order.
• Tester missed/subscriptionRemoved
• Renouveler avant expiration
• Comparer store à un full sync témoin

Limites, modes de panne et lecture des erreurs

Les écarts connus de Delta queries et notifications Graph incluent Delta token invalide, Webhook non validé, Notifications dupliquées, SubscriptionRemoved. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Delta queries et notifications Graph commence sur le périmètre Microsoft Graph, Delta query, Change notifications, Endpoint & Automation — Resource, Subscription, Queue, Delta, ressource supportant delta/notifications, permissions minimales, endpoint HTTPS public ou Event Hubs/Grid. Les limites et actions de réversibilité ci-dessous cadrent la progression.