Applications POS
Les applications POS (Consumer point-of-sale) sont celles que les consommateurs trouvent directement ou indirectement sur un point de vente. À titre d'exemple, citons les terminaux utilisés par les caissiers, les ordinateurs ATM et les bornes de grand magasins. Les données sont collectées sur des sites distants et transmises vers un lieu centralisé, comme le siège social d'une entreprise ou un centre de données. Dans ces applications, il est courant que les données sont d'abord recueillies sur le point de vente, puis téléchargées vers le siège social sans conflit car un utilisateur distant unique (généralement un client ou un commercial) met à jour des segments de données précis.
Le diagramme suivant illustre un scénario classique dans lequel des données sont transmises de part et d'autre d'un site central et de lieux distants :
.gif "Réplication de données à partir des magasins vers les sièges")
Exemple de la société 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 de bases de données AdventureWorks2008R2.
De nombreux magasins de détail commercialisant des produits Adventure Works Cycles utilisent des systèmes de point de vente qui reçoivent des données d'un site central et les leur transmet. En général, des données en lecture seule sur la tarification des produits et les stocks sont envoyées au détaillant à chaque mise à jour. Les informations d'achat de la clientèle sont transmises de chaque magasin de détail vers le site central.
Besoins courants pour ce scénario
En général, les applications POS présentent un certain nombre de caractéristiques dont doit tenir compte une solution de réplication appropriée :
La plupart des données sont saisies et mises à jour sur les sites distants.
Les utilisateurs distants doivent pouvoir faire des mises à jour en mode autonome, sans avoir à se connecter au site central.
Les données mises à jour sur un site distant ne sont pas mises à jour sur les autres sites, d'où des conflits fréquents.
Certaines données ne doivent être mises à jour que sur le site central, par exemple les données des tableaux descriptifs de produits.
Les utilisateurs synchronisent les données à intervalles planifiés (en fin de journée par exemple).
L'application doit contrôler la durée pendant laquelle un site distant peut rester sans synchronisation.
Certaines tables ont besoin d'être filtrées afin que chaque magasin puisse recevoir des données différentes issues d'une ou de plusieurs tables. Par exemple, chaque magasin reçoit des informations portant uniquement sur les produits qu'il stocke.
L'application peut nécessiter l'exécution d'une logique métier personnalisée lors de la synchronisation des données.
L'application peut nécessiter la synchronisation des données sur Internet plutôt que par le biais d'une connexion dédiée.
Le diagramme suivant illustre le filtrage associé à ce scénario :
.gif "Filtrage d'applications de point de vente")
Type de réplication à utiliser pour ce scénario
Microsoft SQL Server utilise une métaphore dans le secteur de la publication pour décrire les composants du système de réplication. Ces composants incluent le serveur de publication, les Abonnés, les publications et les articles, ainsi que les abonnements. Dans le diagramme ci-dessus, le site central est le serveur de publication. Les données situées sur le site central sont la publication, chaque table de données étant un article (les articles peuvent également être d'autres objets de données tels que des procédures stockées). Chaque terminal de point de vente est un Abonné à la publication qui reçoit le schéma et les données en tant qu'abonnement. Pour plus d'informations sur les composants du système, consultez Présentation du modèle de publication de réplication.
SQL Server propose plusieurs types de réplication répondant à des besoins applicatifs précis : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. La mise en œuvre de ce scénario est plus efficace avec la réplication de fusion qui convient bien au traitement des besoins présentés 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.
Options de réplication de fusion adaptées à ce scénario
La réplication de fusion propose plusieurs options pour répondre aux besoins décrits plus haut dans cette rubrique. La liste suivante présente chaque besoin ainsi que les options de réplication de fusion adaptées.
La plupart des données sont saisies et mises à jour sur les sites distants.
La réplication de fusion fournit cette fonctionnalité sans spécification d'options distinctes.
Les utilisateurs distants doivent pouvoir faire des mises à jour en mode autonome, sans avoir à se connecter au site central.
La réplication de fusion fournit cette fonctionnalité sans spécification d'options distinctes.
Les données mises à jour sur un site distant ne sont pas mises à jour sur les autres sites, d'où des conflits fréquents.
Dans les applications POS, les conflits sont souvent évités car un utilisateur unique met à jour des segments de données précis. Comme les données ne se chevauchent pas entre les utilisateurs, il est possible d'optimiser les performances à l'aide l'option de partitions qui ne se chevauchent pas. Pour plus d'informations, consultez la section « Définition des options de partition » de la rubrique Filtres de lignes paramétrés.
La réplication de fusion fournit la détection et la résolution des conflits en cas d'éventuels conflits de données. Pour plus d'informations, consultez Détection et résolution de conflits de réplication de fusion.
Certaines données ne doivent être mises à jour que sur le site central, par exemple des données de tableaux de prix de produits.
La réplication de fusion fournit des articles en téléchargement seul pour les tables que doivent ê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 des données à la demande plutôt qu'à intervalles réguliers.
La réplication offre deux types d'abonnement : les abonnements par envoi de données (push) et les abonnements par extraction de données (pull). Les abonnements par envoi de données sont plus adaptés à la synchronisation à la demande. Pour plus d'informations sur les types d'abonnement et sur 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 sans synchronisation.
La réplication de fusion permet de définir une période d'expiration des abonnements pour s'assurer que tous les Abonnés ont synchronisé dans un temps donné. Pour plus d'informations, consultez Expiration et désactivation des abonnements.
La plupart des tables ont besoin d'être filtrées afin que chaque utilisateur puisse recevoir des données différentes issues d'une ou de plusieurs tables.
La réplication de fusion permet de filtrer des colonnes et des lignes. Les filtres de lignes peuvent être statiques ou paramétrés. Un filtre statique est appliqué uniquement lors de la création d'une publication ; il renvoie un jeu de données unique. Un filtre paramétré est appliqué à chaque synchronisation d'un Abonné ; il renvoie un jeu de données différent pour chaque Abonné. Les applications POS utilisent souvent des filtres paramétrés mais peuvent aussi utiliser des filtres statiques. Pour plus d'informations, consultez Filtrage des données publiées en vue de la réplication de fusion.
L'application peut nécessiter l'exécution d'une logique métier personnalisée lors de la synchronisation des données.
La réplication de fusion permet de spécifier le code qui sera exécuté pendant la synchronisation. Ce code peut répondre à une plage complète d'événements et accède aux données en cours de synchronisation. Pour plus d'informations, consultez Exécution de la logique métier lors de la synchronisation de fusion.
L'application peut nécessiter la synchronisation des données sur Internet plutôt que par le biais d'une connexion dédiée.
Lors de l'utilisation de SQL Server Compact 3.5 SP2, les données sont synchronisées via une connexion HTTP ou HTTPS. Pour les autres éditions de SQL Server, vous pouvez utiliser la synchronisation Web qui nécessite HTTPS. Pour plus d'informations, consultez Synchronisation Web pour la réplication de fusion.
Procédure de mise en œuvre de ce scénario
Pour mettre en œuvre ce scénario, vous devez tout 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 :
Une fois l'abonnement initialisé et les données acheminées entre le serveur de publication et les Abonnés, vous pouvez consulter les rubriques suivantes pour obtenir des informations sur les tâches de surveillance et d'administration communes :