> Data > Contrôler la réplication avec Active X

Contrôler la réplication avec Active X

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Jeannine Hall Gailey - Mis en ligne le 02/02/2004 - Publié en Février 2004

Offrez la synchronisation à  la demande à  partir des applications client

En ces jours d'informatique distribuée, il est très important d'obtenir les bonnes données et de les collecter à  partir des points éloignés de l'entreprise. Et il n'est pas facile de tenir toutes ces données synchronisées, particulièrement avec des connexions réseau à  faible bande passante ou incohérentes. La situation est même pire pour les utilisateurs mobiles, comme les commerciaux, qui travaillent souvent en mode déconnecté puis transfèrent en bloc leurs changements vers la base de données ...SQL Server offre une solution de réplication souple qui permet de distribuer les données aux utilisateurs dans toute l'entreprise. Ceux-ci peuvent ensuite modifier ces données et synchroniser leurs modifications entre tous les serveurs participants dans votre topologie de réplication.
La réplication SQL Server est un ensemble de solutions dont la terminologie s'inspire du monde de l'édition. Les données de réplication se trouvent dans une base de données (la base de données de publication) sur un serveur de réplication central (le Publisher). Un serveur de distribution (le Distributor) distribue ensuite les données dans une base de données d'abonnements qui se trouve sur un ou plusieurs serveurs pratiquant l'abonnement (Subscribers). Dans ce modèle, les publications sont constituées d'un ou plusieurs objets base de données (c'est-à -dire, tables, procédure stockées et vues) appelés articles. Les abonnés reçoivent les articles en s'abonnant à  une publication. (Pour un aperçu rapide des concepts et des termes de réplication, voir l'encadré « Principes de base de la réplication »).
Un ensemble d'agents de réplication - hébergés par le SQL Server Agent - gèrent le mouvement des données dans une topologie de réplication. Et les contrôles d'ActiveX offrent une interface orientée objet pour gérer programmatiquement la plupart des agents de réplication utilisés couramment : Distribution, Snapshot et Merge. Un contrôle séparé gère l'agent de réplication qui fonctionne sur SQL Server 2000 Windows CE Edition. Comme avec le contrôle ActiveX, vous pouvez accéder à  ces contrôles de réplication programmatiquement à  partir de vos applications - même celles qui sont imbriquées dans des pages Web. En utilisant des contrôles ActiveX en même temps que la fonctionnalité administrative fournie par SQL Distributed Management Objects (SQLDMO), vous pouvez administrer et contrôler programmatiquement toute une topologie de réplication.
Bien que vous puissiez gérer la réplication et contrôler les agents de réplication à  partir d'Enterprise Manager, il est intéressant d'accéder programmatiquement aux fonctionnalités de réplication par l'intermédiaire de contrôles ActiveX. Par exemple, vous pourriez écrire une application personnalisée pour qu'un administrateur distant puisse contrôler les agents de réplication. Vous pouvez aussi utiliser le contrôle ActiveX Merge pour fournir la synchronisation à  la demande à  partir des applications client tournant sur le Subscriber, afin que les utilisateurs puissent synchroniser manuellement les abonnements « pull » (ceux qui sont gérés par le Subscriber), choisir le Publisher auquel se synchroniser, et même ajouter des abonnements. Ainsi, en ajoutant des contrôles de réplication aux applications, vous pouvez donner aux utilisateurs un certain contrôle de la réplication sans toutefois leur offrir l'ensemble des fonctionnalités qu'apporte Enterprise Manager.
Pour voir comment utiliser les contrôles ActiveX de réplication dans vos applications, voyons un exemple qui utilise le contrôle ActiveX Merge pour synchroniser manuellement des abonnements par fusion et le contrôle Error qui traite les erreurs de réplication.

Comme scénario classique de fusion/
réplication, prenons une application
de saisie de commandes fonctionnant
sur le portable (ou appareil
de saisie assimilé) d’un vendeur.
Après avoir effectué des saisies
concernant les ventes dans une copie
locale (Subscriber) de la base de données,
l’utilisateur se connecte au
Publisher et l’application synchronise
l’abonnement pour transférer en
amont les modifications de l’utilisateur,
et en aval les éventuels changements
provenant du Publisher.
Mon exemple, qui utilise le
contrôle ActiveX Merge d’une application
Visual Basic .NET, permet aux utilisateurs
de spécifier à  l’exécution les
noms du Publisher, la base de données
de publication, la publication, le
Subscriber et la base de données
d’abonnements. Toutefois, pour les
besoins du test, j’ai utilisé une publication
basée sur la base de données
exemple Northwind de SQL Server,
qui contient trois articles – provenant
des tables Customers, Orders et
OrderDetails – en utilisant le même
ordinateur que Publisher e t
Subscriber. La figure 1 montre l’élément
UI unique de l’application, un
formulaire Windows.
Bien que l’application exemple permette à  un utilisateur
de fournir la plupart de l’information que le Merge Agent demande
pour synchroniser l’abonnement « pull », en pratique,
vous configureriez cette information de synchronisation à 
l’installation et vous la stockeriez dans un fichier ou dans le
registre Windows. Quand vous stockez l’information, l’utilisateur
peut simplement cliquer sur le bouton Synchronize
sans rien connaître de la topologie de réplication sous-jacente.
Comme cet exemple utilise un abonnement pull anonyme
(voir l’encadré « Principes de base de la réplication »
pour une définition de ces termes), le Merge Agent s’exécute
chez le Subscriber et l’application est chargée d’initier manuellement
les synchronisations. Vous pourriez aussi utiliser
le contrôle Merge pour enregistrer de nouveaux abonnements
avec le Windows Synchronization Manager ou même
ajouter des abonnements, mais tout cela est hors du cadre de cet exemple. L’application exemple utilise Windows Authentication
pour faire toutes les connexions serveur et elle
suppose que vous avez déjà  créé un abonnement « pull » anonyme
chez le Subscriber et appliqué l’instantané pour la
publication chez le Subscriber. (Pour plus d’informations sur
la manière de créer un abonnement « pull » anonyme, voir
http://msdn.microsoft.com/library/default.asp?url=/library/e
n-us/replsql/replimpl_26lv.asp.)

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Data - Par iTPro.fr - Publié le 24 juin 2010