Chapitre II : Synchronisation manuelle, personnalisation. , Page 5

Chapitre II : Synchronisation manuelle, personnalisation.

Après une introduction à Sync. Services for ADO.NET 2.0, nous allons construire aujourd'hui un ensemble de classes, sans passer par le designer, pour créer un système de synchronisation en nous appuyant sur Microsoft Synchronization Framework (MSF).

Par Sébastien Pertus publié le 13/01/2008 à 22:50, lu 4844 fois, 6 pages

4 commentaire(s) tag(s)

Tags: SQL Server 2005, Microsoft Sync Framework, Visual Studio 2008, ADO.NET 2

5 | Deuxième solution

1 | Introduction

2 | Présentation

3 | Mise en place : Source de données

4 | Première solution

5 | Deuxième solution

6 | Conclusion

Téléchargez le code source - 552 Kb

Deuxième solution

Dans cette deuxième solution, nous allons créer sur la même base que précédemment, l'ensemble des classes nécessaires à une synchronisation. Mais nous voulons en plus que les requêtes utilisées soient des procédures stockées. Et là le Builder de SyncAdapters ne fonctionnera pas. Nous allons donc devoir nous en passer.

Partie Cliente

La partie cliente reste identique à la première solution, nous la reprenons en intégral.

Partie Serveur

Ici nous devons retravailler les SyncAdapters, et surtout nous allons devoir créer les procédures stockées.
Ces procédures stockées devront en plus être capable de gérer la personnalisation en rapatriant uniquement les clients de l'employé passé en paramètre.

Nous savons qu'il existe, par Table, 8 commandes à créer.
Nous allons donc créer 8 procédures stockées.

Insertion, suppression et mise à jour

Les procédures d'insertion, suppression et mise à jour ne sont pas de "simples" procédures stockées d'insertion, suppression et de mise à jour. Elles doivent gérer les conflits s'il en survient lors de la synchronisation.

Procédure sClientApplyInsert
Cette procédure est relativement simple, puisqu'aucun risque de conflit, le GUID généré étant forcément unique.
Notez l'utilisation de @@rowcount qui renverra le nombre de lignes affectées par la procédure stockée. Cette valeur est passée à la variable output @sync_row_count.

CREATE PROCEDURE sClientApplyInsert

@ClientId uniqueidentifier,

@EmployeId uniqueidentifier,

@ClientTypeId int,

@Prenom nvarchar(100),

@Nom nvarchar(100),

@Adresse nvarchar(150),

@sync_row_count int output

BEGIN

INSERT INTO [Client] ([ClientId], [EmployeId], [ClientTypeId], [Prenom], [Nom], [Adresse])

VALUES (@ClientId, @EmployeId, @ClientTypeId, @Prenom, @Nom, @Adresse) ;

SET @sync_row_count = @@rowcount

END

Procédure sClientApplyUpdate
Ici nous avons des risques de conflits. En effet doit-on (ou pas) effectuer une mise à jour sur une ligne qui a évoluée depuis la dernière synchronisation ?
Ici, nous ne donnons pas la réponse à la question, mais nous allons donner la possibilité à MSF de gérer le cas.

Ne pas mettre à jour une ligne qui a évolué depuis notre dernière synchronisation : Utilisation de @sync_last_received_anchor.
Pouvoir retourner si la mise à jour a été effectuée ou non : Si elle a été effectuée, @sync_row_count vaut 1, si il y a conflit, aucune mise à jour ne doit être faite, @sync_row_count vaut 0.
Dans un deuxième temps, pouvoir forcer la mise à jour, si nécessaire : Utilisation de @sync_force_write.

Create PROCEDURE [dbo].[sClientApplyUpdate]

@ClientId uniqueidentifier,

@EmployeId uniqueidentifier,

@ClientTypeId int,

@Prenom nvarchar(100),

@Nom nvarchar(100),

@Adresse nvarchar(150),

@sync_force_write bit,

@sync_last_received_anchor Datetime,

@sync_row_count int output

BEGIN

UPDATE [Client] SET

[EmployeId] = @EmployeId,

[ClientTypeId] = @ClientTypeId,

[Prenom] = @Prenom,

[Nom] = @Nom,

[Adresse] = @Adresse

WHERE ([ClientId] = @ClientId)

AND (@sync_force_write = 1 OR (LastEditDate <= @sync_last_received_anchor))

SET @sync_row_count = @@rowcount

END

Procédure sClientApplyDelete
Cette procédure est soumise aux mêmes contraintes que la procédure stockée de mise à jour :

CREATE PROCEDURE sClientApplyDelete

@ClientId uniqueidentifier,

@sync_force_write bit,

@sync_last_received_anchor Datetime,

@sync_row_count int output

BEGIN

DELETE FROM [Client]

WHERE ([ClientId] = @ClientId)

AND (@sync_force_write = 1 OR (LastEditDate <= @sync_last_received_anchor))

SET @sync_row_count = @@rowcount

END

Gestion des conflits : Suppression et mises à jour

Les conflits surviennent lors de la suppression ou la mise à jour côté serveur.
Une fois le conflit relevé (via les procédures stockées précédentes) nous devons fournir le moyen à MSF de récupérer la version des lignes serveur en conflit.
Cela permettra en code managé, de disposer des deux lignes en conflit, celle du client et celle du serveur et de décider quelle action faire : Forcer ou Céder la mise à jour (ou la suppression)
Les deux procédures sont relativement simple et récupère les enregistrements serveur.

Procédure sClientConflictDeletes

Create PROCEDURE [dbo].[sClientConflictDeletes]

@ClientId uniqueidentifier

BEGIN

SELECT [ClientId], [DeletionDate] FROM [Client_Tombstone] WHERE ([ClientId] = @ClientId)

END

Procédure sClientConflictUpdates

Create PROCEDURE [dbo].[sClientConflictUpdates]

@ClientId uniqueidentifier

BEGIN

SELECT [ClientId], [EmployeId], [ClientTypeId], [Prenom], [Nom],

[Adresse], [CreationDate], [LastEditDate]

FROM [Client] WHERE ([ClientId] = @ClientId)

END

Gestion des données incrémentales

Il ne nous reste plus qu'à créer les 3 procédures stockées chargées de récupérer les incréments d'insertion, de mise à jour et de suppression de la base serveur.

Procédure sClientIncrementalInserts
Cette procédure stockée est chargée de récupérer l'ensemble des enregistrements entre la date de dernière synchronisation et la date de synchronisation en cours.
Nous utilisons pour cela deux variables pré-définies :

@sync_last_received_anchor : Dernière date de synchronisation
@sync_new_received_anchor : Nouvelle date de synchronisation

Et surtout, nous n'oublions pas notre personnalisation en filtrant par EmployeId

Create PROCEDURE [dbo].[sClientIncrementalInserts]

@EmployeId uniqueidentifier,

@sync_last_received_anchor Datetime,

@sync_new_received_anchor Datetime

BEGIN

SELECT [ClientId], [EmployeId], [ClientTypeId], [Prenom], [Nom], [Adresse], [CreationDate], [LastEditDate]

FROM [Client]

WHERE (EmployeId = @EmployeId)

AND (CreationDate > @sync_last_received_anchor AND CreationDate <= @sync_new_received_anchor)

END

Procédure sClientIncrementalUpdates
Cette procédure est très similaire à la précédente, si ce n'est qu'il existe un filtre supplémentaire sur la colonne représentant la dernière mise à jour (LastEditDate) :

Create PROCEDURE [dbo].[sClientIncrementalUpdates]

@EmployeId uniqueidentifier,

@sync_last_received_anchor Datetime,

@sync_new_received_anchor Datetime

BEGIN

SELECT [ClientId], [EmployeId], [ClientTypeId], [Prenom], [Nom],

[Adresse], [CreationDate], [LastEditDate]

FROM [Client]

WHERE (EmployeId = @EmployeId)

AND (LastEditDate > @sync_last_received_anchor AND LastEditDate <= @sync_new_received_anchor

AND CreationDate <= @sync_last_received_anchor)

END

Procédure sClientIncrementalDeletes
Cette procédure récupère les enregistrements à supprimer.
Notez l'utilisation de la variable @sync_initialized qui va permettre lors de l'initialisation de la base cliente de ne pas essayer d'effacer des lignes (puisque la base est vide!)

Create PROCEDURE [dbo].[sClientIncrementalDeletes]

@sync_last_received_anchor Datetime,

@sync_new_received_anchor Datetime,

@sync_initialized bit

BEGIN

SELECT [ClientId], [DeletionDate] FROM [Client_Tombstone]

WHERE (@sync_initialized = 1

AND DeletionDate > @sync_last_received_anchor AND DeletionDate <= @sync_new_received_anchor)

END

Voilà nos procédures stockées sont à jour, il ne reste plus qu'à créer notre SyncAdapter.

Création du SyncAdapter

Nous reprenons le code de l'exemple précédent et nous retirons la partie traitée par le SqlSyncAdapterBuilder.

A la place nous allons configurer nous même notre SyncAdapter.

Nous avons à fournir les 8 commandes nécessaires :

InsertCommand
DeleteCommand
UpdateCommand
SelectConflictDeletedRowsCommand
SelectConflictUpdatedRowsCommand
SelectIncrementalInsertsCommand
SelectConflictUpdatedRowsCommand
SelectIncrementalDeletesCommand

Pour l'exemple, voici la commande SelectIncrementalInsertsCommand :

this.clientSyncAdapter.SelectIncrementalInsertsCommand =

new System.Data.SqlClient.SqlCommand();

this.clientSyncAdapter.SelectIncrementalInsertsCommand.CommandText = "sClientIncrementalInserts";

this.clientSyncAdapter.SelectIncrementalInsertsCommand.CommandType = System.Data.CommandType.StoredProcedure;

this.clientSyncAdapter.SelectIncrementalInsertsCommand.Parameters.Add(

new System.Data.SqlClient.SqlParameter("@sync_last_received_anchor", System.Data.SqlDbType.BigInt));

this.clientSyncAdapter.SelectIncrementalInsertsCommand.Parameters.Add(

new System.Data.SqlClient.SqlParameter("@EmployeId", System.Data.SqlDbType.UniqueIdentifier));

Le paramétrage par le code des autres commandes reste classique et très similaire (paramétrage d'une procédure stockée), et je vous laisse découvrir le code dans le fichier source en annexe de cet article.