Le premier site francophone dédié au développement Pocket PC

SQL Serveur CE - Pourquoi et comment utiliser IIS

Vous trouverez dans cet article pourquoi et comment utiliser IIS, migrer simplement une ancienne base de données vers SQL Server et un tour d’horizon sur SQL Server 2000.

IIS, Pourquoi faire ?

Tout d’abord, IIS est un serveur WEB marqué de l’empreinte Microsoft. Si une réplication est bien la mise en commun de 2 sources de données différentes, le contexte que nous avons posé dans le premier article traite de 2 réplications. La première entre 2 serveurs SQL Server 2000 et la seconde entre un serveur SQL 2000 d’une part et d’autre part notre PDA doté de SQL Serveur CE. C'est cette dernière réplication qui exige l’emploi de IIS. En effet, pour communiquer, SQL Server nécessite la présence d’une passerelle de communication, centrée sur 2 DLL :

La première embarquée sur le PDA : ssCeCa10.Dll (pour Sql Server Ce Client Agent V1.0)
La seconde présente sur le serveur : ssCeSa10.Dll (pour Sql Server Ce Server Agent V1.0)

Si vous avez suivi le premier article, vous n’aurez pas manqué de remarquer que, si Microsoft donne, pour une fois, des noms « intelligents » à ses DLL, ça n’est pas pour autant qu’ils respectent les numéros de versions dans le nommage de ces dernières puisque, nous sommes bien en V1.1 de SQL Server CE et non en 1.0

Fermons la parenthèse et revenons à nos biquettes. L’une des limites de SQL Server Ce est qu’il n’autorise de réplication PDA vers Serveur qu’en utilisant le protocole HTTP. Tout de suite, vous comprenez l’intérêt d’un serveur WEB. Evidemment, cela ne concerne pas les réplications entre 2 SQL Server 2000.

IIS, son paramétrage ?

Pour résumer, SQL Server 2000 et SQL Server Ce ne répliquent qu’avec le protocole HTTP. ssCeCa10.DLL et ssCeSa10.DLL doivent donc communiquer via IIS. Concrètement « Don’t worry, be happy », le bipède que je suis vous rassure, tout cela est d’une simplicité déconcertante.
-) Tout d’abord créez un répertoire (Ex : C:\CodePpc IIS) dans lequel vous copierez SsCeSa10.DLL (vous la trouverez dans le répertoire d’installation de SQL Server Ce Ex : C:\Program Files\Microsoft SQL Server CE\Server)
-) Cliquez droit sur ce répertoire et allez dans l’onglet « Partage Web » pour cocher l’option « Partager ce dossier ». Dans la nouvelle fenêtre nommez l’alias (Ex : CodePpc) et modifiez les cases à cocher pour obtenir :

-) Exécuter IIS (A noter qu’il est gratuit avec Windows et présent dans les composants d’installation de Windows)
-) Dans l’arborescence qui apparaît, vous voyez notre « CodePpc » bel et bien présent. Ca y’est nous venons de configurer IIS !

Migration de données : DTS (Data Transformation Service)

Il est de bon ton de recadrer la politique Microsoft. Tout d’abord, Microsoft n’a jamais rien inventé et vous pouvez être certains que lorsqu’ils sortent quelque chose, c’est que d’autres l’ont déjà réalisé. Par contre, ils sont très forts au niveau Marketing et ça, c’est bien pour nous ! Ils mettent à notre disposition tout un tas d’outils qui gravitent autour d’une vedette et gratuitement !. Le système d’exploitation Windows en est un bel exemple. Pour SQL Server 2000, il existe, entre autres, un outils que vous allez sûrement adorer autant que moi tant il est simple d’utilisation et redoutablement efficace à la fois (A noter que Oracle dispose d’un outils identique mais hors de prix…) : DTS.

Vous souvenez-vous des fraîches nuits que vous avez passé, à la bourre dans votre projet, à réaliser le module qui pourra permettre à votre utilisateur chéri d’utiliser votre nouvelle application et tout ça, à cause d’une structure de base de donnée radicalement différente de l’ancienne ? Et bien ça, terminé.
DTS vous permet de migrer une base (structure & données) quelle que soit son format (Access, Oracle Sybase, Paradox….) en se fondant sur de l’Odbc, de l’OleDb etc… Et évidemment, la base de destination n’est pas obligatoirement du SQL Server 2000.

En gros tout se passe comme ça :
-) Choix de la source et paramétrages de connexions (Ex : Pour Oracle, vous préciserez le nom du serveur ainsi qu’un Login et un mot de passe).
-) Choix de la destination (Ex : Vers Access, le chemin de la base de données et éventuellement mot de passe).

« Pour l’instant, c’est pas mal » me direz-vous, et je vous réponds « mais il y’a mieux ! », si vous souhaitez passer d’un champs source integer vers un champs destination long, c’est possible (et toutes combinaisons bien entendu). Si vous souhaitez filtrer les données selon des valeurs, des règles ou tout autre requête SQL en mélangeant interdépendances avec d’autres tables, c’est encore possible. Bref, tout est faisable (et simplement) sauf la création des contraintes (Clés primaires, clés étrangères…).
En naviguant 5 minutes dans DTS, vous maîtriserez l’outils. Une fois terminé, vous pouvez générer un script ou un module VB qui reprend toutes les instructions pour l’implémenter dans votre application.

Un peu plus sur SQL Server 2000 : Présentation des réplications

Il serait ambitieux de réaliser une vivisection de SQL Server 2000, penchons-nous plutôt sur le principe de réplication. Comme nous l’avons vu dans l’article précédent, une réplication a pour acteurs un éditeur, un distributeur ainsi qu’un abonné. Le moyen de coordonner l’ensemble passe par une publication qui est gérée par différents agents.

Il existe 2 types de réplications :

1. La réplication transactionnelle.

Comme son nom l'indique, elle passe par des transactions d’une base vers une autre base mais en temps réel. Elle nécessite donc un contact permanent entre le client et le serveur. Dans le cadre du PDA, le seul moyen d’en user serait d’être doté du fameux système réseau par bornes. Inadaptée dans 99 % des cas (liés à la sécurité réseau, technologie etc… elle est peu intéressante et, ça tombe plutôt bien, très simple à réaliser, inutile donc de nous y attarder.

2. La réplication de fusion (merge).

Là, on attaque le noyau dur. Si vous maîtrisez la réplication de fusion, aucune autre réplication (à ce jour) ne vous résistera ! Elle s’adapte parfaitement à la problématique suivante : « Comment synchroniser des bases qui ne communiquent pas directement ensemble ? ». La réplication de fusion va procéder en établissant un cliché (agent Snapshot) des données à un instant T. Lors de la connexion d’un abonné, l’agent de fusion aura pour rôle de déterminer quelles sont les données à mettre à jour en appliquant la résolution des conflits que vous aurez paramétrés dans la publication.

Imaginez une table CLIENTS à synchroniser, nous avons 2 cas de figures :

Le client Maurice est créé sur mon serveur. Mon PDA, se connectant va récupérer Maurice => Pas de conflits

L’adresse de Maurice est modifiée sur le serveur et, notre utilisateur PDA a aussi modifié l’adresse => conflit

La réplication de fusion va analyser le conflit et le résoudre en attribuant une priorité de type « Maître / Esclave » que vous aurez défini selon différents critères (la date, l’auteur de la modification, le champs modifié…) voire, laisser en suspend dans l’attente d’un arbitrage humain.

3. La réplication par cliché (SnapShot).

Cette réplication est un hybride de transactionnelle et de fusion. Elle ne fonctionne que dans un sens et est d’ordre systématique. Pour comprendre, reprenons le cas de notre Maurice, déjà célèbre. Si l’adresse de Maurice est modifiée par le distributeur, l’abonné subira, même sans conflit, le remplacement de l’adresse.

Conclusion

Nous disposons maintenant de toutes les informations théoriques pour entamer un cas pratique. Le prochain article sera un bref tutorial pour créer une réplication de fusion entre 2 SQL Server 2000.

Des questions sur cet article ? N'hésitez pas à me contacter en inscrivant dans l'objet du message : Assistance SQL Server 2000 - PPC ou utilisez les services du forum dédié à SQL Server CE.

Nicolas Vesperini