Scénarios de versions de branche

Disponible avec une licence Standard ou Advanced.

Les exigences métier de votre organisation dictent les scénarios de versionnement de branche que vous utilisez.

Les processus varient, mais 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 métier. Généralement, chaque étape du processus global représente une seule unité de travail telle qu’un bon de travail ou une tâche. Pour gérer ces derniers, vous pouvez créer une version distincte et isolée, et la modifier. Une fois que ce travail a été effectué, vous pouvez intégrer les modifications à la version par défaut.

La connaissance des exigences organisationnelles et commerciales ainsi que les points clés concernant les scénarios de versions de branche vous aideront à déterminer ce qui est le mieux pour votre organisation.

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.

Le versionnement de branche est un type de versionnement de géodatabase qui fonctionne avec le modèle SIG Web de ArcGIS Enterprise en utilisant une architecture basée sur les services pour permettre les processus de mise à jour multi-utilisateurs et les scénarios de transactions longues via des couches d’entités Web. Les couches d’entités Web (également connues sous le nom de services d’entités) sont des couches partagées pour afficher, interroger et mettre à jour des données sur le Web.

Vue d’ensemble du versionnement de branche

Le versionnement de branche prend en charge des classes et des tableaux d’entités simples ainsi que des jeux de données de géodatabase plus complexes tels que les réseaux de distribution et les ateliers parcellaires dans une géodatabase d’entreprise. Il est important de préparer correctement le jeu de données pour qu’il puisse s’adapter aux divers processus accessibles via les couches d’entités Web. Les données doivent être inscrites en tant que branche versionnée et publiées à partir d’une géodatabase d’entreprise. Une fois que les couches d’entités Web sont publiées, le versionnement de branche vous permet de suivre les opérations d’insertion, de mise à jour et de suppression sur les entités d’une version.

Pour obtenir la liste complète des types de données pris en charge par le versionnement de branche, reportez-vous à la rubrique Options de processus de mise à jour.

Si les données sont inscrites en tant que branche versionnée et que vous n’activez pas la fonctionnalité Version Management (Gestion des versions) sur la couche d’entités Web, toutes les opérations, comme l’interrogation et la mise à jour des données, ont lieu sur la version par défaut. Vous ne pouvez utiliser aucune des opérations de Version Management (Gestion des versions), comme la création ou la suppression de versions nommées ou la modification de versions, et aucune opération de réconciliation ou de réinjection.

Pour en savoir plus sur les éléments à prendre en compte lors de la mise à jour des services d’entités.

Les sections ci-après fournissent les considérations générales à prendre en compte pour le versionnement de branche, ainsi que les descriptions de plusieurs scénarios de mise à jour de branche et de configurations de versionnement recommandées.

Considérations générales

Gardez les points suivants à l’esprit lorsque vous envisagez de recourir au versionnement de branche :

• Les éditeurs doivent mettre à jour les données de branche versionnée via la couche d’entités Web ; ils ne peuvent pas se connecter à la géodatabase dans ArcGIS AllSource à l’aide de la connexion à une base de données et mettre à jour les données. Cela signifie que vous devez publier les données de branche versionnée en tant que couche d’entités Web et partager cette couche d’entités Web avec l’audience appropriée (un groupe, l’organisation ou le public). Si vous partagez la couche d’entités Web avec un groupe ou l’organisation, les membres du portail qui doivent mettre à jour la couche d’entités doivent être membres d’un rôle qui inclut le privilège de mise à jour des entités.

  Remarque :

  Le propriétaire des données de branche versionnée peut se connecter à la géodatabase dans ArcGIS AllSource à l’aide de la connexion à une base de données et exécuter des outils de géotraitement qui modifient les données de branche versionnée. Ce cas doit être réservé aux opérations qui facilitent le chargement des données par lots, telles que les opérations Append (Ajouter) ou Copy Features (Copier des entités).

• Lorsque vous mettez à jour des données en branche versionnées, il se peut que la table attributaire ne reflète pas immédiatement les mises à jour. Pour afficher les données mises à jour dans la table attributaire, vous devez actualiser la source de données. Pour ce faire, cliquez sur le bouton Refresh (Actualiser) dans l’onglet Versioning (Versionnement) sur le ruban ou bien, dans la fenêtre Contents (Contenu), sélectionnez List By Data Source (Répertorier par source de données) et cliquez avec le bouton droit de la souris sur la source de données appropriée pour les données en branche versionnées et sélectionnez Refresh (Actualiser).
• Vous devez vous connecter à la couche d’entités Web pour créer des versions nommées. Le propriétaire de la version nommée correspond au membre du portail utilisé pour authentifier la connexion au portail actif lorsque vous créez la version nommée.
• Lorsque vous définissez les autorisations d’accès aux versions, tenez compte de la stratégie des processus de la version ainsi que des besoins des différents utilisateurs de cette structure.
• Les privilèges du membre du portail qui accède à la couche d’entités Web, ainsi que les autorisations d’accès aux versions et les paramètres de la couche d’entités Web, déterminent les opérations réalisables par le membre du portail avec les versions de branche et les données qu’elles contiennent.
• La résolution des conflits pour les données de branche versionnée peut être gérée sur plusieurs sessions de mise à jour. Vous pouvez même fermer le projet ArcGIS AllSource, puis le rouvrir et continuer de gérer les conflits.
• Les processus d’administration des versions de branche sont rationalisés grâce à un modèle de données simplifié. Les opérations de réconciliation et de réinjection sont toujours effectuées pour fusionner les mises à jour et réinjecter les modifications dans la version par défaut, mais l’opération de compression n’est pas nécessaire pour les jeux de données de branche versionnée. Les mises à jour sont suivies grâce à l’archivage, ce qui permet de stocker toutes les mises à jour dans la table de base du jeu de données.

Mettre à jour les données dans la version par défaut

Pour permettre aux autres utilisateurs de mettre à jour les données dans la version par défaut, publiez les données de branche versionnée. La couche d’entités Web référence automatiquement la version par défaut des données.

Lorsque vous mettez à jour les données dans la version par défaut, les mises à jour sont immédiatement enregistrées dans la source de données sous-jacente. La mise à jour de données dans la version par défaut de la branche est équivalente à des transactions courtes standard de base de données. Lorsque vous mettez à jour les données dans la version par défaut de la branche, votre première mise à jour initie la transaction et chaque opération de mise à jour que vous exécutez est automatiquement validée dans la base de données en tant que transaction unique, sans qu’il ne soit nécessaire d’enregistrer les mises à jour. Les modifications que vous apportez sont disponibles pour tous les autres utilisateurs et applications qui accèdent à la couche d’entités Web à partir de la version par défaut lorsque votre transaction est terminée.

Si l’accès à la version par défaut (orange) est défini sur Public (Public), les éditeurs peuvent mettre à jour les données dans la version par défaut, qui est la version publiée. Les utilisateurs dotés du rôle de consultation qui accèdent à cette couche d’entités Web publiée (service d’entités) avec la gestion des versions activée voient également les mises à jour apportées à la version par défaut.

L’accès aux versions est basé sur une combinaison des privilèges de l’utilisateur actif du portail et de l’autorisation d’accès configurée pour la version. Les privilèges des utilisateurs du portail et le niveau d’autorisation d’accès à la version (public ou protected [protégé]) de la version par défaut déterminent les types de processus de mise à jour autorisés.

• Public (Public) : si le niveau d’accès de la version par défaut est défini sur Public (Public), tous les utilisateurs du portail peuvent mettre à jour les données de la version par défaut et les utilisateurs qui mettent à jour les données dans des versions nommées peuvent réinjecter leurs mises à jour dans la version par défaut. Il s’agit du paramètre d’accès par défaut de la version par défaut.
• Protected (Protégé) : si le niveau d’accès de la version par défaut est défini sur Protected (Protégé), seuls les utilisateurs qui sont administrateurs de versions (utilisateurs du portail disposant de privilèges plus élevés) peuvent mettre à jour les données dans la version par défaut ou réinjecter des mises à jour de données de versions nommées dans la version par défaut. Tous les autres éditeurs doivent créer une version nommée pour pouvoir mettre à jour les données.

Éléments à prendre en compte

Tenez compte des points suivants lorsque vous utilisez ou mettez à jour les données dans la version par défaut :

• Plusieurs utilisateurs peuvent mettre à jour simultanément les données dans la version par défaut.
• Si la fonctionnalité Version Management (Gestion des versions) est activée sur la couche d’entités Web, vous ne pouvez pas anuler et rétablir des mises à jour que vous avez effectuées sur les données de la version par défaut.
• Aucune détection de conflit n’est appliquée lors de la mise à jour des données dans la version par défaut. Lorsqu’un utilisateur met à jour une entité et l’enregistre, et qu’un autre utilisateur met à jour la même entité et enregistre les mises à jour, la dernière mise à jour apportée remplace la première.

Mettre à jour une version nommée

Si vous gérez plusieurs projets, bons de travail ou tâches, vous devez adopter une approche structurée pour la gestion des processus. 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. Lorsqu’un bon de travail ou un projet est lancé, vous pouvez créer une version nommée à partir de la version par défaut, pour isoler les mises à jour.

Le versionnement de branche permet de créer un seul niveau de versions nommées à partir de la version de branche par défaut. Pour utiliser des jeux de données de branche versionnée dans une version nommée et les faire participer aux processus de versionnement, procédez comme suit :

• Activez la fonctionnalité Version Management (Gestion des versions) lorsque vous publiez les données de branche versionnée. Une fois qu’il est activé, le service de gestion des versions (VMS) permet de créer, modifier et supprimer des versions nommées, ainsi que de réconcilier et réinjecter les mises à jour des versions nommées dans la version par défaut. Cela est nécessaire pour prendre en charge les couches d’entités Web fonctionnant avec des jeux de données utilisant le versionnement de branche.
• Créez une version nommée pour fournir aux éditeurs leur propre vue unique et isolée leur permettant d’utiliser les mêmes données en même temps, et vous permettre d’identifier et de résoudre les conflits avant de réinjecter les mises à jour dans la version par défaut.

Si l’accès à la version par défaut (orange) est défini sur Public (Public), les éditeurs peuvent mettre à jour les données dans la version par défaut ou créer et modifier une version nommée, telle que la version A (verte) ou la version B (violette). Les éditeurs peuvent ensuite réconcilier (R) et réinjecter (P) leurs mises à jour apportées à la version nommée dans la version par défaut publiée. Les utilisateurs dotés du rôle de consultation qui accèdent à cette couche d’entités Web publiée (service d’entités) avec la gestion des versions activée voient les mises à jour effectuées ou réinjectées dans la version par défaut.

Si vous choisissez une stratégie dans laquelle personne ne met à jour directement la version par défaut, l’administrateur de la géodatabase peut modifier les propriétés de la version par défaut et définir le niveau d’accès à la version sur Protected (Protégé), ce qui permet aux utilisateurs de continuer de voir les données dans la version par défaut, mais limite leur niveau d’accès à la lecture seule. Tout éditeur qui souhaite modifier les données doit créer une version nommée et en mettre à jour les données.

Si l’accès à la version par défaut (orange) est défini sur Protected (Protégé), les éditeurs peuvent uniquement mettre à jour les données d’une version nommée, comme la version A (verte) ou la version B (violette). Les éditeurs peuvent réconcilier (R) leurs mises à jour et les administrateurs de versions peuvent réinjecter (P) les mises à jour apportées à la version par défaut protégée. Les utilisateurs dotés du rôle de consultation qui accèdent à cette couche d’entités Web publiée (service d’entités) avec la gestion des versions activée voient les mises à jour réinjectées dans la version par défaut.

Lorsqu’une couche d’entités Web dont la fonctionnalité Version Management (Gestion des versions) est activée est initialement ajoutée à la carte à partir d’une connexion au portail, elle accède à la version par défaut. Cependant, vous pouvez utiliser la boîte de dialogue Change Version (Changer de version) pour basculer d’une version à l’autre. Lorsque vous mettez à jour une couche d’entités Web avec la fonctionnalité Version Management (Gestion des versions) activée, vous pouvez mettre à jour les données dans la version par défaut ou dans une version nommée, s’il en existe une. Lorsque vous mettez à jour les données dans une version nommée, vous pouvez annuler et rétablir chaque mise à jour et enregistrer ou ignorer des groupes de mises à jour. Pour accéder à ces fonctions de mise à jour dans une version nommée, la version en cours de mise à jour doit être isolée des autres éditeurs et des utilisateurs dotés du rôle de consultation. Pour ce faire, ArcGIS AllSource prévoit des mécanismes de verrouillage visant à limiter l’accès aux versions en mode d’affichage ou de mise à jour.

Le modèle de verrouillage autorise plusieurs Viewers mais un seul Editor sur le principe suivant :

• Lorsqu’un éditeur commence à mettre à jour les données dans une version nommée, un verrouillage exclusif est mis en place et aucun autre utilisateur ne peut se connecter à cette version pendant la session de mise à jour.
• Au moment où un éditeur commence à mettre à jour les données dans une version nommée, il doit être le seul utilisateur connecté à cette version.

Pour éviter une partie de ce verrouillage, définissez l’autorisation d’accès à la version nommée sur Private (Privé). Une version nommée dont l’autorisation d’accès est définie sur Private (Privé) empêche les autres utilisateurs de se connecter à cette version. Les utilisateurs disposant de privilèges élevés (par exemple l’administrateur du portail et l’administrateur des versions) ne sont pas affectés par cette restriction.

Si l’accès à la version par défaut (orange) est défini sur Protected (Protégé), les éditeurs peuvent uniquement mettre à jour les données d’une version nommée, comme la version A (verte) ou la version B (violette). Pour empêcher d’autres utilisateurs de se connecter à leur version nommée, les éditeurs peuvent régler l’accès à leur version nommée sur privé. Les éditeurs peuvent réconcilier (R) leurs mises à jour et les administrateurs de version peuvent réinjecter (P) les mises à jour apportées à la version par défaut protégée. Les utilisateurs dotés du rôle de consultation qui accèdent à cette couche d’entités Web publiée (service d’entités) avec la gestion des versions activée voient les mises à jour réinjectées dans la version par défaut.

Une fois que toutes les modifications apportées au bon de travail, à la tâche ou au projet sont terminées, vous pouvez effectuer une opération de réconciliation pour récupérer les modifications de la version par défaut et résoudre les conflits découverts. Le versionnement de branche permet de gérer les conflits sur plusieurs sessions de mise à jour, d’examiner et de résoudre ces conflits, de vous interrompre et de continuer ultérieurement. Vous pouvez examiner les conflits un par un et, si nécessaire, apporter les modifications nécessaires. Dès que cette opération est terminée, l’administrateur des versions peut réinjecter les modifications de la version de branche nommée dans la version par défaut protégée, en intégrant les mises à jour dans la version par défaut. La version nommée peut alors être supprimée.

Éléments à prendre en compte

Lorsque vous mettez à jour les données dans une version nommée, tenez compte des points suivants :

• Le versionnement de branche permet de créer un seul niveau de versions nommées à partir de la version par défaut. En d’autres termes, vous ne pouvez pas créer de version nommée à partir d’une version nommée.
• Un seul éditeur par version de branche nommée est autorisé ou plusieurs utilisateurs peuvent lire les données de la version nommée. Une fois qu’un éditeur commence à mettre à jour les données dans une version nommée, un verrouillage exclusif est mis en place et aucun autre utilisateur ne peut se connecter à cette version.
• Vous pouvez annuler et rétablir les mises à jour lorsque vous mettez à jour les données dans une version nommée.
• Les opérations de réconciliation et de réinjection sont effectuées en utilisant la version par défaut comme version cible ; vous ne pouvez pas effectuer de réconciliation ou de réinjection dans une autre version nommée.
• Le modèle de versionnement de branche étant un modèle temporel dans lequel tous les enregistrements et mises à jour sont suivis dans la même table de base, il n’est pas nécessaire de procéder à une compression.

Prise en charge des éditeurs et des Viewers

Si votre organisation doit prendre en charge plusieurs niveaux d’utilisateurs, chacun d’eux devant effectuer des opérations différentes, l’approche recommandée consiste à créer une couche d’entités Web par niveau d’utilisateurs. Par exemple, vous pouvez avoir des éditeurs et des utilisateurs dotés d’un rôle de consultation qui ont besoin d’un accès aux données versionnées. Dans ce scénario, vous pouvez prendre en charge ces éditeurs et Viewers en publiant deux couches d’entités Web (services d’entités) de la même classe d’entités sous-jacente inscrites en tant que branche versionnée.

Une fois que les éditeurs réinjectent les mises à jour de la version par défaut (orange) dans la couche d’entités Web modifiable (service d’entités), ces mises à jour sont reflétées dans la classe d’entités sous-jacente inscrite en tant que branche versionnée. Elles sont visibles pour les Viewers qui accèdent à la couche d’entités Web non éditable (vert), car cette couche d’entités Web est également publiée à partir de la même classe d’entités sous-jacente.

• Publiez la première couche d’entités Web comme couche d’entités Web modifiable avec la fonctionnalité Version Management (Gestion des versions) activée. Partagez cette couche d’entités Web avec un groupe dont les membres sont autorisés à mettre à jour les données.

  Une fois que la première couche d’entités Web a été publiée, les éditeurs peuvent mettre à jour les données dans la version par défaut de la branche ou mettre à jour les données dans une version nommée, puis réconcilier et réinjecter leurs mises à jour. Une fois que les mises à jour ont été effectuées et, si nécessaire, réinjectées dans la version par défaut, les modifications sont immédiatement disponibles dans la version par défaut. Ces mises à jour sont disponibles pour la couche d’entités Web que vous publiez pour les utilisateurs en lecture seule ci-après.

• Publiez une deuxième couche d’entités Web avec la fonctionnalité de requête activée et les opérations de création, de mise à jour, de suppression, d’exportation et de synchronisation désactivées. Lorsque vous publiez cette couche d’entités Web pour laquelle la mise à jour n’est pas activée, vous pouvez laisser la fonction Version Management (Gestion des versions) désactivée. Partagez cette couche d’entités Web, pour laquelle les mises à jour ne sont pas activées, avec un groupe dont les membres ne requièrent qu’un affichage en lecture seule des données dans la version par défaut ou partagez-la avec votre organisation pour permettre à l’ensemble de ses membres d’afficher les données en lecture seule dans la version par défaut.

Éléments à prendre en compte

Tenez compte des points suivants lors de la prise en charge des éditeurs et des Viewers :

• La fonctionnalité Version Management (Gestion des versions) étant activée pour la couche d’entités Web modifiable et partagée avec les éditeurs de l’organisation, ces derniers peuvent créer des versions nommées, en supprimer et en modifier les propriétés, mais également mettre à jour les données et effectuer des opérations de réconciliation. Si l’autorisation d’accès à la version par défaut est définie sur Public (Public), les éditeurs peuvent réinjecter les mises à jour des versions nommées dans la version par défaut.
• Pour utiliser des jeux de données de branche versionnée dans une version nommée et les faire participer aux processus de versionnement, vous devez activer la fonctionnalité Version Management (Gestion des versions) lorsque vous publiez la couche d’entités Web. L’utilisateur du portail qui a publié la couche d’entités Web est un administrateur des versions pour cette couche. Le propriétaire de la couche d’entités Web peut partager cette dernière avec le ou les groupes qui comprennent les membres ayant besoin de mettre à jour la couche d’entités Web. Une fois que le partage a été effectué, les éditeurs peuvent créer, modifier et supprimer des versions, effectuer des mises à jour et procéder à des réconciliations et des réinjections.
• Seule la fonctionnalité Query (Requête) étant activée sur la deuxième couche d’entités Web (la gestion des versions ne l’est pas), les membres avec lesquels vous partagez la deuxième couche d’entités Web ne peuvent accéder qu’à la version par défaut.
• L’opération Query (Requête) est requise pour que les Viewers puissent afficher les données dans la couche d’entités Web. C’est pour cette raison que l’opération Query (Requête) est activée lorsque vous effectuez une publication depuis ArcGIS AllSource et qu’elle ne peut pas être désactivée.

Étapes de projet

Dans une organisation, les systèmes de gestion des bons de travail et le processus d’attribution d’un bon de travail passent par plusieurs étapes. Beaucoup de projets se déroulent selon un certain nombre d'étapes prescrites et réglementées nécessitant une phase d'ingénierie, d'administration, ou d'approbation légale avant de passer à l'étape suivante. Ces étapes peuvent comprendre la conception initiale proposée, la construction, l’étude sur le terrain, la construction conforme à l’exécution et l’achèvement du projet. À chaque étape d’un projet, des mises à jour peuvent être effectuées plusieurs fois sur des sous-ensembles de données. Ce processus est essentiellement cyclique : un bon de travail est initialement attribué à un ingénieur et modifié dans le temps au fur et à mesure des étapes du projet, avant intégration complète à la base de données de production. Il se peut que la dernière tâche de chaque étape exige qu’un administrateur se charge de l’assurance qualité (QA) et du contrôle qualité (QC) ou d’une étape de validation avant la réinjection.

Dans le scénario ci-après, une version nommée intitulée Proposed est créée à partir de la version par défaut et représente l’étape de proposition dans ce processus. Une fois que les mises à jour ont été effectuées dans cette étape de proposition, l’utilisateur octroie la propriété de la version à l’administrateur des versions. L’administrateur des versions examine et complète le processus de validation QA/QC, puis réconcilie et réinjecte les modifications dans la version par défaut protégée. Une fois qu’elle a été réinjectée, la version Proposed peut être supprimée.

Un éditeur peut créer une version nommée appelée Proposed (vert) et procéder à une réconciliation (R) de la version nommée Proposed à partir de la version par défaut protégée. Pendant que l’éditeur (vert) met à jour la version nommée Proposed, les Viewers voient ce qui est publié à partir de la version par défaut (orange). Une fois que l’éditeur a terminé la mise à jour et changé la propriété de la version sur l’utilisateur admin (bleu) pour compléter le processus QA/QC, l’utilisateur admin réconcilie (R) et réinjecte (P) les mises à jour en utilisant la version par défaut. Une fois que les mises à jour sont réinjectées dans la version par défaut, les Viewers voient les nouvelles mises à jour lorsqu’ils accèdent à cette couche d’entités Web publiée.

Ensuite, une version nommée intitulée Constructed est créée à partir de la version par défaut pour représenter l’étape de construction de ce traitement. Une fois que les mises à jour ont été effectuées dans cette étape construite, le propriétaire de la version nommée octroie la propriété de la version à l’administrateur des versions. L’administrateur des versions examine et complète le processus QA/QC, puis réconcilie et réinjecte les modifications dans la version par défaut protégée. Une fois que les mises à jour ont été réinjectées dans la version par défaut, la version Constructed peut être supprimée.

Un éditeur peut créer une version nommée appelée Constructed (Construite) (violette) et procéder à une réconciliation (R) de la version par défaut protégée dans sa version nommée Constructed (Construite). Pendant que l’éditeur (violet) met à jour la version nommée Constructed, les Viewers voient ce qui est publié à partir de la version par défaut (orange). Une fois que l’éditeur a terminé ses mises à jour et octroyé la propriété de la version à l’utilisateur admin (bleu) pour compléter le processus QA/QC, l’administrateur des versions (admin) réconcilie (R) et réinjecte (P) les mises à jour en utilisant la version par défaut. Une fois que les mises à jour sont réinjectées dans la version par défaut, les Viewers voient les nouvelles mises à jour lorsqu’ils accèdent à cette couche d’entités Web publiée.

Ce processus de cycle de vie consiste à générer des versions nommées, à effectuer les mises à jour et à octroyer la propriété de la version à l’administrateur des versions, qui complète alors le processus QA/QC et effectue la réconciliation et les réinjections dans les versions par défaut successives jusqu’à l’étape finale.

Éléments à prendre en compte

Vous pouvez utiliser les éléments ci-après avec tous les scénarios décrits ci-avant, mais il sont particulièrement utiles dans ce processus QA/QC.

• Règles attributaires : les règles attributaires améliorent l’expérience de mise à jour et l’intégrité des données des jeux de données des géodatabases. Il s’agit de règles définies par l’utilisateur permettant de renseigner automatiquement des attributs, de restreindre des mises à jour non valides lors d’opérations de mise à jour ou d’effectuer des vérifications d’assurance qualité sur des entités existantes.
• ArcGIS Data Reviewer : Data Reviewer vous permet de gérer les données pour la production et l’analyse des données en fournissant un système d’automatisation et de simplification du contrôle de la qualité des données qui peut améliorer l’intégrité des données. Data Reviewer comprend un ensemble d’outils de contrôle qualité qui permettent un examen efficace et cohérent des données, comme l’analyse des valeurs d’attribut des tables et des relations spatiales entre les entités.
• ArcGIS Workflow Manager : ArcGIS Workflow Manager permet de rationaliser et de normaliser des processus métier, qui peuvent être représentés sous forme de processus utilisant une série d’étapes reliées par des chemins dans ArcGIS Workflow Manager. En organisant et clarifiant les tâches, les processus garantissent qu’aucune étape n’est oubliée. Les informations sont automatiquement enregistrées pour chaque activité et des outils sont fournis pour générer des rapports d’information sur chaque tâche. ArcGIS Workflow Manager comprend des outils permettant d’allouer des ressources et de suivre le statut et l’avancement des tâches. Diverses notifications par courrier électronique sont fournies pour informer les utilisateurs, entre autres activités, des tâches qui leur sont assignées, des tâches réalisées et des données spatiales mises à jour.

Gestion répartie des données

Vous pouvez prendre en charge les processus d’édition mobile dans des applications de collecte de données mobiles ou dans ArcGIS AllSource avec le bouton Download Map (Télécharger la carte).

Pour en savoir plus sur l’implémentation de scénarios de versions de branche pour les éditeurs mobiles, reportez-vous à la rubrique Utilisation de cartes hors connexion et de données faisant partie d’une branche versionnée.

Les couches d’entités Web qui accèdent à des données de branche versionnée sont également prises en charge dans les processus de collaboration distribuée. La collaboration permet de partager des couches d’entités Web pour lesquelles la synchronisation est activée en tant que copies pour accéder à différentes versions 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.