Application des modifications
Une fois que le fournisseur de destination a obtenu un lot de modifications et géré les conflits, les modifications doivent être appliquées au réplica de destination. Cette opération est en général effectuée dans la méthode ProcessChangeBatch (pour le code managé) ou ProcessChangeBatch (pour le code non managé) du fournisseur de destination, et peut être réalisée plus facilement en utilisant un objet d'applicateur de modifications fourni par Sync Framework.
Mode d'application des modifications
Après avoir obtenu le lot de modifications du fournisseur de source, le fournisseur de destination applique les modifications au réplica de destination. Un objet d'applicateur de modifications fourni par Sync Framework peut être obtenu en créant un objet NotifyingChangeApplier (pour le code managé) ou en appelant IProviderSyncServices::CreateChangeApplier (pour le code non managé). La méthode ApplyChanges (pour le code managé) ou ApplyChanges (pour le code non managé) détecte les conflits et appelle les méthodes sur le fournisseur de destination pour appliquer les modifications au réplica de destination.
Traitement d'un élément de modification
Pour traiter un élément de modification classique, l'applicateur de modifications fait d'abord appel à la méthode LoadChangeData (pour le code managé) ou ISynchronousDataRetriever::LoadChangeData (pour le code non managé) sur le fournisseur de source pour démarrer le transfert de données. Cette méthode retourne un objet object (pour le code managé) ou une interface IUnknown (pour le code non managé) qui représente le mécanisme de transfert de données. L'applicateur de modifications appelle ensuite la méthode SaveItemChange (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::SaveChange (pour le code non managé) sur le fournisseur de destination, et passe l'objet de transfert de données dans le cadre du contexte d'enregistrement des modifications. Le fournisseur de destination peut ensuite transférer les données au réplica de destination. Tous les échecs survenus lors de l'obtention des données ou du traitement des modifications sont indiqués en utilisant la méthode RecordRecoverableErrorForItem (pour le code managé) ou ISaveChangeContext::SetRecoverableErrorOnChange (pour le code non managé). Cette méthode enregistre une erreur récupérable pour cet élément dans l'objet de connaissance acquise contenu dans le lot de modifications.
Mise à jour de la connaissance acquise
Pendant que les modifications sont appliquées, l'applicateur de modifications met à jour la connaissance acquise contenue dans le lot de modifications. La connaissance acquise est la connaissance du réplica source projetée sur les modifications dans le lot de modifications, et représente ce que le réplica de destination apprend quand il applique toutes les modifications dans le lot de modifications. La connaissance acquise est mise à jour des façons suivantes :
Si un sous-ensemble de modifications uniquement a été appliqué en raison d'interruptions ou d'annulations, l'applicateur de modifications utilise l'opérateur de projection pour restreindre la connaissance au jeu de modifications appliquées uniquement.
Si l'application de certaines modifications a échoué, l'applicateur de modifications les exclut également de la connaissance.
Gardez à l'esprit que les implémenteurs de fournisseur n'ont pas à effectuer ces opérations de projection, d'union et d'exclusion manuellement. Cela est dû au fait que l'applicateur de modifications les effectue au nom du fournisseur.
Enregistrement de la connaissance de destination mise à jour
Une fois la connaissance acquise mise à jour, elle est associée à la connaissance du réplica de destination. Le fournisseur de destination doit remplacer atomiquement la connaissance du réplica de destination par cette connaissance. Cette atomicité peut être obtenue en enregistrant la connaissance mise à jour une seule fois par lot si toutes les modifications dans un lot sont appliquées en une transaction unique. L'applicateur de modifications apporte sa contribution en appelant la méthode StoreKnowledgeForScope (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (pour le code non managé) sur le fournisseur de destination à la fin de chaque lot. La connaissance passée à cette méthode est la connaissance mise à jour qui sera appliquée au réplica de destination. Le fournisseur de destination peut également appeler la méthode GetUpdatedDestinationKnowledge (pour le code managé) ou ISaveChangeContext::GetKnowledgeForScope (pour le code non managé) pour obtenir la connaissance mise à jour.
Lorsque les fournisseurs utilisent des unités de modification pour représenter des sous-éléments, il existe certaines différences dans la façon dont les modifications sont appliquées. Pour plus d'informations, consultez Synchronisation des unités de modification.
Considérations spéciales relatives aux réplicas hiérarchiques
La synchronisation des réplicas hiérarchiques peut rencontrer certaines complications provoquées par les jeux de modifications du traitement par lot de la source vers la destination. Sync Framework ne prend pas en charge le concept de hiérarchie de données. Par conséquent, il appartient aux fournisseurs de gérer correctement ces situations.
La complication la plus courante est l'ordre des relations entre parent et enfant dans les opérations de mise à jour. Imaginons, par exemple, le scénario suivant :
Le réplica source a créé un dossier et un jeu d'éléments à l'intérieur de celui-ci.
Le fournisseur de destination demande des modifications au fournisseur de source. Le fournisseur de source envoie sa liste de modifications dans deux lots. Toutefois, le lot de modifications qui contient la création du dossier parent arrive après le lot de modifications qui contient les éléments enfants.
Le fournisseur de destination doit décider de l'emplacement où stocker le jeu des éléments qui sont arrivés dans le premier lot, car les informations sur leur emplacement de stockage se trouvent dans le second lot.
Réduction des mises à jour hiérarchiques
En cas de mises à jour, la façon la plus simple de réduire les complexités liées aux relations parent/enfant consiste à demander au fournisseur de source de se charger du classement des ID globaux. De cette façon, les éléments parents arrivent toujours avant leurs éléments enfants.
Lorsque les fournisseurs de destination s'occupent de la transmission des mises à jour effectuées dans un magasin hiérarchique, ils peuvent recevoir des relations parent/enfant inexploitables. Les fournisseurs de destination doivent être en mesure de pallier cette situation en supprimant la modification inexploitable et en notant une exception dans leur connaissance, ou en mettant la modification en file d'attente pour l'appliquer ultérieurement. Dans la mesure où la taille des éléments peut être importante, le fait de supprimer la modification et de noter les exceptions de connaissance est probablement l'approche la plus efficace.
Réduction des suppressions hiérarchiques
Les fournisseurs de destination déterminent si un élément est un élément de conteneur. Pour les conteneurs vides, les suppressions peuvent se produire immédiatement. Toutefois, si le conteneur inclut des éléments qui n'ont pas été marqués pour suppression, le fournisseur a les options suivantes :
Mettre en file d'attente les suppressions pour traitement ultérieur. Une fois que tous les enfants du conteneur sont marqués pour suppression, la suppression réelle peut être déclenchée.
Supprimer cette demande et définir une exception dans la connaissance pour indiquer la réception inexploitable d'un élément.
Pour traiter les scénarios dans lesquels un parent est supprimé dans la hiérarchie, puis un enfant est ajouté, la règle suivante est observée : les suppressions en file d'attente sont valables uniquement jusqu'à la fin d'une session par paires et ne sont pas rendues persistantes entre les participants.
Voir aussi
Référence
Interface IProviderSyncServices
ISynchronousNotifyingChangeApplier::ApplyChanges
IAsynchronousNotifyingChangeApplier::ApplyChanges
ISynchronousNotifyingChangeApplierTarget::SaveKnowledge
IAsynchronousNotifyingChangeApplierTarget::SaveKnowledge
Interface ISynchronousDataRetriever
Interface IAsynchronousDataRetriever
ISyncKnowledge::ExcludeItem
ISyncKnowledge::Union
Interface ISaveChangeContext
NotifyingChangeApplier
ApplyChanges
StoreKnowledgeForScope
IChangeDataRetriever
ExcludeItem
Contains
SaveChangeContext
Concepts
Fournisseurs de synchronisation
Présentation de la connaissance de synchronisation