Réplication SQL pour les projets mobiles : Bien définir les articles des publications et leurs options
Introduction :
Revenons un instant sur les synchronisations de données et plus particulièrement sur la mise en place de la réplication SQL entre un serveur et des terminaux portables.
Aujourd’hui, je vais vous parlez des articles… Je vais tenter de vous apportez quelques précisions et conseils en ce qui concerne la définition des articles d’une publication.
Pour rappel, les articles représentent l’ensemble des tables qui vont être répliquées lors de la synchronisation SQL. La définition des articles représente la première phase importante lors de la configuration d’une publication.
Bien choisir les articles d’une publication :
L’écran ci-dessous est celui qui permet de définir les articles d’une publication.
Il apparait dans le wizard lors de la création d’une nouvelle publication.
Cet écran permet d’ajouter ou de supprimer facilement des tables à répliquer en les cochant ou décochant dans la liste.
Chacune des tables est représentée sous la forme d’un nœud, qui une fois déployé, permet également de cocher ou de décocher les colonnes répliquées.
Dans l’exemple ci-dessus, nous allons considérer que toutes les tables sont représentatives du référentiel de travail sauf RAPPORT_INTERVENTION et RAPPORT_INTERVENTION_FOURNITURE. Ces dernières seront destinées à stocker les rapports d’intervention des techniciens et seront mises à jour uniquement à partir du terrain par les utilisateurs nomades.
Conseil :
Il est habile de créer une première publication regroupant tous les articles sauf RAPPORT_INTERVENTION et RAPPORT_INTERVENTION_FOURNITURE. Une seconde publication, pourra donc être créée pour la remontée des informations terrain et devra contenir les 2 tables précédemment citées. On sépare ainsi la synchronisation du référentiel de travail de celle des informations saisies sur le terrain en 2 publications différentes. Les 2 publications implémentées ne possèderont pas les mêmes options, et seront configurées selon le sens des flux (descendant ou remontant).
Le fait de séparer les tables du référentiel de celles des données terrain en 2 publications différentes permet d’éviter les conflits.
Autre avantage : dans le code .NET de l’application mobile, il sera possible de lancer la synchro du référentiel ou celle des exports terrain indépendamment et à différents endroits de l’application (selon les besoins métiers).
Remarque :
L’option “Show only checked articles in the list” permet de ne visualiser que les articles sélectionnés dans la liste :
Bien définir les options et le sens des flux :
Des propriétés supplémentaires peuvent également être définies sur chacun des articles.
Le bouton “Article Properties” permet d’afficher une fenêtre permettant de définir les options des articles. Ces propriétés peuvent être saisies pour des articles particuliers, ou pour l’ensemble des articles sélectionnés (option “Set properties for all table articles”) :
Le premier groupe de paramètres permet de définir les objets copiés sur l’abonné par le processus de réplication (indexes, clefs, contraintes…).
Le second groupe, quant à lui, est le plus important car il définit des propriétés concernant le comportement des tables répliquées.
Conseil :
La propriété importante, qu’il est nécessaire de faire attention, est la “Synchronisation direction”.
En effet, cette option permet de préciser si les données d’une table seront répliquées d’une manière bidirectionnelle ou uniquement dans le sens “Serveur à Abonné” (“Download only”).
Le fait de définir l’ensemble des tables du référentiel en “Download only” permet d’optimiser les processus de réplication et permet également d’éviter les modifications anormales des abonnés.
Il est évident que seules les tables du référentiel, autrement dit, les tables dont les données ne sont jamais modifiées sur le terrain, doivent être définies en “Download only”.
Les autres tables, destinées à stocker les données terrain, doivent être définies en “Bidirectionnal”. (L’option “Upload only” n’existe pas).
Pour la mise en place de la publication du référentiel, il faut donc modifier l’option “Synchronisation direction” pour choisir “Download only to Subscriber, prohibit Subscriber changes” :
En validant l’option « Download-only » en cliquant sur le bouton « OK », les petites icones symbolisant les articles sélectionnés dans la liste seront grisées. De la même façon, l’option « Highlighted table is download only » sera cochée et l’intitulé « For this table, only changes made at the Publisher or a server subscription are replicated » sera visible :
Pour la seconde publication, c’est à dire celle qui permettra de remonter les informations saisies sur le terrain, il sera nécessaire de cocher les tables RAPPORT_INTERVENTION et RAPPORT_INTERVENTION_FOURNITURE et de ne pas modifier les propriétés afin de les laisser en mode “Bidirectionnal”. Le fait de déclarer ces 2 articles en “Download only” rendrait bien évidemment la remontée des saisies terrain impossible.
Conclusion :
Si le modèle de données le permet, il peut être intéressant de construire 2 publications différentes pour séparer les articles du référentiel de ceux qui permettent de remonter les données terrain. Le sens des flux peut facilement être paramétré dans le wizard lors de la définition des articles. Cette opération permet :
-
D’éviter au mieux les conflits
-
De sécuriser les données du référentiel, en empêchant les terminaux mobiles de les mettre à jour
-
D’optimiser les performances de la synchronisation en définissant des articles en “Download only”
-
De pouvoir lancer la synchro du référentiel ou celle des exports terrain indépendamment dans l’application mobile
La prochaine grande phase lors de la création d’une publication est de définir un système de filtres… (à suivre)
Pi-R.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
