Sébastien Warin

Il y a quelque temps je cherchais a mettre en place une architecture d’application connectée/déconnectée !
Typiquement j’ai plusieurs clients qui se connectent à un serveur de base de donnée pour centraliser leurs données ! Mais ces clients sont mobiles et n’ont pas toujours de connectivité. Ils doivent donc posséder une version locale du serveur la plus a jour possible pour continuer a travailler et se synchroniser avec le serveur dès qu’ils retrouvent la connexion pour mettre a jour les données modifiées en local pendant la déconnexion et répliquer les nouvelles données du serveur.

L’application est lourde, difficile de revenir dans le code, trop de boulot ! Je me suis donc débarrassé du problème en laissant SQL Server 2005 le gérer pour moi !

Pour cela, sur le serveur central (avec un SQL Server 2005 Standard ou +) la base de donnée a été publié au travers une « Publication transactionnelle prenant en charge les abonnements mis à jour » dans les outils de réplication que propose SQL Server 2005.
Il ne reste plus qu’a installer SQL Server 2005 Express (et gratuite :)) et de venir l’abonner à la publication du serveur central.
L’application n’a plus qu’a venir taper sur l’instance sqlexpress locale et MSSQL gère le reste 🙂

Elle est pas belle la vie ?? Encore faut-il arriver a configurer le tout… :p

Pour cela il nous faut :

• 1 serveur avec SQL Standard ou +
• X client(s) possedant une instance d’SQL (SQL Express fait très bien l’affaire !)
• SQL Studio Management Standard/Express pour configurer tout ça (bien que des scripts peuvent être réalisé pour un déploiement plus simple !)

Les étapes pour mettre tout ça en place :

1er étape : connexion et résolution de nom
Libre à vous de choisir la connexion avec votre serveur. Pour ma part les clients étaient connectés via un simple VPN Windows pour garantir un 1er niveau de sécurité. Mais après il ne faut pas oublier la résolution des noms NETBIOS ! Il faut d’une part que votre client sache résoudre le nom du serveur MAIS AUSSI que votre serveur sache résoudre le nom du client. Pour cela le plus sûr et simple est d’installer un serveur WINS sur le serveur. Vous trouverez WINS dans « Ajout et supp. de programme » sur votre serveur Windows 2000 ou 2003. Sur les clients il faudra juste dans les options avancées TCP/IP de votre connexion, entrer l’IP de votre serveur WINS.
A Savoir : dans le cas d’un adresse IP dynamique (DHCP) de vos clients, il faut garder a l’esprit le processus de résolution de noms par Windows :

1. Interrogation du cache local (sachant que la durée de vie d’un enregistrement est de 10min)
2. Interrogation du serveur WINS
3. Broadcast sur le réseau
4. Interrogation du fichier local LMHOST

Ce qu’il faut en retenir, c’est que si votre client vient a perdre la connexion puis se reconnecte sous une adresse IP différente, il se peut que votre serveur ne puisse pas résoudre son nom pendant moins de 10min, le temps que l’ancien enregistrement dans son cache local expire !

2ème étape : SQL Server sur le réseau Par défaut un SQL Server 2005 Standard ou + est configuré pour accepter les connexions distantes mais ce n’est pas le cas de la version express qui par défaut n’accepte que les connexions locales.

Pour cela dans « SQL Server 2005 Surface Aera Configuration » > « Service and connections » : autoriser les connexions locales et distances TCP/IP et par « pipe ».

Ensuite dans MMC « SQL Server Configuration Manager » vérifier que le protocole TCP/IP dans la configuration réseau de votre instance SQLEXPRESS est bien activé.

Pour finir, relancer votre instance SQM et activer le démarrage automatique d’ SQL Browser et lancer-le !

A ce stade, vous devez être en mesure de vous connectez du client sur le serveur et du serveur sur le client !

3ème étape : MSDTC et le réseau MSDTC pour Microsoft Distributed Transaction Coordinator doit être lancé sur le client ET serveur pour permettre la réplication. Pour cela, dans « Services » dans outils d’administration, activé le démarrage automatique de ce serveur et lancer-le !

Il faut aussi que votre serveur et client autorisent les connexions à distances.
Pour cela, toujours dans les outils d’administration, dans « Services de composants » accéder aux propriétés de votre « Poste de travail ».

Sous l’onglet « MSDTC » > « Configuration de la sécurité » :

Pour activer les options suivantes :

Notes : A ce stade, les préliminaires pour mettre en place la réplication transactionnelle sous SQL Server 2005 est OK. Du coté du firewall il faut ouvrir le port SQL (1433) et MSDTC (process msdtc.exe) coté serveur comme client

4ème et 5ème étape : Configuration de la publication coté serveur et de l’abonnement du client
Pour cela je vois renvoi sur un article de Fabrice publié sur ASP-PHP ici. Bien que le type de publication ne soit pas la même la configuration est quasi-identique a part qu’il vous faudra prendre le type « Publication transactionnelle prenant en charge les abonnements mis à jour » et non « par capture instantanée » comme dans l’article.
De plus lors de la configuration de l’abonnement (coté client), il faudra définir a « en attente » la « méthode de mise a jour » 🙂

Quand tout s’est déroulé avec succès, votre client récupèrera toute la base (ce qui peut être long la 1er fois, tout dépends de la taille de votre base !). Puis amusez-vous a mettre faire des modifications en local en connecté/déconnecté et voyez comment les autres clients se synchronisent !

Certes dans certaine application ça a ses limites (pas de contrôle réelle sur la synchronisation, régle de « si pas modifié, je peux injecter mes données » qui peut provoquer pas mal de perte de donnés si il y a beaucoup de mise a jour, etc..etc..) mais pour ma part ça répondait aux besoins donc expédié avec 0 lignes de code (enfin si 1: la connString dans le App.config :p) et quelques heures recherches/configuration/tests 🙂

Merci Mr SQL 🙂