Application des modifications

Article
08/18/2010

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. D'autre part, lorsque des conflits de contraintes sont utilisés, appelez RecordConstraintConflictForItem (pour le code managé) ou ISaveChangeContext2::SetConstraintConflictOnChange (pour le code non managé) afin de signaler un conflit de contraintes. Le conflit de contraintes peut alors être résolu comme spécifié par l'application ou le fournisseur.

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 à l'ensemble 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.