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
 3 | Le conflit dans une synchronisation
Téléchargez le code source - 330 Kb
Le conflit dans une synchronisation
Contrairement à ce que l'on pourrait croire, les conflits ne sont pas gérés par le SyncAgent de notre synchronisation. Celui-ci étant l'orchestreur de la synchronisation, c'est le premier vers qui nous aurions tendance à nous tourner.
Mais notre SyncAgent est présent uniquement sur le client et ne pourrait donc pas agir coté serveur.
Les conflits sont directement gérés par les SyncProviders coté client et coté serveur.
Type de conflit
Avant d’aller plus loin, il est de bon ton de présenter les types de conflits que nous pouvons rencontrer.
Il existe une énumération, qui reprend l’ensemble des conflits possibles, entre un client et un serveur : ConflictType

public enum ConflictType

{

    Unknown = 0,

    ErrorsOccurred = 1,

    ClientUpdateServerUpdate = 2,

    ClientUpdateServerDelete = 3,

    ClientDeleteServerUpdate = 4,

    ClientInsertServerInsert = 5,

}

ConflictType : Cette énumération décrit le type de conflit survenu:
  • ClientUpdateServerUpdate : Le type de conflit le plus commun et répandu : Un client met à jour un enregistrement en local, et le serveur a lui-même mis à jour cet enregistrement.
  • ClientUpdateServerDelete : Un client met à jour un enregistrement, alors que celui-ci a été supprimé coté serveur.
  • ClientDeleteServerUpdate : Un enregistrement client a été supprimé alors que celui-ci a été mis à jour coté serveur
  • ClientInsertServerInsert : Surement un conflit très rare, si nous utilisons des GUID pour générer nos clés primaires : Un enregistrement est à la fois inséré coté client et coté serveur.
Par expérience la plupart des conflits sont contenus dans les valeurs 2, 3 et 4.
SyncConflict
Un SyncConflict contient, outre le type de conflit ConflictType, l’ensemble des informations nécessaires à sa résolution.
Nous possédons le type de conflit, d'une part, mais nous avons aussi la possibilité de connaître l'étape de synchronisation lorsque ce conflit survient, grâce à l'énumération SyncStage
SyncStage : Enumération décrivant les différentes étapes de synchronisation:
  • ReadingSchema : Lecture du schéma serveur
  • CreatingSchema : Création du schéma coté client (souvent lors de la première synchronisation)
  • ReadingMetadata : Lecture des méta données: Quelles tables à synchroniser, quelles tables à uploader, quelles tables à downloader
  • CreatingMetadata : Ecriture des ces métas données.
  • DeletingMetadata : Suppression des ces métas données.
  • UploadingChanges : Envoi des données à synchroniser du client vers le serveur, ou du serveur vers le client
  • DownloadingChanges : Récupération des données à synchroniser provenant du serveur sur le client, ou provenant du client sur le serveur
  • ApplyingInserts : Application des insertions, coté client ou coté serveur
  • ApplyingUpdates : Application des mises à jour, coté client ou coté serveur
  • ApplyingDeletes : Application des suppressions, coté client ou coté serveur
  • GettingInserts : Phase de récupération des insertions, coté client ou coté serveur
  • GettingUpdates : Phase de récupération des mises à jour, coté client ou coté serveur
  • GettingDeletes : Phase de récupération des suppressions, coté client ou coté serveur
L'objet SyncConflict contient aussi deux DataTables, contenant l'ensemble des modifications, suppressions, insertion, et ce coté serveur comme coté client:
  • ServerChange : Ensemble des modifications en conflit coté Serveur.
  • ClientChange : Ensemble des modifications en conflit coté Client.
Exemple de conflit
Pour illustrer un conflit, nous générons volontairement un conflit de type Update – Update :
 
/content/17ca4685-7c88-4fcc-9de9-44e7e7cb9bf2/image4.gif
 
Nous avons mis à jour l’adresse d’une personne de type « client »
Lors de la synchronisation, Sync Services va lever un conflit, indiquant que chacun des fournisseurs a mis à jour un même enregistrement. Il ne reste plus qu’à savoir qui des deux a raison ou tort !
Si l’on reprend le schéma directeur des opérations menées lors d’une synchronisation, le premier fournisseur qui va lever le conflit sera notre fournisseur serveur, pendant la phase N°2 : ApplyChanges.
C’est ici que nous devrons résoudre le conflit :
 
/content/17ca4685-7c88-4fcc-9de9-44e7e7cb9bf2/image5.gif
 
Mais avant de résoudre ce conflit, reste à définir la règle métier à appliquer. Cette règle métier vient de votre gestion, de votre cahier des charges et des règles métiers de votre application.
Bref, c’est à vous de choisir.
 
» Démarrer une discussion
 
Discussion démarée par realtn le 01/02/2010 à 16:58, 1 commentaire(s).