Intégration de données à partir de plusieurs sites (client)

De nombreuses sociétés disposent de bureaux régionaux ou d'entités qui collectent et traitent les données devant être envoyées à un bureau central. Exemple :

• L'inventaire des données peut être consolidé à partir de nombreux serveurs se trouvant dans des entrepôts de données locaux sur un serveur central se trouvant au siège de la société.
• Les informations provenant de divisions commerciales autonomes au sein d'une société peuvent être envoyées sur un serveur central.
• Les informations de traitement des commandes provenant d'emplacements dispersés peuvent être regroupées.

Dans certains cas, les données sont envoyées également du site central vers des sites distants. Les données sont généralement prévues pour être en lecture seule sur le site distant, comme un ensemble de tables d'inventaire produit mis à jour uniquement sur un site central.

Le diagramme suivant illustre un scénario typique où les données circulent dans les deux directions entre un site central et des emplacements distants :

Dans ce diagramme, les données circulent d'abord sur un concentrateur avant de rejoindre les bureaux régionaux servis par ce concentrateur. Les données peuvent également circuler directement entre le site central et les bureaux régionaux si l'organisation ne dispose pas de couche intermédiaire.

Exemple Adventure Works Cycles

Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations, consultez Exemples et exemples de base de données.

Adventure Works Cycles dispose de nombreuses agences commerciales dans le monde. Chaque agence commerciale collecte les données de son équipe commerciale régionale. Ces données sont transmises à des concentrateurs régionaux, puis au site central à la fin de chaque journée de travail. Les données sont également transmises du site central à chaque agence commerciale par le biais des concentrateurs, afin que ces dernières disposent des dernières informations en termes de prix et de promotions.

Conditions communes requises pour ce scénario

Les applications des bureaux régionaux ont généralement les caractéristiques suivantes, qu'une solution de réplication appropriée doit résoudre :

• Les données sont saisies et mises à jour sur un site central et des sites distants.
• Les utilisateurs distants doivent pouvoir effectuer des mises à jour indépendamment, sans recours à une connexion au site central.
• Du fait que plusieurs utilisateurs puissent mettre à jour les mêmes données indépendamment, des conflits de données peuvent se produire et doivent être gérés.
• Certaines données doivent être mises à jour uniquement sur le site central, comme les données des tables de prix des produits.
• Les utilisateurs doivent pouvoir synchroniser les données à la demande ou à des heures planifiées.
• L'application doit contrôler la durée pendant laquelle un site distant peut rester non synchronisé.
• Certaines tables nécessitent d'être filtrées afin que chaque utilisateur reçoive des données différentes pour une ou plusieurs tables. Par exemple, un bureau régional reçoit des coordonnées des clients de sa région uniquement.
• Certaines données doivent être traitées en tant qu'unité quand elles sont transférées entre sites. Par exemple, si une commande est envoyée d'un utilisateur distant au site central, l'en-tête de la commande doit être validée avant les détails de la commande.
• L'application peut nécessiter l'exécution d'une logique métier personnalisée quand les données sont synchronisées.
• L'application peut nécessiter que les données soient synchronisées via Internet plutôt que par le biais d'une connexion dédiée.
• L'entreprise peut être organisée de telle sorte que les données circulent à travers une ou plusieurs couches intermédiaires entre le site central et les sites distants (comme dans le diagramme décrit précédemment dans cette rubrique).

Le diagramme suivant illustre le filtrage associé à ce scénario :

Type de réplication à utiliser pour ce scénario

Microsoft SQL Server utilise une métaphore de l'industrie de la publication pour décrire les composants du système de réplication. Les composants comprennent le serveur de publication, les abonnés, les publications et articles, et les abonnements. Dans le diagramme ci-dessus, le site central est le serveur de publication. Les données sur le site central représentent la publication, avec chaque table de données représentant un article (les articles peuvent également être d'autres objets de base de données, comme les procédures stockées). Chaque concentrateur est un Abonné à la publication et reçoit un schéma et des données comme abonnement. Les concentrateurs republient ensuite les données, et les bureaux régionaux s'abonnent à ces données. Pour plus d'informations sur les composants du système, consultez Présentation du modèle de publication de réplication.

SQL Server offre différents types de réplication pour différents besoins d'application : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. Ce scénario est mieux implémenté avec la réplication de fusion, davantage conçue pour gérer les besoins décrits dans la section précédente. Pour plus d'informations sur la réplication de fusion, consultez Présentation de la réplication de fusion et Fonctionnement de la réplication de fusion.

Important :

Il est possible d'implémenter ce scénario de deux façons : le bureau central est un serveur de publication et les bureaux distants sont les abonnés, ou le bureau central est un abonné et les bureaux distants sont les serveurs de publication. La réplication de fusion ne prend pas en charge les topologies d'abonné central. Mêmes si toutes les modifications se produisent sur les sites distants, les bureaux centraux doivent être configurés comme étant le site de publication et les sites distants comme étant les abonnés. Un scénario similaire peut être implémenté avec une réplication transactionnelle utilisant une topologie d'abonné central. Si votre application ne nécessite pas de résolution de conflits ou de filtres fournissant à chaque site un ensemble de données unique, envisagez d'utiliser la réplication transactionnelle. Pour plus d'informations, consultez Intégration de données provenant de plusieurs sites (Serveur).

Options de réplication de fusion relatives à ce scénario

La réplication de fusion dispose de nombreuses options permettant de répondre aux conditions requises décrites précédemment dans cette rubrique. La liste suivant présente chaque condition requise et les options de réplication de fusion permettant d'y répondre.

• Les données sont saisies et mises à jour sur un site central et des sites distants.
  La réplication de fusion offre cette possibilité sans spécifier d'options supplémentaires.
• Les utilisateurs distants doivent pouvoir effectuer des mises à jour indépendamment, sans recours à une connexion au site central.
  La réplication de fusion offre cette possibilité sans spécifier d'options supplémentaires.
• Du fait que plusieurs utilisateurs puissent mettre à jour les mêmes données indépendamment, des conflits de données peuvent se produire et doivent être gérés.
  La réplication de fusion fournit la détection et la résolution de conflits dans les cas où des conflits de données sont attendus. Il est préférable de concevoir des applications pour éviter les conflits, mais quand cela n'est pas possible, vous pouvez sélectionner le mécanisme de résolution des conflits par défaut (traités par ordre d'arrivée) ou utiliser une résolution de conflits personnalisée. Pour plus d'informations, consultez Détection et résolution de conflits de réplication de fusion.
• Certaines données doivent être mises à jour uniquement sur le site central, comme les données des tables de prix des produits.
  La réplication de fusion fournit des articles en téléchargement seul pour les tables devant être mises à jour uniquement sur le serveur de publication. Pour plus d'informations, consultez Optimisation des performances de la réplication de fusion avec les articles en téléchargement seul.
• Les utilisateurs doivent pouvoir synchroniser les données à la demande et à des heures planifiées.
  La réplication offre deux types d'abonnements : les abonnements par envoi de données (push) et par extraction de données (pull). Les abonnements par extraction de données (pull) sont mieux adaptés pour la synchronisation à la demande. Pour plus d'informations sur les types d'abonnements et la planification de la synchronisation, consultez Abonnement à des publications et Synchronisation des données.
• L'application doit contrôler la durée pendant laquelle un site distant peut rester non synchronisé.
  La réplication de fusion vous permet de définir une période d'expiration d'abonnement afin de s'assurer que tous les abonnés se sont synchronisés dans un temps imparti. Pour plus d'informations, consultez Expiration et désactivation des abonnements.
• Certaines tables nécessitent d'être filtrées afin que chaque utilisateur reçoive des données différentes pour une ou plusieurs tables. Par exemple, chaque commercial peut ne recevoir des coordonnées que pour ses clients.
  La réplication de fusion vous permet de filtrer les colonnes et les lignes. Les filtres de lignes peuvent être statiques ou paramétrables. Un filtre statique est appliqué uniquement quand une publication est créée, il en résulte un ensemble de données. Un filtre paramétré est appliqué à chaque fois que l'Abonné se synchronise, il en résulte un ensemble de données différent pour chaque abonné. Les applications des bureaux régionaux utilisent souvent les filtres paramétrés, mais peuvent également se servir des filtres statiques. Pour plus d'informations, consultez Filtrage des données publiées en vue de la réplication de fusion.
• Certaines données doivent être traitées en tant qu'unité quand elles sont transférées entre sites. Par exemple, si une commande est envoyée d'un utilisateur distant au site central, l'en-tête de la commande doit être validée avant les détails de la commande.
  La réplication de fusion vous permet d'indiquer qu'un ensemble de tables liées doit être traité en tant qu'unité. Cette unité est appelée un enregistrement logique. Pour plus d'informations, consultez Regroupements des modifications apportées à des lignes connexes à l'aide d'enregistrements logiques.
• L'application peut nécessiter l'exécution d'une logique métier personnalisée quand les données sont synchronisées.
  La réplication de fusion vous permet de spécifier un code à exécuter pendant la synchronisation. Ce code peut répondre à une large plage d'événements et dispose d'un accès aux données qui sont synchronisées. Pour plus d'informations, consultez Exécution de la logique métier lors de la synchronisation de fusion.
• L'application peut nécessiter que les données soient synchronisées via Internet plutôt que par le biais d'une connexion dédiée.
  Lors de l'utilisation de SQL Server Compact Edition (SQL Server 2005 Compact Edition), les données sont synchronisées sur une connexion HTTP ou HTTPS. Pour les autres versions de SQL Server, vous pouvez utiliser la synchronisation Web ; celle-ci nécessite HTTPS. Pour plus d'informations, consultez Synchronisation Web pour la réplication de fusion.
• L'entreprise peut être organisée de telle sorte que les données circulent à travers une ou plusieurs couches intermédiaires entre le site central et les sites distants.
  La réplication de fusion peut adapter cette condition à l'aide d'une republication, approche par laquelle un serveur central de publication publie des données sur un ou plusieurs abonnés, qui à leur tout publient les données sur d'autres abonnés. Pour plus d'informations, consultez Republication des données.

Étapes d'implémentation de ce scénario

Pour implémenter ce scénario, vous devez d'abord créer une publication et des abonnements, puis initialiser chaque abonnement. Cliquez sur les liens ci-dessous pour plus d'informations sur chaque étape :

• Configuration de la distribution
• Publication de données et d'objets de base de données
• Abonnement à des publications
• Initialisation d'un abonnement

Une fois que l'abonnement est initialisé et que les données circulent entre le serveur de publication et les abonnés, vous devrez peut-être consulter les rubriques suivantes afin d'obtenir des informations sur les tâches communes d'administration et d'analyse :

• Gestion de la réplication
• Stratégies de sauvegarde et de restauration de la réplication de fusion
• Résolution des problèmes de réplication
• Suppression de la réplication

Voir aussi

Concepts

Réplication de données entre un serveur et des clients

Aide et Informations

Assistance sur SQL Server 2005