Réplication SQL pour les projets mobiles : Système de filtres & HostName
Introduction :
Aujourd’hui, je vous propose de revenir un instant sur les synchronisations de données et plus particulièrement sur la réplication de fusion SQL.
Dans un précédent article, nous avons vu comment bien définir les articles des publications. Construire le système de filtres lié à une publication est également une phase importante qui intervient juste après celle du choix des articles.
Dans cet article, nous allons nous attarder un peu sur la construction de ce système de filtres.
Pourquoi est-ce important de filtrer ?
Comment construire une arborescence de filtres propre ?
Pourquoi filtrer ?
Les filtres jouent un rôle important pour la réplication dans le sens où ils permettent de filtrer l’ensemble des données qui descendent sur les terminaux mobiles.
En effet, tous les terminaux ne doivent pas forcément posséder les mêmes données dans leurs bases locales.
Considérons par exemple qu’un terminal mobile est affecté à un technicien nomade spécifique, chargé d’effectuer des interventions chez des clients. Dans cet exemple, le technicien T1 ne doit pas avoir le même référentiel de travail que le technicien T2. En effet, les interventions que doit réaliser le technicien T1 ne seront pas les mêmes que celles attribuées au technicien T2. Il en est de même pour les clients, les sites d’interventions, etc.…
Pour certains projets mobiles, l’implémentation de filtres peut également avoir un rôle important pour la sécurité des données. En effet, les filtres peuvent être parfois un bon moyen de restreindre la visibilité des données protégées par des droits.
Enfin, implémenter un système de filtres est essentiel quant à la volumétrie des bases mobiles. S’ils n’existaient pas, les bases mobiles répliquées pourraient être trop volumineuses et ne pourraient même peut-être pas être prises en charge par SQL Server Compact (limite physique à 4Go pour une base mobile SQL Server Compact 3.5).
Deux types de filtres :
Il existe 2 types de filtres :
Les filtres “join” permettent de former une arborescence d’articles de la publication.
Le système de filtre peut donc être représenté sous la forme d’un arbre composé de nœuds et de feuilles.
Les tables sont reliées entre elles à l’aide de jointures SQL.
Les filtres “join” définissent le fait que les données d’une table dépendent des données filtrées de la table parent, qui dépendent des données filtrées de la table parent et ainsi de suite…
Il s’agit donc d’un système de filtrage complexe, précis et très lié logiquement au fonctionnel attendu. En effet, le système de filtres s’établit en adéquation avec les besoins et le fonctionnel de l’application mobile.
Point d’entrée des filtres et HostName :
Le point d’entrée du système n’est autre que la table située en haut de l’arborescence.
Dans l’exemple ci-dessous, nous allons considérer qu’un terminal est attribué à un et un seul technicien nomade. Nous allons donc nous baser sur la table TECHNICIEN (par exemple), et plus particulièrement sur le champ IdTec, pour initialiser le système de filtres.
Pour ajouter le premier filtre de la publication, il faut cliquer sur le bouton “Add” puis sélectionner “Add filter…”, depuis cet écran du wizard :
Sur l’écran suivant, nous allons sélectionner l’article TECHNICIEN dans le menu déroulant du haut, puis saisir le filtre “WHERE [IdTec] = HOST_NAME()” dans le champ de saisie de droite et cliquer sur “OK” :
Filtre d’entrée : WHERE [IdTec] = HOST_NAME()
Explications :
Le HOST_NAME n’est autre que la variable qui permet d’initialiser le filtrage des données. Dans notre cas, elle correspond à l’identifiant du technicien.
Cette variable devra être définie dans le code de l’application mobile et sera utilisée lorsque le PDA initialisera sa phase de réplication. (Propriété “HostName” de la classe “SqlCeReplication”).
Dès lors, lorsqu’un terminal se connecte au serveur SQL, il est immédiatement reconnu et le système de filtres peut ainsi déterminer l’ensemble des données qui doivent être affectées au technicien en question (en fonction de l’id contenu dans la variable HOST_NAME).
Construction de l’arborescence de filtres :
Nous allons à présent rajouter un filtre de type “join” qui sera lié au filtre de l’article TECHNICIEN que nous venons de créer.
Pour ce faire, il faut sélectionner le filtre précédemment créé dans la zone de gauche, puis cliquer sur le bouton “Add”, pour enfin sélectionner “Add Join to Extend the Selected Filter…” :
Dans l’écran qui apparaitra, il sera question de renseigner les éléments de la jointure, c’est à dire la table ainsi que les champs sur lesquels la jointure SQL va s’appliquer :
Dans notre exemple, en cliquant sur “OK”, vous validerez le fait qu’une ligne d’intervention sera distribuée uniquement au technicien concerné par cette intervention. Notez qu’il est tout à fait possible d’éditer au mieux la jointure à appliquer en précisant des clauses “Or” ou “And” pour le filtre.
Après validation, nous pouvons visualiser l’arborescence des filtres qui est en train de se former :
Nous pouvons alors continuer à construire l’arborescence en implémentant d’autres filtres à partir de ceux déjà créés, en allant plus loin (ou non) dans les niveaux de profondeurs de l’arbre. La construction de l’arborescence dépend bien sûr du fonctionnel de l’application mobile. L’arbre finit par prendre forme lorsqu’il rassemble plusieurs articles :
Remarques importantes :
-
La complexité de l’arborescence des filtres peut être un inconvénient au niveau des performances des synchronisations. Plus le système est complexe, plus les calculs liés à la phase d’initialisation des synchronisations seront longs.
-
Tous les articles n’ont pas la nécessité d’être filtrés. En effet, pour des raisons de performance, il est conseillé de ne pas filtrer les tables non-volumineuses.
Petite astuce pour finir :
En spécifiant un filtre du type “WHERE 0 = 1” le système purgera automatiquement les données remontées au serveur, sur la base SQL Compact du terminal. Les tables d’exportation de données étant définies en “Bidirectionnal” (Cf. précédent article), l’application du filtre WHERE 0 = 1 aura pour effet de supprimer les données sur les bases locales. Pour les articles “Bidirectionnal”, l’upload des données a lieu avant le download.
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 :
