Application des modifications à l'aide du service d'application des modifications
Le service d'application des modifications effectue les mêmes actions que le composant applicateur de modifications de Sync Framework, mais d'une façon plus précise. Un fournisseur de destination qui requiert plus de flexibilité que celle offerte par l'applicateur de modifications standard peut utiliser le service d'application des modifications pour effectuer uniquement le jeu d'actions requis par le fournisseur. Par exemple, un fournisseur peut effectuer sa propre détection de conflit et utiliser le service d'application des modifications pour calculer la connaissance mise à jour. Sinon, un fournisseur de destination peut utiliser le service d'application des modifications pour appliquer des modifications dans un ordre différent de celui envoyé par le fournisseur de source.
Gardez à l'esprit que le service d'application des modifications ne peut pas être utilisé par un fournisseur qui signale des conflits de contraintes ou utilise des filtres personnalisés, sinon des résultats inattendus peuvent se produire.
Traitement de modifications
Pour traiter les modifications, le fournisseur de destination effectue les étapes suivantes :
Crée et initialise le service de l'applicateur de modifications.
Démarre une session d'application des modifications.
Utilise le service d'application des modifications pour effectuer la détection de conflit et l'application des modifications qui ne sont pas gérées autrement par le fournisseur.
Signale toutes les modifications qui n'ont pas pu être appliquées.
Signale éventuellement les modifications appliquées avec succès. Cette opération est nécessaire uniquement lorsque le fournisseur récupère la connaissance de destination mise à jour pendant la session d'application des modifications. Sinon, il est plus efficace de signaler uniquement les modifications ayant échoué et de récupérer la connaissance de destination mise à jour une fois à la fin de la session d'application des modifications.
Met fin à la session d'application des modifications. Le service d'application des modifications retourne la connaissance de destination mise à jour pour le lot de modifications traitées.
Création de l'objet de service d'application des modifications
Le fournisseur de destination crée et initialise l'objet ChangeApplicationServices (pour le code managé) ou IChangeApplicationServices (pour le code non managé). Pour ce faire, il convient d'appeler ChangeApplicationServices (pour le code managé) ou de passer IID_IChangeApplicationServices à IProviderSyncServices::CreateChangeApplier et d'appeler ensuite IChangeApplicationServices::Initialize (pour le code non managé).
Démarrage d'une session d'application des modifications
Le fournisseur de destination démarre une session d'application des modifications en appelant BeginChangeApplication (pour le code managé) ou IChangeApplicationServices::BeginChangeApplication (pour le code non managé). La connaissance de destination passée à cette méthode est utilisée comme base pour calculer la connaissance de destination mise à jour pendant et après l'application des modifications.
Traitement d'une modification
Le fournisseur de destination utilise le service d'application des modifications pour traiter uniquement les modifications qui ne sont pas gérées autrement. Par exemple, un fournisseur de destination effectue sa propre détection de conflit et applique les modifications lui-même. Dans ce cas, le service d'application des modifications n'est pas utilisé pour traiter les modifications. Sinon, un fournisseur de destination applique les modifications dans un ordre différent de celui envoyé par le fournisseur de source. Dans ce cas, le service d'application des modifications est utilisé pour traiter les modifications dans l'ordre spécifié par le fournisseur de destination.
Pour traiter une modification, le fournisseur de destination effectue les étapes suivantes :
Appelle GetChangeApplicationContext (pour le code managé) ou IChangeApplicationServices::GetChangeApplicationContext (pour le code non managé) pour démarrer le traitement d'une modification. Cette méthode retourne un objet ChangeApplicationContext (pour le code managé) ou IChangeApplicationContext (pour le code non managé).
Obtient la propriété ChangeApplicationAction (pour le code managé) ou appelle IChangeApplicationContext::GetChangeApplicationAction (pour le code non managé). Cette méthode retourne l'action suivante à entreprendre en tant que valeur ChangeApplicationAction (pour le code managé) ou Interface IChangeApplicationContext (pour le code non managé).
Effectue l'action spécifiée, par exemple l'enregistrement de la modification sur le réplica de destination. Pour plus d'informations sur la gestion des actions possibles, consultez les rubriques de référence pour obtenir les composants du service d'application des modifications.
Répétez ces étapes jusqu'à ce que l'action retournée à l'étape 1 soit Finished (pour le code managé) ou CAA_FINISHED (pour le code non managé).
Signalement des modifications réussies et non réussies
Si le fournisseur de destination utilise le service d'application des modifications pour calculer la connaissance mise à jour, le fournisseur doit signaler toutes les modifications qui n'ont pas pu être appliquées avant de mettre fin à la session d'application des modifications. Pour signaler une modification non réussie, appelez ReportRecoverableErrorOnItemChange ou ReportRecoverableErrorOnChangeUnitChange (pour le code managé), ou IChangeApplicationServices::ReportRecoverableErrorOnItemChange ou IChangeApplicationServices::ReportRecoverableErrorOnChangeUnitChange (pour le code non managé).
Par ailleurs, si le fournisseur de destination récupère la connaissance de destination mise à jour pendant la session d'application des modifications, le fournisseur doit signaler les modifications appliquées avec succès. La connaissance de destination mise à jour est récupérée en appelant GetUpdatedDestinationKnowledge (pour le code managé) ou IChangeApplicationServices::GetUpdatedDestinationKnowledge (pour le code non managé). Le signalement des modifications réussies n'est pas nécessaire lorsque le fournisseur récupère la connaissance mise à jour uniquement à la fin de la session d'application des modifications. Pour signaler une modification appliquée avec succès, appelez ReportItemChangeApplied ou ReportChangeUnitChangeApplied (pour le code managé), ou IChangeApplicationServices::ReportItemChangeApplied ou IChangeApplicationServices::ReportChangeUnitChangeApplied (pour le code non managé).
Fin d'une session d'application des modifications
Lorsque toutes les modifications ont été traitées, le fournisseur de destination met fin à la session d'application des modifications en appelant EndChangeApplication (pour le code managé) ou IChangeApplicationServices::EndChangeApplication (pour le code non managé). La connaissance acquise contenue dans le lot de modifications du fournisseur de source est passée à cette méthode. Le service d'application des modifications calcule la connaissance de destination mise à jour de la connaissance acquise et les modifications signalées comme non réussies. La connaissance de destination mise à jour qui est retournée par cette méthode doit remplacer la connaissance actuelle du réplica de destination.