Disponible avec une licence Standard ou Advanced.
La réplication de géodatabase utilise le versionnement pendant le processus de synchronisation sur les réplicas hébergés dans des géodatabases d’entreprise. La seule exception concerne l’utilisation de l’archivage pour le suivi des modifications lors d’une réplication monodirectionnelle.
Le versionnement permet de déterminer les modifications à envoyer et à quel moment ces dernières doivent être réceptionnées. Voici comment le versionnement est utilisé dans chacun des processus suivants :
Envoi des modifications
Lorsqu’un réplica envoie des modifications, une analyse de la version de réplication (définie lors de la création du réplica) et des versions de système est effectuée. Cette analyse peut filtrer et exclure les mises à jour déjà envoyées lors de synchronisations antérieures ou déterminer que certaines modifications doivent être renvoyées. Pour les réplicas d’extraction dans les géodatabases fichier ou personnelles, une table interne contenant toutes les mises à jour est analysée. Pour la réplication monodirectionnelle avec utilisation de l’archivage, la classe d’archive est analysée pour déterminer quelles sont les modifications à envoyer.
Réception des modifications
Lorsqu’un réplica reçoit des modifications, voici ce qui se produit :
Tout d’abord, les modifications sont appliquées à la version de synchronisation. La version de synchronisation est un enfant de la version de réplica. Elle est conçue pour contenir temporairement ces modifications jusqu’à leur réconciliation et leur réinjection dans la version de réplica. Pour les réplicas bidirectionnels et monodirectionnels, il est possible que la version ne soit pas créée avant la synchronisation. En revanche, pour les réplicas d’extraction, la version est créée lors de leur création. Dans les diagrammes ci-dessous, la version de réplica peut être DEFAULT ou une version nommée.
Ensuite, la version de synchronisation est réconciliée par rapport à la version de réplica. Le type de réplica détermine le comportement lors de cette étape :
- Réplicas bidirectionnels : dans le cas de réplicas bidirectionnels, il peut y avoir des conflits lors de l’opération de réconciliation. En cas de conflits, une règle de réconciliation permet de déterminer leur mode de gestion. Lors de la synchronisation, vous avez le choix entre des règles de réconciliation automatiques ou manuelles. S’il n’y a aucun conflit, ou qu’une règle de réconciliation automatique résout automatiquement les conflits, la version de réplica est réinjectée dans la version de synchronisation.
- Réplicas d’extraction : les processus de réconciliation et de réinjection sont facultatifs et ne sont pas exécutés par défaut. Si vous choisissez de ne pas procéder à la réconciliation et à la réinjection, les modifications sont conservées dans la version de synchronisation. Vous pouvez ensuite effectuer manuellement la réconciliation et la réinjection ultérieurement. Si vous choisissez de procéder à la réconciliation et à la réinjection, le comportement est identique à celui des réplicas bidirectionnels.
- Réplicas monodirectionnels : dans le cas des réplicas monodirectionnels, les modifications apportées à la version de réplica sont toujours remplacées et il n'existe jamais de conflit non résolu. Si un type de modèle simple est utilisé, les données du réplica enfant risquent de ne pas être versionnées. Dans ce cas, les modifications sont appliquées directement aux tables de base et le versionnement n'est pas utilisé lors de leur réception. De même, les modifications sont remplacées directement si le réplica enfant est hébergé dans une géodatabase fichier ou personnelle.
Une fois que les modifications ont été réinjectées dans la version de réplica, la version de synchronisation est supprimée. Si vous choisissez une règle de réconciliation manuelle et qu'il n'existe aucun conflit, c'est à vous de procéder à la réconciliation et à la réinjection de votre côté ultérieurement. Pour les réplicas bidirectionnels, tant que la version de synchronisation existe, le réplica est considéré comme étant en conflit. Le réplica en conflit peut recevoir les modifications, mais il ne peut pas en envoyer.
