Le Blog de Pi-R (Pierre Cambier)

Spécificités de la réplication SQL dans le cadre de projets mobiles

Dans cet article, je vous présente les spécificités de la réplication de fusion SQL dans le cadre de projets mobiles (SQL Server Compact).

S’en suivront d’autres articles plus techniques qui représenteront les points importants et délicats sur la mise en place d’un système de synchronisation entre des terminaux mobiles et un serveur SQL.

Présentation de la réplication de fusion :

La réplication de fusion (merge replication) est un système puissant et riche en fonctionnalités qui permet la synchronisation de données, et plus particulièrement la synchronisation d’un différentiel de données vers les différents terminaux du parc.

La réplication SQL permet les échanges de données entre une base centrale SQL Server et plusieurs bases SQL Server Compact déployées sur des terminaux mobiles.

Lors du processus de réplication, seules les données modifiées (par des ordres UPDATE, INSERT, ou DELETE) sont prises en compte. Le système peut déterminer de manière intelligente quelles sont les données modifiées et quelles sont les données qui doivent être envoyées sur chacun des terminaux.

Il existe plusieurs types de réplication dans SQL Server, cependant seule la réplication de fusion est prise en charge et permet de synchroniser des données entre un serveur et des terminaux portables. Pour la mobilité, nous parlons de « web synchro » dans le sens où les PDA doivent s’appuyer sur une DLL exposée sur un serveur web IIS pour échanger leurs données (= Agent de réplication). L’URL de cette DLL sera donc précisée dans le code de l’application mobile.

Grands principes de la réplication de fusion :

Publisher, Distributor et Subscriber :

La notion de réplication SQL passe obligatoirement par les notions de Publisher, Distributor et Subscriber.

Il s’agit en fait de 3 parties distinctes ayant chacune un rôle précis dans les process de synchronisations. Ces 3 parties correspondent d’ailleurs à 3 bases de données différentes.

Le Publisher correspond à la base publiée, c’est à dire celle qui contient les données à répliquer. Le Distributor correspond à la base qui distribue les données (base système), tandis que le Subscriber (ou abonné) correspond à la base répliquée, c’est à dire celle qui reçoit les données répliquées.

Les snapshots :

Les snapshots sont des métadonnées utilisées lors des synchronisations entre un PDA et le serveur SQL.

Ils doivent être stockés dans un répertoire réseau de telle manière à être accessibles à la fois par le serveur IIS et l’agent de snapshots situé sur le serveur SQL.

Les snapshots permettent de définir le schéma de la base à un instant t, ainsi que l’ensemble des contraintes liées.

Il existe 2 types de snapshots:

• Le snapshot principal qui doit être généré obligatoirement suite à la mise en place d’une publication.
• Un snapshot particulier par terminal (système de partitions)

Les synchronisations de données entre le PDA et le serveur SQL se basent sur ces snapshots.

Déroulement de la synchronisation initiale :

La synchronisation initiale se déroule de la manière suivante :

• Le Distributor utilise le répertoire de snapshots pour préparer le schéma de la base répliquée.
• Le schéma de la base mobile est créé.
• Les contraintes sont créées sur la base mobile.
• Les données sont téléchargées.

Déroulement des synchronisations suivantes :

Lors des synchronisations suivantes, le distributor n’utilise plus les snapshots. Seul le différentiel des données est téléchargé.

Publications :

Une publication est rattachée à une et une seule base publisher.

La publication permet de définir l’ensemble des éléments suivants :

• Articles : Ce sont les tables et les colonnes répliquées
• Filtres : La publication peut se baser sur un système de filtres pour restreindre le nombre de données sur chacun des abonnés
• Options: De nombreuses options peuvent être liées à une publication particulière et permettent de définir le comportement des synchronisations.

Plusieurs publications peuvent être rattachées à une même base.

En effet, nous pouvons par exemple distinguer les tables du référentiel de travail de celles qui correspondent aux tables qui vont stocker les données collectées sur le terrain par les différents terminaux.

Dans ce cas, il est astucieux d’implémenter 2 publications différentes. La première permettra de répliquer les tables du référentiel de travail (tables dont les données doivent uniquement descendre sur les PDA), tandis que l’autre publication va être utilisée pour la remontée des terrains terrain. Ces 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 également d’éviter les conflits.

Exemple concret de mise en pratique dans le cadre d’un projet mobile :

Imaginons que nous devons mettre en place un système de synchronisation pour des techniciens nomades qui effectuent des interventions de maintenance chez des clients (plomberie, électricité, etc...).

Ces techniciens possèdent chacun un terminal portable sur lequel est installé une application mobile.

L’application mobile, développée sous Windows Mobile, doit permettre aux techniciens de synchroniser leurs données lorsqu’ils le souhaitent en cliquant sur un simple bouton « Synchro ». Dès lors, les techniciens doivent pouvoir recevoir les demandes d’interventions qu’ils doivent accomplir chez les clients, et peuvent également envoyer les rapports des interventions qu’ils ont réalisées via le logiciel mobile.

Cet exemple représente un cas typique d’utilisation de la réplication SQL et de l’ensemble de ses fonctionnalités !

Ainsi, des bases de données locales, une par terminal, seront destinées à stocker le référentiel de travail ainsi que les rapports des techniciens. Ces bases de données contenues sur les PDA représentent donc les abonnés de la réplication de fusion. Elles pourront échanger leurs données avec le serveur SQL lors d’un clic sur le bouton de synchronisation.

Grâce à la réplication SQL, et plus particulièrement à la construction d’un système de filtres, nous pouvons aussi faire en sorte qu’un technicien possède dans sa base de données locale uniquement le référentiel de travail qui lui est propre.

Ainsi la base de données d’un technicien T ne pourra contenir que les demandes d’interventions qui sont planifiées pour ce technicien (Il en est de même pour l’ensemble du référentiel, c'est-à-dire les clients, le périmètre géographique, etc.…).

Les filtres jouent un rôle important dans 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 devront pas forcément posséder les mêmes données dans leurs bases locales.

Dans certains projets mobiles l’implémentation de filtres peut avoir un rôle important pour la sécurité des données. Les filtres peuvent être parfois un bon moyen de restreindre la visibilité des données protégées par des droits.

Exemple de process :

1. La secrétaire reçoit les appels téléphoniques et saisit les demandes d’interventions des clients via une application PC.
2. Les informations relatives aux demandes et aux clients sont alors stockées dans la base centrale.
3. Les agents terrain cliquent sur le bouton « Synchro » pour synchroniser leurs terminaux mobiles.
4. Chaque technicien reçoit alors les demandes d’interventions qu’il doit réaliser.
5. Les techniciens réalisent donc les interventions et rédigent leurs rapports dans l’application mobile.
6. Ils synchronisent de nouveau leurs terminaux pour que les rapports d’interventions remontent dans la base serveur. (De la même façon, ils reçoivent encore les éventuelles nouvelles demandes).
7. Une fois les rapports remontés dans la base centrale, la secrétaire peut les traiter et envoyer les factures aux différents clients.

Pré-requis :

Voici la liste de tous les éléments nécessaires pour implémenter convenablement la réplication SQL dans le cadre de projets mobiles :

Pour pouvoir construire un système de réplication entre des terminaux mobiles (SQL Server Compact) et une base centrale (SQL Server), il est nécessaire d’installer les outils de réplication SQL Server Compact.

Téléchargement des “Microsoft SQL Server Compact 3.5 Server Tools” :

http://www.microsoft.com/downloads/details.aspx?FamilyID=b18327f3-96e1-415d-b037-9e0c46d49956&DisplayLang=en

Installation et déploiement sur un terminal mobile :

Pour que la réplication SQL soit prise en charge par un terminal, il est question d’installer certains composants sur le PDA. Les fichiers d’installation CAB se situent par défaut dans le répertoire “%ProgramFiles%\Microsoft SQL Server Compact Edition\v3.5\Devices\plateforme\processeur\” :

• sqlce.type_appareil.plateforme.processeur.CAB
• sqlce.dev.langue.type_appareil.plateforme.processeur.CAB
• sqlce.repl.type_appareil.plateforme.processeur.CAB

Ces composants dépendent du type d’appareil, de plateforme et également du processeur de l’appareil.

A noter que les bons fichiers CAB sont poussés et installés automatiquement par Visual Studio lors du lancement d’une phase de déploiement.

Règles de bases pour la réplication avec SQL Server Compact :

Voici quelques règles importantes à connaitre en ce qui concerne la mise en place de la réplication entre des terminaux mobiles et un serveur SQL :

• Les terminaux mobiles peuvent uniquement être des Subscribers (jamais des Publishers, ni des Distributors).
• Il existe plusieurs Subscribers (= terminaux portables) pour un même publisher.
• Un subscriber doit toujours se synchroniser avec le même Publisher, mais plusieurs publications peuvent être utilisées.
• C’est toujours aux Subscribers que revient la tache d’initialiser une synchronisation avec le serveur.

Restrictions des modifications de schéma sur un subscriber :

Certaines modifications de schéma sur l’abonné sont interdites et peuvent générer des échecs de synchronisation. Voici la liste complète des actions à ne pas entreprendre sur la base de données abonnée :

• Supprimer ou renommer une table
• Ajouter ou supprimer une colonne dans une table
• Ajouter ou supprimer une clef primaire ou une clef étrangère

Eléments non pris en charge par SQL Server Compact :

Les éléments ci-dessous ne sont pas pris en charge par SQL Server Compact :

• Procédures stockées
• Propriétés étendues
• Vues
• Contraintes CHECK
• Fonctions utilisateurs
• Triggers

Limites de volumétrie des bases mobiles :

Il est à noter que les bases SQL Compact 3.5 ne peuvent pas excéder la taille de 4Go.

Pi-R.