|
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.
La partie cliente reste identique à la première solution, nous la reprenons en intégral.
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 AS 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 AS 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 AS 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
AS
BEGIN
SELECT [ClientId], [DeletionDate] FROM [Client_Tombstone] WHERE ([ClientId] = @ClientId)
END
Procédure sClientConflictUpdates
Create PROCEDURE [dbo].[sClientConflictUpdates]
@ClientId uniqueidentifier
AS
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 EmployeIdCreate PROCEDURE [dbo].[sClientIncrementalInserts] @EmployeId uniqueidentifier, @sync_last_received_anchor Datetime, @sync_new_received_anchor Datetime AS 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 AS 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 AS 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.
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.
|
|
|
|
|