Scénarios de versions traditionnels

Disponible avec une licence Standard ou Advanced.

Le versionnement peut être appliqué dans divers scénarios et peut varier selon les besoins métier de chaque organisation. Les considérations générales en matière de mise à jour des processus et de configurations de versionnement recommandées sont décrites ci-dessous sous forme d’illustrations.

Les processus varient selon les organisations. Ils évoluent souvent selon des étapes discrètes, chaque étape nécessitant l'attribution d'un ensemble différent de ressources et de règles commerciales. Généralement, chaque étape du processus global représente une seule unité de travail telle qu’un bon de travail. Pour gérer chaque bon de travail, vous pouvez créer une version distincte et isolée, et la modifier. Une fois ce travail effectué, vous pouvez intégrer les modifications à la version publiée de la base de données. En utilisant ainsi les versions, vous pouvez gérer les processus les plus élémentaires et les plus complexes.

Le concept de versionnement reste le même, que vous utilisiez le versionnement de branche ou le versionnement traditionnel. Le versionnement fournit des représentations multiples des données sans les copier, permet de les mettre à jour simultanément et donne la possibilité aux utilisateurs de disposer de versions pendant de longues périodes. Pour plus détails, reportez-vous à la rubrique Vue d’ensemble du versionnement.

Versionnement traditionnel offre une souplesse d’utilisation des versions pour les transactions longues lorsque vous y accédez directement depuis la géodatabase d’entreprise, ainsi qu’une expérience de mise à jour simplifiée lorsque vous utilisez des services d’entités pour les transactions courtes.

Voici un aperçu général du processus de versionnement traditionnel.

Dans la plupart des cas, vous utiliserez une mise à jour simultanée de la configuration de la base de données publiée dans laquelle plusieurs éditeurs modifient la version par défaut, ou une combinaison des autres configurations. La connaissance des exigences organisationnelles et commerciales et l’évaluation des avantages et inconvénients de chaque scénario de version traditionnelle vous aideront à choisir ce qui est le mieux pour votre organisation.

Par souci de simplicité et pour la bonne gestion des géodatabases, nous vous recommandons de conserver une arborescence des versions plate ou d’autoriser la modification simultanée de la version par défaut par plusieurs éditeurs.

Mise à jour de la version par défaut

La version par défaut est la version initiale créée lorsque les données sont inscrites comme versionnées de manière traditionnelle. Lorsque vous utilisez le versionnement traditionnel et que l’accès à la version est défini sur public, plusieurs éditeurs peuvent mettre à jour et consulter simultanément les données en utilisant la version par défaut. La façon la plus simple de prendre en charge l’édition multi-utilisateurs est de permettre à plusieurs éditeurs de mettre à jour directement la version par défaut.

Si l’accès à la version par défaut (orange) est défini sur Public, les utilisateurs Editor peuvent directement mettre à jour la version par défaut. Les Viewers qui se connectent à la version par défaut visualisent les mises à jour apportées à la version par défaut.

Lorsque chaque éditeur commence à modifier la version par défaut, une version temporaire sans nom est automatiquement créée dans la session de mise à jour. Cette version temporaire est accessible uniquement à l'éditeur actuel. Lorsque l’éditeur enregistre son travail ou termine la session de mise à jour, les modifications enregistrées dans la version temporaire sont réinjectées dans la version par défaut.

Si un autre éditeur a modifié la version par défaut depuis que vous avez commencé votre mise à jour, ArcGIS réconcilie et réinjecte automatiquement les modifications lorsque vous enregistrez votre travail. Un message vous avertit que la version a été modifiée et doit être réenregistrée pour appliquer les modifications des autres éditeurs. En cas de conflits, vous devez les résoudre à l’aide de la boîte de dialogue de résolution des conflits avant de pouvoir enregistrer vos modifications.

Éléments à prendre en compte

Tenez compte des avantages et des limitations suivants lorsque vous manipulez ou mettez à jour une version par défaut :

• Avantages
  • Cette stratégie permet également d’effectuer des modifications simples dans la base de données car les utilisateurs n’ont pas besoin de créer de nouvelles versions pour modifier les données. Elle est recommandée lorsque les unités de travail sont relativement petites ou lorsque d'autres solutions de création permanentes sont inutiles.
  • S’il n’y a pas de conflit, les mises à jour enregistrées sont directement injectées dans la version par défaut.
• Limitations
  • La version par défaut change constamment et s’expose donc à des modifications accidentelles ou non autorisées ; en conséquence, l’administrateur de base de données doit effectuer des sauvegardes de base de données plus fréquentes.
  • Les longues transactions et la création d'autres versions de conception réparties sur plusieurs sessions de mise à jour ne sont pas prises en charge.
  • Une seule opération de réconciliation par géodatabase peut être active à un moment donné. En cas d’opérations fréquentes de réconciliation et de réinjection à partir de plusieurs sessions de mise à jour, les éditeurs qui enregistrent leurs modifications doivent éventuellement attendre la fin des processus de réconciliation et de réinjection actifs. Dans une géodatabase multi-utilisateurs volumineuse, il est recommandé d'éviter que de nombreux d'utilisateurs réconcilient et réinjectent une même version. La réconciliation et la réinjection provoquent un verrouillage exclusif de la version. Tant que ce verrouillage est actif, il empêche les autres utilisateurs de terminer leurs tâches.

Pour en savoir plus sur les paramètres d'enregistrement des données

Pour en savoir plus sur la résolution des conflits de données

Mettre à jour une version enfant

Si vous gérez plusieurs projets, bons de travail ou tâches, vous devez adopter une approche structurée pour la gestion des workflows. Les unités de travail discrètes comprenant plusieurs sessions de mise à jour et s’étalant sur de nombreux jours, semaines ou mois peuvent être gérées sans modifier la version par défaut. Un programme de rénovation d’autoroute, l’installation d’un nouveau service téléphonique ou un projet de maintenance de gazoduc en cours sont des exemples d’unités de travail discrètes.

Si vous utilisez le versionnement traditionnel, lorsqu’un bon de travail ou un projet est lancé, une version est créée comme version enfant de la version par défaut.

Si l’accès à la version par défaut (orange) est défini sur Public, les utilisateurs Editor peuvent directement mettre à jour la version par défaut, ou créer et modifier une version enfant, comme la version A (verte) ou la version B (violette). Les éditeurs peuvent ensuite réconcilier (R) et injecter (P) leurs mises à jour apportées à la version par défaut. Les Viewers qui se connectent à la version par défaut visualisent les mises à jour apportées à la version par défaut ou injectées dans celle-ci.

Un ou plusieurs éditeurs peuvent utilisent cette version jusqu'à la fin de l'ordre de travail ou du projet. Lorsque toutes les modifications d’une version enfant ont été effectuées, un éditeur ou administrateur procède à la réconciliation avec la version par défaut, résolvant ainsi tous les conflits éventuels. Les modifications apportées à la version par défaut sont ensuite injectées, ce qui a pour effet d’intégrer les modifications dans la base de données publiée. A ce stade, la version enfant peut être supprimée.

Les autorisations d’accès des utilisateurs à la version par défaut peuvent être limitées afin d’appliquer ce processus et s’assurer que la version par défaut n’est pas modifiée. L’administrateur peut définir l’autorisation de la version par défaut sur la valeur protected (protégé), afin que les utilisateurs puissent continuer à visualiser la version par défaut mais ne disposent que d’un accès en lecture seule. L’éditeur qui souhaite modifier les données doit créer une nouvelle version enfant.

Si l’accès à la version par défaut (orange) est défini sur Protected (Protégé), les utilisateurs Editor peuvent uniquement mettre à jour une version enfant, comme la version A (verte) ou la version B (violette). Les éditeurs peuvent réconcilier (R) et réinjecter (P) leurs mises à jour dans la version par défaut protégée et les Viewers qui se connectent à la version par défaut voient les mises à jour effectuées ou réinjectées dans la version par défaut.

Lorsque vous utilisez le versionnement traditionnel, l’accès aux versions est déterminé par une combinaison des privilèges de l’utilisateur de la base de données et du niveau d’autorisation d’accès (public, protégé ou privé) défini pour la version.

Éléments à prendre en compte

Tenez compte des avantages et des limitations suivants lorsque vous manipulez ou mettez à jour une version enfant :

• Avantages
  • Simplicité : chaque unité de travail est logiquement répartie par version.
  • Les longues transactions réparties sur plusieurs de sessions de mise à jour et la création d'autres versions de conception sont prises en charge, permettant ainsi aux éditeurs de développer des propositions sans affecter la base de données de production.
  • La création d’une nouvelle version de la version par défaut protège la vue de production de la base de données contre toute modification inopinée. Une fois terminés, les projets individuels sont intégrés à la base de données de production.
  • Les processus de réconciliation/réinjection par lot sont pris en charge.
• Limitations
  • Comme dans toute configuration de version multi-niveaux, le nombre de lignes gérées dans les tables delta de la version affecte les performances de requête de la version. Vous pouvez réduire ce problème en compressant régulièrement la base de données et en actualisant les statistiques SGBD.

Prise en charge des éditeurs et des Viewers

Si votre organisation doit prendre en charge un groupe d’éditeurs ainsi que des utilisateurs accédant au système en lecture seule, les éditeurs utilisent le processus de versionnement traditionnel décrit dans le scénario Modifier une version enfant. Si les utilisateurs disposant d’un accès en lecture seule n’ont pas besoin de visualiser leurs modifications dès leur réinjection dans la version par défaut, vous pouvez mettre à leur disposition une nouvelle version statique protégée, créée à partir de la version par défaut. Cette version doit être créée après la compression de la base de données et la reconstruction des index et des statistiques. Ainsi, toutes les lignes nécessaires à la représentation de la version en lecture seule sont stockées dans la table de base et la base de données fonctionne de manière optimale. Dans ce cas, aucune modification n’est effectuée dans la version de la base de données des utilisateurs en lecture seule ; les requêtes de recherche des différences de versions sont donc inutiles et les statistiques et index de la base de données ne deviennent ni obsolètes ni fragmentés. Après chaque compression planifiée de la base de données, cette version est recréée pour permettre aux utilisateurs en lecture seule d’accéder aux modifications effectuées depuis la dernière compression de base de données.

Une fois que les éditeurs ont injecté les mises à jour dans la version par défaut (orange), une version statique ou en lecture seule protégée peut être créée à partir de la version par défaut. Cette version B en lecture seule (violet) doit être créée après que toutes les modifications de la version enfant A (vert) aient été réconciliées (R) et mises à jour (P) avec la version par défaut, que la base de données ait été compressée et que les index et les statistiques aient été reconstruits. Ce processus garantit que les utilisateurs qui se connectent à cette version B en lecture seule peuvent accéder aux mises à jour apportées depuis la dernière compression de la base de données.

Gestion répartie des données

Il existe plusieurs façons de distribuer des données versionnées au sein de votre organisation afin de faciliter les différents processus.

Réplication de géodatabase

La réplication de géodatabase fonctionne directement avec les géodatabases ou les services de géodonnées et prend en charge les processus de synchronisation. Des outils sont mis à disposition dans ArcGIS Pro pour effectuer une réplication de géodatabase, comme dans ArcGIS Desktop. La plupart de ces processus nécessitent des données versionnées de manière traditionnelle.

Par exemple, dans certains projets, deux ou plusieurs bureaux distants doivent partager les mêmes données. Chaque bureau nécessite un accès local à la base de données et crée donc une copie de cette base de données. Lorsqu’un bureau modifie les données, la modification doit également être appliquée aux données de l’autre bureau. Pour maintenir la synchronisation des copies de bases de données, les bureaux peuvent s’envoyer régulièrement les modifications. Cette fonctionnalité correspond à une réplication de géodatabase.

La réplication facilite également le travail d’un éditeur qui, sinon, devrait peut-être passer par un réseau lent pour mettre à jour les données. Dans ce cas, la réplication permet d’extraire un sous-ensemble de données vers une machine locale afin que l’éditeur puisse travailler avec sans utiliser le réseau. Une fois les mises à jour terminées, elles peuvent être transférées sur le réseau, en les fusionnant à nouveau dans la base de données de production. Pour plus d’informations, reportez-vous à la rubrique Scénarios de données distribuées.

Services d'entités

Les données versionnées traditionnelles peuvent également être publiées sous forme de services d’entités activés pour la synchronisation. Ces services prennent en charge les processus avec les éditeurs mobiles utilisant ArcGIS Collector ou ArcGIS Pro, avec lesquels les éditeurs peuvent télécharger une copie des données, faire des modifications locales et appeler ensuite la synchronisation du service d’entités. Lorsque vous travaillez avec des données versionnées traditionnelles et des éditeurs mobiles, apprenez à utiliser et manipuler des données versionnées traditionnelles dans des services d’entités que vous mettez hors connexion.

Les services d’entité peuvent également participer à des processus de collaboration distribuée. Par exemple, la collaboration distribuée (ou simplement collaboration) prend en charge des services d’entités qui comprennent des couches d’entités fonctionnant sur des données versionnées traditionnelles. Elle permet aux services d’entités activés pour la synchronisation d’être partagées sous forme de copie lorsque les services d’entités partagés dans le cadre de la collaboration fonctionnent sur des copies séparées des données. Pour en savoir plus sur le processus de collaboration et les concepts de la collaboration, reportez-vous à la rubrique Comment fonctionne la collaboration.