Échange de données avec des utilisateurs mobiles
La fourniture et la collecte de données auprès des utilisateurs mobiles est une partie essentielle de nombreuses applications. La plupart des applications qui prennent en charge les utilisateurs mobiles entrent dans deux grandes catégories :
La gestion de la relation client (Customer relationship management - CRM) et l'automatisation de la force de vente (Sales Force Automation - SFA)
Par exemple, un vendeur peut utiliser une application SFA pour saisir les données d'une commande lors d'une visite à un client. Ces données sont ensuite retransmises vers un lieu central, par exemple le siège social de l'entreprise ou un centre de données.
Automatisation des forces de terrain (Field force automation - FFA)
Par exemple, des travailleurs sur le terrain – chauffeurs livreurs, techniciens de maintenance, inspecteurs, etc. – peuvent utiliser une application FFA installée sur un périphérique portable pour collecter et transmettre des données à partir de lieux distants. Un chauffeur livreur pourrait saisir sur le lieu de livraison des données sur les livraisons de colis, données qui seraient ensuite retransmises vers un site central.
Ces deux catégories d'applications nécessitent des fonctions de réplication très similaires. Leur différence essentielle réside dans le fait que les données sont ou non mises à jour par plus d'un utilisateur. Cette question est traitée dans la section « Conditions communes pour ce scénario », dans cette rubrique.
Les diagrammes qui suivent illustrent deux approches différentes de la fourniture de données aux utilisateurs mobiles : l'une utilise des ordinateurs portables et l'autre des périphériques (qui exécutent Microsoft SQL Server Compact 3.5 SP2). La première approche est plus couramment utilisée avec les applications SFA et CRM, la seconde avec les applications FFA. Cependant, toutes deux conviennent pour ces trois catégories d'applications.
Le premier diagramme illustre un scénario dans lequel un ensemble d'utilisateurs équipés d'ordinateurs portables se connectent à un site central :
.gif "Réplication de données à partir des vendeurs vers les sièges")
Le second illustre un scénario dans lequel des utilisateurs équipés de périphériques se connectent via des serveurs Microsoft Windows Internet Information Services (IIS) à un site central. Des serveurs IIS sont nécessaires lorsque SQL Server Compact 3.5 SP2 est utilisé.
.gif "Réplication de données vers les chauffeurs livreurs")
Exemples 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.
Adventure Works Cycles dispose d'une importante force de vente qui passe une part considérable de son temps sur le terrain, à travailler directement avec les principaux clients de l'entreprise, les distributeurs indépendants et franchisés de bicyclettes. Les équipes de vendeurs sont affectées à des régions et chaque vendeur gère ses propres clients. Cependant, les données clients peuvent être partagées par les vendeurs et les responsables commerciaux. Les vendeurs entrent les commandes sur leurs ordinateurs portables et transmettent ces données au siège au moment qui leur convient.
Adventure Works Cycles utilise les services de la société A-1 Shipping pour ses livraisons de pièces et de bicyclettes. Les chauffeurs livreurs de A-1 Shipping utilisent tous des périphériques équipés de SQL Server Compact 3.5 SP2. Ils entrent les données de chaque livraison une fois qu'elle est terminée. Ces données sont répliquées vers le bureau central de A-1 Shipping puis supprimées du périphérique. Les données sont alors mises à la disposition de Adventure Works Cycles via un extranet clients.
Conditions communes pour ce scénario
Les applications CRM, SFA et FFA présentent en général les caractéristiques suivantes, auxquelles doit répondre une solution de réplication appropriée :
La synchronisation des données doit être programmable, pour permettre la personnalisation d'une application sur ordinateur portable ou sur périphérique en vue d'y intégrer la synchronisation, l'utilisateur final ne connaissant pas la réplication.
La plupart des applications mobiles permettent d'entrer et d'actualiser les données sur le site central et sur les sites distants. Dans les applications FFA, la plupart des données sont entrées sur des sites distants.
Les utilisateurs distants entrent et actualisent les données sur un ordinateur portable, un périphérique ou un Tablet PC.
Les utilisateurs distants doivent avoir la faculté de faire leurs mises à jour de façon autonome, sans se connecter à un site central.
Plusieurs utilisateurs pouvant actualiser les mêmes données de façon autonome, il peut s'élever des conflits de données, qui doivent être gérés.
Certaines données ne doivent être mises à jour que sur le site central ; c'est le cas des données de tarification des produits.
Les utilisateurs doivent avoir la possibilité de synchroniser les données à la demande, plutôt qu'à heures fixes.
L'application doit décider d'un délai maximal entre deux synchronisations d'un site distant.
Certaines tables doivent être filtrées pour que chaque utilisateur puisse recevoir des données différentes pour une ou plusieurs tables. Par exemple, un vendeur ne reçoit les informations de contact que pour ses propres clients.
Certaines données doivent être traitées comme une unité lors de leur transfert entre sites. Si par exemple un utilisateur distant envoie une commande vers le site central, l'en-tête de commande doit être validé avant les détails de la commande.
L'application peut nécessiter qu'une logique métier personnalisée soit exécutée lors de la synchronisation des données.
L'application peut nécessiter que les données soient synchronisées sur Internet plutôt que sur un réseau privé virtuel ou une connexion à distance IPSEC.
La différence essentielle entre les applications CRM et SFA et les applications FFA en ce qui concerne la réplication, réside dans le nombre d'utilisateurs - un seul ou plusieurs - qui actualisent les données (l'actualisation par plusieurs utilisateurs peut provoquer des conflits). Le volume des données mises à jour par plusieurs utilisateurs dépend du niveau de filtrage des données. Si par exemple chaque utilisateur ne reçoit que son propre jeu de données, aucun conflit n'intervient entre les utilisateurs :
Dans les applications CRM et SFA, les données sont souvent filtrées, mais certaines sont malgré tout actualisées en plusieurs endroits. Certaines données ne sont mises à jour qu'au siège social, certaines par un seul utilisateur distant, et certaines par plusieurs utilisateurs distants. Le diagramme ci-dessous illustre le filtrage commun aux applications CRM et SFA :
.gif "Filtrage d'applications d'automatisation des groupes opérationnels")
Dans les applications FFA, il est courant que les données soient essentiellement collectées sur le terrain, puis téléchargées vers le siège sans aucun conflit, parce qu'un seul utilisateur distant actualise une donnée spécifique. Le diagramme ci-dessous illustre le filtrage commun aux applications FFA :
.gif "Filtrage d'applications d'automatisation des groupes opérationnels")
Type de réplication à utiliser pour ce scénario
SQL Server utilise une métaphore du secteur de l'édition pour décrire les composants du système de réplication. Ces composants sont le serveur de publication, les Abonnés, les publications et articles et les abonnements. Dans les deux premiers diagrammes ci-dessus, le site central est le serveur de publication. Les données du site central sont la publication, chaque table de données étant un article (les articles peuvent aussi être d'autres objets de bases de données, tels que des procédures stockées). Les ordinateurs portables des vendeurs et les périphériques des chauffeurs livreurs représentent chacun un Abonné à la publication, et reçoivent comme abonnement des schémas et des données. Pour plus d'informations sur les composants de ce 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 des applications : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. La plus adaptée à ce scénario est la réplication de fusion, qui convient bien pour prendre en compte les conditions exposées dans la section qui précède. 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 convenant à ce scénario
La réplication de fusion offre plusieurs options qui répondent aux conditions décrites plus haut dans cette rubrique. La liste qui suit présente chaque condition et la ou les options de réplication de fusion qui y répondent.
La synchronisation des données doit être programmable.
La réplication offre une fonction de programmation avec les procédures stockées et les objets RMO (Replication Management Objects). Les objets RMO sont en général utilisés pour les applications mobiles. Pour plus d'informations sur la programmation de la réplication, consultez Guide du développeur (réplication) et Sales Orders Sample Scenario.
La plupart des applications mobiles permettent d'entrer et d'actualiser les données sur le site central et sur les sites distants. Dans les applications FFA, la plupart des données sont entrées sur des sites distants.
La réplication de fusion offre cette possibilité sans nécessiter la spécification d'options séparées.
Les utilisateurs distants entrent et actualisent les données sur un ordinateur portable, un périphérique ou un Tablet PC.
Les ordinateurs portables et les Tablet PC peuvent exécuter SQL Server Standard et d'autres éditions (y compris SQL Server Compact 3.5 SP2), mais les Pocket PC requièrent SQL Server Compact 3.5 SP2. La réplication de fusion vous permet de créer des publications et des abonnements utilisables par SQL Server Compact 3.5 SP2. Pour plus d'informations, consultez Réplication de données vers SQL Server Compact.
Les utilisateurs distants doivent avoir la faculté de faire leurs mises à jour de façon autonome, sans se connecter à un site central.
La réplication de fusion offre cette possibilité sans nécessiter la spécification d'options séparées.
Plusieurs utilisateurs pouvant actualiser les mêmes données de façon autonome, il peut s'élever des conflits de données, qui doivent être gérés.
La réplication de fusion offre la détection et la résolution de conflit pour les cas où des conflits sont prévisibles. Il est préférable de bâtir les applications de façon à éviter les conflits, mais lorsque ce n'est pas possible vous pouvez sélectionner le mécanisme de résolution de conflit par défaut (le meilleur) ou utiliser une résolution de conflit personnalisée. 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 ; c'est le cas des données de tarification des produits.
La réplication de produits propose des articles en téléchargement seul, pour les tables qui ne doivent être actualisées qu'au niveau du 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 avoir la possibilité de synchroniser les données à la demande, plutôt qu'à heures fixes.
La réplication offre deux types d'abonnements : les abonnements par envoi de données et les abonnements par extraction de données. Les abonnements par envoi de données conviennent mieux 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 décider d'un délai maximal entre deux synchronisations d'un site distant.
La réplication de fusion vous permet de définir une période d'expiration d'abonnement, pour garantir que tous les Abonnés effectuent leur synchronisation dans un délai déterminé. Pour plus d'informations, consultez Expiration et désactivation des abonnements.
Certaines tables doivent être filtrées pour que chaque utilisateur puisse recevoir des données différentes pour une ou plusieurs tables. Par exemple, un vendeur peut ne recevoir que les informations de contact de ses propres clients.
La réplication de fusion vous permet de filtrer les lignes et les colonnes. Les filtres de lignes peuvent être statiques ou paramétrés. Un filtre statique n'est appliqué qu'à la création d'une publication ; il produit un seul jeu de données. Un filtre paramétré est appliqué chaque fois qu'un Abonné effectue une synchronisation ; il produit un jeu de données distinct pour chaque Abonné. Les applications CRM et SFA utilisent souvent des filtres paramétrés, mais elles 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.
Certaines données doivent être traitées comme une unité lors de leur transfert entre sites. Si par exemple un utilisateur distant envoie une commande vers le site central, l'en-tête de commande doit être validé avant les détails de la commande.
La réplication de fusion vous permet de spécifier qu'un jeu de tables associées doit être traité comme une unité. Cette unité est appelée 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 qu'une logique métier personnalisée soit exécutée lors de la synchronisation des données.
La réplication de fusion vous permet de spécifier un code à exécuter durant la synchronisation. Ce code peut réagir à un large éventail d'événements et a accès 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 que les données soient synchronisées sur Internet plutôt que sur 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 :
Après initialisation d'un abonnement, lorsque les données circulent entre le serveur de publication et les Abonnés, peut-être aurez-vous besoin de consulter les rubriques qui suivent pour vous informer sur les tâches d'administration et de surveillance courantes :