La synchronisation déconnectée est le processus consistant à synchroniser manuellement les réplicas afin de transférer des données dans un environnement déconnecté. Ce processus manuel d’échange de messages est réalisé en exportant un message d’un réplica vers un fichier et en important le message du fichier dans le réplica associé. Voir le processus de synchronisation déconnectée.
Remarque :
Les différents aspects de la réplication déconnectée et de la synchronisation sont réalisables via l’échange de fichiers contenant des messages entre les paires de réplicas. Ces messages permettent d’effectuer plusieurs tâches et peuvent être échangés à l’aide d’une géodatabase fichier (.gdb) ou d’un fichier XML (.xml) :
Création de réplica (.gdb ou .xml)
Messages de changement de données (synchronisation) (.gdb ou .xml)
Messages d’accusé de réception (.xml)
Dans les environnements déconnectés, les fichiers .gdb ou .xml peuvent être transférés sur des supports tel que des périphériques de stockage externes (par exemple, des clés USB, des cartes SD ou cartes mémoire, des disques durs externes, des CD ou des DVD) et envoyés à l'aide d'un agent de distribution, tel qu’un courrier électronique, un transporteur privé ou des services de distribution de colis.
Un réplica peut à tout moment être un expéditeur de données ou un destinataire de données. Un expéditeur de données exporte les messages de changement de données vers les fichiers de deltas qui contiennent les changements à appliquer au réplica associé. Un destinataire de données importe les messages de changement de données et exporte les messages d’accusé de réception vers les fichiers d’accusé de réception pour confirmer la réception. Vous pouvez savoir si un réplica est un destinataire de données ou un expéditeur de données en consultant son état qui est mentionné sur la fiche du réplica dans la fenêtre Manage Replicas (Gérer les réplicas). Pour une présentation de la fenêtre Manage Replicas (Gérer les réplicas), reportez-vous à la rubrique Accéder à la fenêtre Manage Replicas (Gérer les réplicas).
Processus de synchronisation déconnectée
Pour les réplicas figurant dans un environnement déconnecté, la synchronisation est possible via un processus d’échange manuel de messages entre les réplicas. Ce processus manuel d’échange de messages est mené en faisant appel à une combinaison de plusieurs outils de géotraitement et suit le modèle élémentaire de synchronisation déconnectée, décrit et illustré ci-dessous.
Les mises à jour sont effectuées.
Les mises à jour sont effectuées et enregistrées dans la géodatabase (Géodatabase 1).
Exportez les modifications de données de l'expéditeur de données.
Dans cet exemple, un triangle orange appelé également un delta, est utilisé pour représenter les changements de données ou différences.
L'expéditeur de données utilise l'outil de géotraitement Export Data Change Message (Exporter le message de changement de données) pour exporter toutes les nouvelles mises à jour de données du réplica parent vers un message de changement de données qui peut être conservé sous forme de géodatabase fichier (.gdb) ou de fichier XML (.xml).
Remarque :
Dans les environnements déconnectés, les fichiers .gdb ou .xml peuvent être transférés sur des supports tels que des périphériques de stockage externes (par exemple, des clés USB, des cartes SD ou cartes mémoire, des disques durs externes, des CD ou des DVD) et envoyés à l'aide d'un agent de distribution.
Le destinataire des données importe le message de changement de données.
Le destinataire des données utilise l’outil de géotraitement Import Message (Importer un message) pour importer le fichier de message de changement de données conservé sous forme de géodatabase fichier (.gdb) ou de fichier XML (.xml) vers le réplica du destinataire des données (Géodatabase 2).
L’importation d’un changement de données applique les changements de données à partir du réplica associé et met également à jour les métadonnées du réplica.
L'expéditeur de données ne se trouvant pas dans un environnement connecté avec le destinataire des données, il ne sait pas si les changements de données ont été reçus et importés par le destinataire. Par conséquent, il est important que le destinataire de données exporte et envoie des messages d’accusé de réception le plus souvent possible. Si aucun message d’accusé de réception n’est reçu, l’expéditeur des données renvoie par défaut les changements et conserve les informations nécessaires au renvoi de ces changements jusqu’à ce qu’il reçoive un accusé confirmant leur réception par le réplica associé. De ce fait, il arrive que la géodatabase de l’expéditeur des données devienne très volumineuse, tout comme les messages de changement de données suivants.
Dans l’idéal, même si cela n’est nullement obligatoire, le destinataire des données envoie un message d’accusé de réception après la réception de chaque message de changement de données. Il est également important de noter qu’un message d’accusé de réception confirme la réception de tous les messages de changement de données. Si, par exemple, un réplica reçoit trois messages de changement de données et importe chacun d’entre eux, il peut envoyer un seul message d’accusé de réception pour confirmer la réception des trois messages.
L'expéditeur de données utilise l’outil de géotraitement Import Message (Importer un message) pour importer le message d’accusé de réception au format XML et met à jour les métadonnées du réplica de l’expéditeur de données (Géodatabase 1) afin de déterminer les changements à inclure lors de la prochaine exportation.
Jusqu’ici cette rubrique a décrit un modèle élémentaire de processus de synchronisation déconnectée dans lequel des messages sont échangés entre le réplica parent et le réplica enfant. Si vous conservez ce modèle, le système fonctionnera efficacement et sera même capable de s’auto-corriger si des messages sont perdus.
Cependant, vous pouvez également être amené à utiliser les scénarios d’échange de messages spécifiques suivants décrits dans les sections figurant ci-après.
Permuter les rôles
Dans les réplicas bidirectionnels, l’expéditeur et le destinataire de données peuvent inverser leur rôle. La permutation est initiée par l’expéditeur de données qui envoie un message de changement de données comportant des instructions de permutation des rôles. Lorsque le destinataire de données a importé le message, les rôles sont inversés et le système est prêt à envoyer les données dans la direction opposée.
Dans les réplicas monodirectionnels, vous ne pouvez pas inverser les rôles puisque les mises à jour et les changements de données ne vont que dans une seule direction. Dans le cas de réplicas monodirectionnels parent vers enfant, l’expéditeur de données est toujours le réplica parent. Dans le cas de réplicas monodirectionnels enfant vers parent, l’expéditeur de données est toujours le réplica enfant. Quel que soit le cas de figure, il reste crucial pour le destinataire de données d’envoyer des messages d’accusé de réception. Pour les réplicas d’extraction, l’expéditeur de données est toujours le réplica enfant : les messages d’accusé de réception sont superflus. Pour en savoir plus sur les différents types de réplicas, reportez-vous à la rubrique Types de réplication.
Les étapes et les diagrammes suivants expliquent comment le réplica parent envoie un message de changement de données contenant des instructions pour changer le rôle du réplica associé en expéditeur de données.
Assurez-vous que vous êtes connecté à un réplica bidirectionnel.
Pour permuter les rôles, l’expéditeur de données utilise l’outil de géotraitement Export Data Change Message (Exporter un message de changement de données) pour exporter un message de changement de données avec l’option Switch to receiver once the message has been exported (Devenir destinataire après l’exportation du message) cochée.
Lorsque le réplica parent exporte le message de changement de données contenant les instructions de permutation des rôles, il devient le destinataire des données.
Remarque :
Lors de l’utilisation de l’outil Exporter un message de changement de données afin d’inverser les rôles, une option supplémentaire peut être cochée : Don’t include any data change messages (N’inclure aucun message de changement de données). Cette option est utile pour transmettre un message afin de changer de rôle sans envoyer de données. Pour plus d’informations sur cette option, reportez-vous à la rubrique Permuter les rôles sans envoyer de changement de données.
Le destinataire de données utilise l’outil de géotraitement Importer un message pour importer le fichier des messages de changement de données contenant les instructions de permutation des rôles.
Après l’importation, il devient l’expéditeur des données.
Permuter les rôles sans envoyer de changement de données
Il est possible d’envoyer un message de changement de données avec des instructions pour permuter les rôles, mais sans changement de données. Cette opération présente un intérêt si vous devez, en qualité d’expéditeur des données, vous procurer les changements auprès du destinataire des données mais que vous n’êtes pas prêt à envoyer les changements de données. Pour plus d’informations sur l’envoi d’un message afin de permuter les rôles sans envoyer de données, reportez-vous à la rubrique Exporter un message de changement de données.
Accuser réception des changements après permutation des rôles
Après avoir inversé les rôles dans un réplica bidirectionnel, le nouvel expéditeur de données dispose de deux possibilités pour accuser réception du message spécifiant le changement de rôles.
Le nouvel expéditeur de données peut exporter un message d’accusé de réception : dans le diagramme suivant, le réplica parent a envoyé un message de changement de données destiné à permuter les rôles. Dès que le réplica enfant a reçu le message, il devient le destinataire des données, mais puisqu’il vient juste de changer de rôle, le système l’autorise à envoyer un message d’accusé de réception à l’aide de l’outil de géotraitement Exporter un message d’accusé de réception.
Le nouvel expéditeur de données peut envoyer un message de changement de données : dans le diagramme suivant, le réplica parent a envoyé un message de changement de données destiné à permuter les rôles. Dès que le réplica enfant a reçu le message, il devient l’expéditeur de données. À l’aide de l’outil de géotraitement Exporter un message de changement de données, le réplica enfant peut dorénavant envoyer un message de changement de données, qui accuse implicitement réception du message de changement de données précédent issu du réplica parent. Si vous ne prévoyez pas d’envoyer un message de changement de données dans un futur proche, vous devriez envoyer un message d’accusé de réception.
Réexporter un message de changement de données sans accusé de réception
Le système permet aux réplicas de renvoyer les changements de données qui n’ont pas fait l’objet d’un accusé de réception. En tant qu’expéditeur des données, vous souhaiterez peut-être procéder à cette opération si le message de changement de données n’a pas été importé par le destinataire des données, si le message s’est perdu en cours de route ou s’il doit être renvoyé. Une autre solution consiste à attendre le prochain envoi de changement de données, car il inclut, par défaut, à la fois les nouveaux changements et les changements de données sans accusé de réception.
Le diagramme suivant décrit le scénario selon lequel vous devez réexporter un message de changement de données sans accusé de réception. Le réplica parent envoie un message de changement de données et passe du rôle d’expéditeur au rôle de destinataire. Toutefois, le message s’égare alors que réplica parent et le réplica enfant sont tous deux destinataires de données. Pour résoudre ce problème, le destinataire des données qui vient de permuter les rôles utilise l'outil de géotraitement Re-export Unacknowledged Messages (Réexporter les messages sans accusé de réception). Dans ce cas, le réplica parent est autorisé à renvoyer le message de changement de données sans accusé de réception ainsi que les instructions spécifiant le changement de rôle au réplica enfant.
Passer outre le fichier de message d’accusé de réception
Au cours de l’envoi des changements de données, tous les nouveaux changements de données ainsi que les changements de données sans accusé de réception sont envoyés par défaut. Les changements de données comprennent les insertions, les mises à jour et les suppressions appliquées à la version de réplica depuis la dernière exportation du message de changement de données. Les changements de données sans accusé de réception incluent les changements précédemment exportés pour lesquels vous n’avez pas reçu d’accusé de réception. Si vous avez envoyé plusieurs messages de changement de données et que vous n’avez reçu aucun accusé de réception, la taille des fichiers de changement de données peut augmenter considérablement.
La meilleure solution implique que le destinataire de données envoie un fichier de message d’accusé de réception. Cela n’est toutefois pas toujours possible selon le système de communication. Par exemple, si les réplicas sont déconnectés et que l’envoi d’un fichier d’accusé de réception nécessite l’expédition d’un support pour échanger des fichiers, il se peut que vous préfériez envoyer un courrier électronique à la personne chargée de la gestion du réplica de l’expéditeur de données pour l’informer que vous avez reçu et importé les changements de données.
N’oubliez pas cependant que le fait de passer outre le fichier de message d’accusé de réception complique la gestion de la synchronisation.
L’importation de messages d’accusé de réception est la seule façon pour le système de sélectionner les versions système nécessaires au renvoi des changements d’un réplica. Les versions système non sélectionnées peuvent perturber la compression au fil du temps et augmenter considérablement la taille de la géodatabase de l’expéditeur, ce qui peut ralentir les performances de la géodatabase. Pour cette raison, il est important d’envoyer au moins régulièrement des messages d’accusé de réception.
Le fait d’éviter le fichier de message d’accusé de réception nécessite une intervention manuelle accrue à la fois de la part de la personne chargée de la gestion du réplica de l’expéditeur des données et de la personne qui gère le destinataire des données.
Vous pouvez utiliser la fiche de réplica de l'onglet Geodatabase Replicas (Réplicas de géodatabase) de la fenêtre Manage Replicas (Gérer les réplicas) pour déterminer les changements envoyés et reçus par un réplica. Pour éviter d’envoyer un message de changements de données inutilement volumineux, l’expéditeur de données peut désactiver l’option Include unacknowledged data changes (Inclure les changements de données sans accusé de réception) lors de l’envoi de changements de données suivant.
Lorsque vous passez outre l’utilisation du fichier de message d’accusé de réception, votre processus de synchronisation est davantage source d’erreurs.
Les nouveaux changements peuvent être importés par le destinataire de données seulement si les changements précédents ont bien été importés. Si le système détecte que les changements précédemment envoyés n’ont pas été importés, une erreur est renvoyée et le jeu de changements actuel ne peut être importé. Si plusieurs messages de changement de données sont envoyés à la fois, ils doivent être importés dans le bon ordre. Le système renvoie une erreur si vous tentez d’importer dans un ordre incorrect. Lorsqu’une erreur se produit, des messages d’erreur s’affichent. Cependant, si vous utilisez un système automatisé, vous ne serez pas forcément présent lors de l’affichage des erreurs. En pareille situation, vous pouvez utiliser le journal d’activité de réplica pour détecter si des erreurs se sont produites durant la synchronisation.
qui peut être conservé sous forme de géodatabase fichier (.gdb) ou de fichier XML (.xml).
