Mettre à jour les couches d’entités Web

En règle générale, la mise à jour des couches d’entités Web est identique à la mise à jour d’autres données vectorielles. Les types de mises à jour que vous pouvez effectuer sur une couche d’entités Web sont déterminés par les propriétés du service d’entités. Le mode de mise à jour diffère selon les données en cours de publication, les autorisations des éditeurs et les fonctions activées sur le service. L’une des fonctionnalités qui affectent le mode de mise à jour est la fonction de gestion des versions. Lorsque les éditeurs activent cette fonctionnalité pour la publication de données de branche versionnée, elle modifie la manière dont les éditeurs peuvent mettre à jour la couche Web dans ArcGIS Pro.

Pour en savoir plus, reportez-vous à la rubrique Autorisations des Editors pour les services d’entités et à la rubrique Couches ou fonctionnalités supplémentaires.

Mettre à jour des couches Web sans gestion de versions

Le plus souvent, lorsque vous mettez à jour une couche d’entités Web dans ArcGIS Pro, la fonctionnalité de gestion des versions n’est pas activée. Lorsque des mises à jour sont apportées à ces couches, la plupart des mises à jour effectuées sont stockées localement sur la machine exécutant ArcGIS Pro avant d’être enregistrées. Vous pouvez conserver ou annuler les mises à jour à l’aide des options d’annulation et de rétablissement disponibles dans ArcGIS Pro. Vous pouvez continuer à annuler et rétablir des mises à jour spécifiques jusqu’à enregistrer ou ignorer vos mises à jour.

Remarque :

Les mises à jour et les suppressions, y compris les opérations d’annulation et de rétablissement, sont stockées localement jusqu’à ce que les mises à jour soient enregistrées ou ignorées. Lorsque vous insérez des entités, celles-ci sont immédiatement ajoutées au service d’entités et stockées localement.

Attention :

Vous pouvez publier des données de branche versionnée sans que la fonction de gestion des versions ne soit activée.

Dans ce scénario, la mise à jour s’applique toujours à la version par défaut. La mise à jour se comporte d’une manière similaire à la mise à jour de la version par défaut lorsque la fonction de gestion des versions est activée. Les mises à jour sont enregistrées immédiatement dans la source de données sous-jacente et les fonctions telles que la réconciliation, la publication, le changement de version, l’affichage des différences, la création de version, l’annulation, le rétablissement, l’enregistrement et la suppression ne sont pas disponibles.

Reportez-vous à la rubrique Partager des données de branche versionnée pour plus d’informations.

Enregistrer ou annuler des mises à jour

Lorsque vous enregistrez, toutes les mises à jour et les suppressions que vous avez effectuées depuis le dernier enregistrement sont appliquées aux données source, une par une. Annuler vos mises à jour les supprime de la machine locale. Lorsque des mises à jour sont annulées, les suppressions sont également envoyées au serveur afin d’annuler les insertions effectuées au cours de la session.

Du fait du stockage côté client de plusieurs mises à jour, l’enregistrement ou l’annulation des mises à jour peut prendre du temps. Cela empêche également les utilisateurs du service de voir les modifications et les suppressions tant que les mises à jour ne sont pas enregistrées. Il est recommandé d’enregistrer fréquemment les mises à jour ou d’activer l’option permettant d’enregistrer les mises à jour à intervalles réguliers. Lorsque vous choisissez cette option, vous pouvez configurer l’application de manière à procéder à l’enregistrement selon un intervalle défini ou au bout d’un nombre d’opérations donné. Ce faisant, l’enregistrement automatique dans la source de données intervient régulièrement et accélère la procédure d’enregistrement. Comme pour les autres sources de données, les mises à jour enregistrées ne peuvent pas être annulées.

Les fonctions qui reposent sur un comportement lors de la mise à jour côté serveur peuvent être retardées ou non disponibles dans une session de mise à jour. Voici des exemples de ce type de comportement :

• Il n’est pas possible de naviguer de l’origine à la destination dans une relation créée dans la session de mise à jour.
• Les règles attributaires exclues de l’évaluation côté client n’affichent pas les valeurs calculées.

Si votre processus requiert un accès immédiat à ces comportements ou si vous souhaitez visualiser des mises à jour effectuées par d’autres, il est recommandé d’enregistrer fréquemment les mises à jour ou d’activer l’option permettant d’enregistrer les mises à jour à intervalles réguliers. Pour prévenir tout retard, vous pouvez enregistrer chaque opération. Il peut également être nécessaire d’actualiser la carte pour observer ces comportements côté serveur.

Remarque :

Si une session ArcGIS Pro se ferme de manière inattendue sans enregistrer les mises à jour apportées aux entités insérées, ces entités insérées doivent être examinées manuellement dans une session ultérieure.

Mettre à jour des couches d’entités Web avec gestion de versions

Si le /// a activé la fonctionnalité de gestion de versions lors de la publication de la couche d’entités Web, votre processus de mise à jour diffère du processus de mise à jour s’exécutant lorsque vous mettez à jour des couches d’entités n’ayant pas cette fonctionnalité. La fonctionnalité de gestion de versions n’est disponible que pour les données de branche versionnée.

Lorsque vous mettez à jour une couche d’entités Web avec la fonction de gestion des versions activée, vous mettez à jour la version par défaut ou une version nommée, si une telle version existe. Reportez-vous à la rubrique Se connecter à une version de branche pour savoir comment accéder à une version nommée sur une carte.

Des différences importantes existent entre la mise à jour de la version par défaut et celle d’une version nommée. Lorsque vous mettez à jour la version par défaut, les mises à jour sont immédiatement enregistrées dans la source de données sous-jacente. Pendant la mise à jour d’une version nommée, vous pouvez annuler et rétablir chaque mise à jour et enregistrer ou ignorer des groupes de mises à jour. Ces fonctions qui permettent d’annuler et de rétablir ou d’enregistrer et d’ignorer ne sont pas disponibles lors de la mise à jour de la version par défaut.

Pour fournir ces fonctions de mise à jour dans une version nommée, la version en cours de mise à jour doit être isolée des autres utilisateurs dont le rôle est éditeur. Pour ce faire, ArcGIS Pro utilise 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.

• Lorsqu’un utilisateur de type Editor commence à effectuer une mise à jour d’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 utilisateur doté du rôle éditeur commence la mise à jour d’une version nommée, il doit être le seul utilisateur connecté à cette version.

Définir l’autorisation d’accès à la version sur le mode privé lors de la création d’une version nommée permet d’éviter de telles situations de blocage.

Comportement supplémentaire lors de la mise à jour

À l’instar du comportement décrit ci-avant avec les fonctionnalités de gestion des versions, des comportements de mise à jour supplémentaires sont disponibles en fonction des propriétés de service et de couche. L’utilisation de ces comportements vise à réduire les échecs de mise à jour en raison de limitations liées à la taille des fichiers ou au temps de traitement.

Charger avec une application asynchrone des mises à jour

Deux propriétés déterminent la manière dont les mises à jour sont communiquées au serveur : supportsApplyEditsbyUploadID et supportsAsyncApplyEdits. Si les propriétés supportsApplyEditsbyUploadID et supportsAsyncApplyEdits d’un service sont définies sur true, ArcGIS Pro peut utiliser le chargement et le traitement asynchrone lorsqu’il utilise l’opération applyEdits pour procéder aux mises à jour. Pour déterminer le moment où il convient d’utiliser un chargement et un traitement asynchrone pour applyEdits, l’algorithme décrit ci-après est utilisé.

Pour upload, la taille de la requête est utilisée. La taille requise est déterminée par la taille de la charge utile ainsi que par une estimation de la taille d’encodage d’URL de la requête. Si la taille de la requête dépasse la taille de 6 Mo, upload est utilisé. Le processus de chargement vise à réduire les délais d’attente en empaquetant la charge utile de mise à jour dans un fichier, lui-même chargé avec un ID d’élément unique. L’ID d’élément de la charge utile est ensuite référencé par un appel applyEdits afin d’appliquer les mises à jour du service.

Pour plus d’informations sur le chargement des fichiers, reportez-vous à la rubrique Chargements..

Pour applyEdits en mode asynchrone, un calcul est réalisé afin de déterminer le coût de chaque demande de service applyEdits nécessaire pour effectuer une mise à jour donnée. Ce calcul prend en compte le nombre d’enregistrements à mettre à jour et la taille de la charge utile de la mise à jour. Ces valeurs sont alors utilisées dans la formule ci-après.

1 + (Nombre d’enregistrements / 1 000) + (Taille de la charge utile (Mo) / 6 Mo)

La valeur obtenue est arrondie au nombre entier le plus proche. Si cette valeur arrondie est égale ou supérieure à 3, l’appel applyEdits est effectué en mode asynchrone. Si les valeurs arrondies ne sont pas égales ou supérieures à 3, l’appel applyEdits est effectué en mode synchrone.

Pour plus d’informations sur applyEdits asynchrone, reportez-vous à la section Appliquer les mises à jour.