Énumération des modifications

Article
10/17/2009

Lorsqu'un fournisseur de source répond à une demande GetChangeBatch (pour le code managé) ou IKnowledgeSyncProvider::GetChangeBatch (pour le code non managé), sa tâche consiste à générer un lot de modifications inconnues du réplica de destination. Le fournisseur de source détermine les éléments du réplica source qui ne se trouvent pas dans l'objet de connaissance envoyé par le fournisseur de destination, puis retourne un lot de ces éléments.

Chaque lot de modifications est composé des informations suivantes :

Les ID globaux et les versions pour les éléments modifiés.
Les objets tombstone que le réplica de destination doit connaître.
La connaissance courante. Il s'agit de la connaissance du réplica source lorsque des modifications sont apportées. Sync Framework calcule la connaissance acquise pour la destination à partir de la connaissance courante lorsque le fournisseur de destination applique les modifications.
La connaissance préalable. Il s'agit de la connaissance minimum qu'un réplica de destination doit avoir afin de traiter ce lot de modifications. Si la connaissance du réplica de destination ne contient pas la connaissance préalable, il ne peut pas traiter ces modifications.
La connaissance oubliée du réplica source. Elle est utilisée pour détecter un réplica de destination obsolète.

Modifier l'énumération entre deux réplicas

Cette section fournit un scénario qui décrit le processus d'énumération des modifications entre deux réplicas en utilisant les interfaces de connaissance Sync Framework.

Notes

Un réplica est chargé de garantir que les modifications apportées localement se reflètent dans sa connaissance avant qu'un fournisseur énumère les modifications. Cela peut être obtenu en mettant à jour la connaissance lorsqu'une modification locale est apportée ou en faisant une passe de maintenance des métadonnées avant l'énumération des modifications.

Dans ce scénario, un fournisseur de destination demande des modifications au fournisseur de source. L'ordre de la demande est le suivant :

Le réplica de destination garantit que toutes les modifications apportées localement sont répercutées dans sa connaissance pour l'étendue qui sera synchronisée avec le réplica source.
Le fournisseur de destination envoie la connaissance du réplica de destination au fournisseur de source. Le fournisseur de source reçoit la connaissance via la méthode GetChangeBatch (pour le code managé) ou IKnowledgeSyncProvider::GetChangeBatch (pour le code non managé).
Pour générer un lot de modifications, le fournisseur de source énumère les modifications et les suppressions dans le réplica source et vérifie chacune d'elle par rapport à la connaissance du réplica de destination. Une modification n'est ajoutée au lot de modifications que lorsqu'elle n'est pas contenue dans la connaissance du réplica de destination. Le lot de modifications est représenté par l'objet ChangeBatch (pour le code managé) ou l'interface ISyncChangeBatch (pour le code non managé).
Le fournisseur de source retourne le lot de modifications au fournisseur de destination.

Notes

Potentiellement, un ensemble de modifications peut contenir de nombreuses modifications. Pour permettre au fournisseur de destination de traiter les modifications entrantes, il peut demander à ce que les modifications soient envoyées par lots en retournant un nombre différent de zéro pour la taille du lot dans sa méthode GetSyncBatchParameters (pour le code managé) ou GetSyncBatchParameters (pour le code non managé).

Lorsque le fournisseur de source utilise des unités de modification pour représenter des sous-éléments énumérés à partir du réplica source, il envoie uniquement les unités de modification qui ont changé, au lieu de l'élément entier. Pour plus d'informations, consultez Synchronisation des unités de modification.

Gestion de modifications obsolètes

Lorsqu'un lot de modifications est construit, les modifications obsolètes sont automatiquement exclues. Une modification obsolète est une modification qui est déjà contenue dans la connaissance du réplica de destination et qui ne doit pas s'appliquer au réplica de destination. Lorsqu'une modification est ajoutée à un lot de modifications, Sync Framework compare la version de la modification avec la connaissance du réplica de destination et ajoute la modification uniquement si elle n'est pas contenue dans la connaissance du réplica de destination. Cela produit un lot de modifications minimal et permet à un fournisseur d'implémenter un algorithme plus simple pour énumérer les modifications, tel qu'un algorithme basé sur un nombre de cycles.

Un fournisseur peut vérifier lui-même que les modifications qu'il ajoute à un lot de modifications ne sont pas obsolètes. Pour ce faire, le fournisseur détermine si l'ID global et la version de la modification sont contenus dans la connaissance du réplica de destination. Cela est réalisé en utilisant la méthode Contains (pour le code managé) ou ISyncKnowledge::ContainsChange (pour le code non managé). Si la connaissance ne contient pas la modification, le fournisseur l'ajoute au lot de modifications. Cela produit un lot de modifications minimal et est utile pour les fournisseurs qui souhaitent obtenir un contrôle total sur la construction de lot de modifications.