Synchronisation des unités de modification
Une unité de modification représente une modification de sous-élément, telle que le champ de numéro de téléphone dans un élément qui représente une carte de visite. En utilisant des unités de modification, les fournisseurs peuvent synchroniser des modifications de sous-éléments plus efficacement. Quelques exemples des fournisseurs qui peuvent tirer parti des unités de modification sont les fournisseurs de gestionnaire d'informations personnelles et ceux qui gèrent des images avec leurs métadonnées.
Unités de modification
Les unités de modification permettent aux modifications de sous-éléments compacts d'être représentées et offrent un meilleur suivi des modifications. Cela peut réduire le nombre de conflits déclenchés lorsque des modifications sont apportées à l'élément.
Imaginez un élément qui représente une carte de visite rendue persistante dans un système de fichiers. Si la granularité du suivi des modifications est au niveau de l'élément (fichier), toute modification apportée au fichier est une modification d'élément et toutes les données du contact doivent être transférées. En utilisant des unités de modification, un fournisseur peut décider à la place de détecter les modifications et de résoudre les conflits de données au niveau des propriétés du contact, telles que son prénom, son nom et son numéro de téléphone. Dans ce cas, si deux réplicas modifient indépendamment différentes propriétés sur un contact, par exemple si l'un modifie l'adresse de messagerie et qu'un autre joint une image, aucun conflit n'est détecté au niveau de l'élément et seules les données de l'unité de modification doivent être envoyées.
L'ensemble des unités de modification forme efficacement un schéma dans lequel l'ordre des unités de modification est décidé par les réplicas qui synchronisent un schéma particulier. Par exemple, les réplicas peuvent décider de représenter les propriétés de contact comme suit :
Change Unit[0] = First Name
Change Unit[1] = Last Name
Change Unit[2] = Phone Number
Suppression des unités de modification
La durée d'une unité de modification est liée à la durée de l'élément. Contrairement aux éléments de modification standard, les unités de modification ne peuvent pas être supprimées parce que les réplicas ont accepté qu'elles représentent les propriétés d'un élément.
Ajout d'unités de modification
Les fournisseurs ne doivent pas essayer de créer spontanément des unités de modification, car des effets indésirables peuvent se produire.
Les unités de modification peuvent être ajoutées selon des mises à jour de schéma qui se produisent hors bande avec une synchronisation des données. Pour une réussite de cette opération, les unités de modification ajoutées doivent avoir une valeur null ou une valeur par défaut acceptée par tous les réplicas. La version de mise à jour pour les unités de modification ajoutées sera alors la version de création de l'élément jusqu'à ce que ces unités de modification soient modifiées. En traitant les ajouts d'unités de modification de cette manière, elles apparaissent aux composants d'application de la même façon qu'une unité de modification qui existe depuis toujours et n'a jamais été modifiée.
Énumération des modifications d'unité de modification
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. Gardez à l'esprit que, lorsqu'un élément contient des unités de modification, les informations de version sont conservées uniquement pour chaque unité de modification et pas pour l'élément lui-même.
Énumération des modifications d'unité de modification en utilisant le code managé
Pour déterminer les unités de modification à envoyer, le fournisseur de source utilise la méthode Contains ou Contains de l'objet SyncKnowledge du fournisseur de destination. Si une modification d'unité de modification n'est pas contenue dans la connaissance de destination, la modification doit être incluse dans le lot de modifications envoyé par le fournisseur de source.
Les modifications d'unité de modification sont contenues dans les modifications d'élément ajoutées au lot de modifications. L'objet ItemChange peut être créé pour contenir les modifications d'unité de modification en utilisant le constructeur ItemChange ou celles-ci peuvent être ajoutées en utilisant AddChangeUnitChange.
Énumération des modifications d'unité de modification en utilisant le code non managé
Pour déterminer les unités de modification à envoyer, le fournisseur de source utilise la méthode ISyncKnowledge::ContainsChangeUnit de l'objet ISyncKnowledge du fournisseur de destination. Si une modification d'unité de modification n'est pas contenue dans la connaissance de destination, elle doit être incluse dans le lot de modifications envoyé par le fournisseur de source.
Les modifications d'unité de modification sont contenues dans les modifications d'élément ajoutées au lot de modifications. Pour ajouter des modifications d'unité de modification, spécifiez une valeur différente de NULL pour le paramètre ppChangeBuilder de la méthode ISyncChangeBatchBase::AddItemMetadataToGroup. L'objet ISyncChangeBuilder retourné peut alors être utilisé pour ajouter des modifications d'unité de modification à la modification d'élément associée en utilisant ISyncChangeBuilder::AddChangeUnitMetadata.
Traitement des modifications d'unité de modification
Lorsque le fournisseur de destination utilise un applicateur de modifications pour mieux traiter un lot de modifications dans sa méthode ProcessChangeBatch (pour le code managé) ou IKnowledgeSyncProvider::ProcessChangeBatch (pour le code non managé), il énumère les informations de version de destination pour chaque modification reçue du fournisseur de source. Quand une modification de la source contient des modifications d'unité de modification, le fournisseur de destination doit déterminer, le cas échéant, les versions d'unité de modification à inclure dans le lot des versions de destination. Cette décision dépend du type de modification du fournisseur de source et du fait que l'élément est marqué ou pas comme supprimé sur le réplica de destination. Le tableau suivant affiche les informations de version que le fournisseur de destination doit envoyer à l'applicateur de modifications.
|
La modification de la source est une suppression |
La modification de la source est une mise à jour |
L'élément de destination est supprimé |
Version de l'élément de destination uniquement. Les suppressions ne sont autorisées que sur des éléments entiers. Par conséquent, les informations de version pour une suppression font l'objet d'un suivi pour l'élément. |
Version de l'élément de destination uniquement. Les suppressions ne sont autorisées que sur des éléments entiers. Par conséquent, les informations de version pour une suppression font l'objet d'un suivi pour l'élément. |
L'élément de destination n'est pas supprimé |
Toutes les versions d'unité de modification de destination. |
Versions d'unité de modification de destination uniquement pour les unités de modification énumérées à partir de la source. |
Gestion des conflits qui contiennent des unités de modification
Lorsqu'une application utilise la résolution de conflit personnalisée pour les modifications qui contiennent des unités de modification, elle doit en général définir l'action de résolution de conflit pour le conflit d'unité de modification en utilisant SetResolutionAction (pour le code managé) ou IChangeConflict::SetResolveActionForChangeUnit (pour le code non managé).
Toutefois, lorsque le conflit est provoqué par une mise à jour sur un réplica et une suppression sur l'autre réplica, l'application doit spécifier l'action de résolution de conflit pour le conflit d'élément en utilisant SetResolutionAction (pour le code managé) ou IChangeConflict::SetResolveActionForChange (pour le code non managé).
Application des modifications d'unité de modification
En général, lorsqu'une modification contient des unités de modification, Sync Framework appelle SaveChangeWithChangeUnits (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (pour le code non managé) pour appliquer la modification au réplica de destination. Toutefois, lorsqu'un conflit s'est produit et a été résolu afin que l'élément soit supprimé, Sync Framework appelle SaveItemChange (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::SaveChange (pour le code non managé). Cela est dû au fait que seuls les éléments entiers peuvent être supprimés et non les unités de modification individuelles.