Sébastien Pertus
Chapitre IV : Sync Services for ADO.NET. Créer un Custom Resolver
Création d’un système de résolution des conflits pendant une synchronisation entre un serveur de données et un client consommateur. Utilisation de Sync Services for ADO.Net
Par Sébastien Pertus publié le 20/10/2008 à 00:42, lu 2968 fois, 7 pages
commentaire(s) 1 commentaire(s) tag(s)Tags: ADO.NET, Microsoft Sync Framework, SQL Server 2008, Visual Studio 2008
 5 | Résolution d’un conflit coté client
Téléchargez le code source - 330 Kb
Résolution d’un conflit coté client
Que nous reste-t-il coté client ?
Si l’on regarde bien les types de conflits et les types de résolution, on se rend compte que les conflits sont tous gérés coté serveur. Et c’est tant mieux. Il est plus que préférable que le serveur sache résoudre les conflits sans le client, un autre client pouvant lui aussi demander une synchronisation.
Mais alors, que doit-on faire côté Client ? Où plutôt doit on gérer un conflit coté client ?
Première constatation, il existe bel et bien l’ensemble des évènements de gestion de conflits coté client.
Alors à quoi servent ‘ ils ?
La raison est à allée chercher du côté de l’équipe Sync. Services elle-même qui nous donne les raisons d’une telle mise en œuvre
« Une synchronisation coté client peut entrer en conflit si un enregistrement est modifié entre le moment où celui est envoyé au serveur et le moment où la réponse du serveur revient »
On peut schématiser cette génération de conflit de la façon suivante :
 
/content/17ca4685-7c88-4fcc-9de9-44e7e7cb9bf2/image10.gif
 
A vous de gérer les conflits à l’identique, coté client.
Dans la plupart des cas, les interfaces client ne permettent pas ce genre de conflits (synchronisation à la connexion, petite animation d’attente de fin de synchro etc…)
Le fournisseur client de synchronisation simplifie encore plus ce mécanisme en nous proposant uniquement les attitudes à adopter en amont d’un conflit, en supposant de la réaction du serveur. En effet, à priori, lors de l’envoi de ses données, le client ne sait pas s’il va y avoir conflit ou non.
Nous allons donc juste lui indiquer « l’attitude à adopter », via l’énumération ResolveAction :

partial void OnInitialized(){

 

    this.Client.SyncDirection = SyncDirection.Bidirectional;

 

    BewiseSyncClientSyncProvider syncClientProvider = this.LocalProvider as BewiseSyncClientSyncProvider;

 

    // Cas où le client l'emporte : Suppression d'un enregistrement coté client

    syncClientProvider.ConflictResolver.ClientDeleteServerUpdateAction = ResolveAction.ClientWins;

 

    // Pour le reste, le serveur est le référent

    syncClientProvider.ConflictResolver.ClientUpdateServerDeleteAction = ResolveAction.ServerWins;

    syncClientProvider.ConflictResolver.ClientInsertServerInsertAction = ResolveAction.ServerWins;

    syncClientProvider.ConflictResolver.ClientUpdateServerUpdateAction = ResolveAction.ServerWins;

    syncClientProvider.ConflictResolver.StoreErrorAction = ResolveAction.ServerWins;

 

    syncClientProvider.ApplyChangeFailed += BewiseSyncSyncAgent_ApplyChangeFailed;

 

}

Cas particulier : ClientDeleteServerUpdate
Il existe pourtant bien un cas particulier coté client qui nécessite de résoudre un conflit :
  • Suppression d’une ligne coté client
  • Mise à jour coté serveur, qui gagne le conflit coté serveur (ApplyAction.Continue)
  • Retour coté client d’une ligne supprimée à « ré insérer »
Pourtant si nous nous référons à ce qui a été énoncé précédemment, la ligne qui revient du serveur n’est rien d’autre qu’une ligne dont la date est supérieure à la dernière date de synchronisation et qui doit être mis à jour coté client. Une ligne parfaitement … normale !
Oui mais … la ligne qui revient coté serveur est une ligne marquée comme ligne à … mettre à jour, et celle-ci n’existe plus coté client !
Levé d’un conflit coté client !
Le client ne sait pas exécuter une requête de type Update sur une ligne qui n’existe plus !
Si on ne modifie par le code précédent, ce conflit peut même passer inaperçu, et s’auto gérer seul. Mais on peut aussi lever un évènement coté client et gérer le cas.
Note : Ce cas n’arrive pas dans notre exemple, puisque nous sommes partis du principe qu’une ligne supprimée coté client doit l’être aussi coté serveur, quand bien même celle-ci aurait été mise à jour coté serveur.
 
» Démarrer une discussion
 
Discussion démarée par realtn le 01/02/2010 à 16:58, 1 commentaire(s).