Synchronisation et versionnement
Cette rubrique s'applique uniquement à ArcGIS for Desktop Standard et ArcGIS for Desktop Advanced.
La réplication de géodatabases utilise le versionnement lors du processus de synchronisation pour les réplicas hébergés dans les géodatabases ArcSDE. L'utilisation de l'archivage pour le suivi des mouvements dans une réplication monodirectionnelle constitue une exception.
Le versionnement permet de déterminer le moment où les modifications doivent être envoyées et reçues. Les sections suivantes décrivent l'utilisation du versionnement dans chacun de ces processus :
Envoi des modifications
Lorsqu'un réplica envoie des modifications, ArcSDE détermine les mises à jour à envoyer en analysant la version du réplica (définie lors de la création du réplica) et certaines versions de système. Ces analyses permettent de filtrer les mises à jour déjà envoyées lors de synchronisations antérieures ou de définir les modifications devant être envoyées à nouveau. Pour les réplicas d'extraction dans des géodatabases fichier ou personnelles, une table interne contenant toutes les modifications est analysée. Pour la réplication monodirectionnelle utilisant l'archivage, la classe d'archive est analysée pour déterminer les modifications à envoyer.
Réception des modifications
Lorsqu'un réplica reçoit des modifications, les événements suivants se produisent :
Les modifications sont d'abord appliquées à la version de synchronisation. La version de synchronisation est un enfant de la version du réplica. Elle est conçue pour stocker temporairement ces modifications jusqu'à ce qu'elles soient réconciliées et réinjectées dans la version du réplica. Pour les réplicas bidirectionnels et monodirectionnels, la version ne peut pas être créée tant que la synchronisation n'a pas été effectuée, tandis pour les réplicas d'extraction la version est générée au moment de la création. Dans les diagrammes ci-dessous, la version du réplica peut être DEFAULT ou une version nommée.
La version de synchronisation est ensuite réconciliée avec la version du réplica. A ce stade, le comportement dépend du type de réplica :
- Réplicas bidirectionnels : pour les réplicas bidirectionnels, des conflits peuvent survenir lors de la réconciliation. En cas de conflits, une règle de réconciliation permet de déterminer la méthode de résolution de ces conflits. Vous pouvez choisir entre des règles de réconciliation automatique et manuelle lors de la synchronisation. Si aucun conflit n'a été détecté ou que les conflits sont résolus à l'aide d'une règle de réconciliation automatique, la version du réplica est réinjectée avec la version de synchronisation.
- Réplicas d'extraction : pour les réplicas d'extraction, la réconciliation et la réinjection sont des opérations facultatives qui ne sont pas exécutées par défaut. Si vous choisissez de ne pas effectuer de réconciliation ni de réinjection, les modifications restent dans la version de synchronisation. Vous pouvez effectuer manuellement la réconciliation et la réinjection à une date ultérieure. Dans ce cas, le comportement est identique à celui utilisé pour les réplicas bidirectionnels.
- Réplicas monodirectionnels : avec les réplicas monodirectionnels, les modifications de version du réplica sont toujours remplacées et aucun conflit non résolu ne subsiste. Si vous utilisez un type de modèle simple, les données du réplica enfant ne peuvent pas être versionnées. Dans ce cas, les modifications sont directement appliquées aux tables de bases et le versionnement n'est pas utilisé lors de la réception des modifications. Les modifications sont directement écrasées lorsque le réplica enfant est hébergé par une géodatabase personnelle ou fichier.
 |
Une fois les modifications réinjectées dans la version du réplica, la version de synchronisation est supprimée. Si vous choisissez une règle de réconciliation manuelle et que des conflits subsistent, vous pouvez décider d'effectuer vous-même ultérieurement la réconciliation et la réinjection. Pour les réplicas bidirectionnels, tant que la version de synchronisation existe, le réplica est considéré conflictuel. Dans ce cas, les modifications peuvent être reçues par le réplica, mais pas envoyées à partir du réplica.
 |
Remarque :