Mise à jour : ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 a introduit Champs déclencheurs ce qui affecte la discussion sur l'atténuation des impacts de l'édition avec événements.
La gestion des sous-réseaux peut souvent impliquer des centaines voire des milliers de modifications sur des entités lors de la création ou de la reconfiguration d'un sous-réseau. Pour cette raison, le système propose plusieurs modes d'édition différents pouvant être utilisés pour effectuer ces mises à jour. Vous pouvez trouver plus d'informations sur ce sujet dans le sous-réseaux du guide en ligne.
En lisant cet article, vous comprendrez l'impact que ce paramètre a sur la performance de la mise à jour du sous-réseau et pourquoi, pour certains flux de travail, vous pourriez vouloir activer l'événementiel même si cela impacte les performances.
Qu'est-ce qu'un mode d'édition ?
Qu'est-ce qu'un mode d'édition ? Dans ArcGIS Utility Network, le mode d'édition désigne la manière dont le logiciel gère les champs système sur les entités lors de la gestion des sous-réseaux. Il existe actuellement deux options pour les modes d'édition, avec événementiel ou sans événementiel.
À quel “événementiel” faisons-nous référence lorsque nous disons que nous gérons les données avec événementiel ou sans événementiel ? Lorsque nous parlons d'événementiel, nous faisons spécifiquement référence aux événements de géodatabase déclenchés en réponse aux modifications. Les événements de géodatabase sont l'un des moyens par lesquels ArcGIS déclenche des comportements spéciaux lorsque des objets dans une géodatabase sont modifiés. Des exemples courants incluent le remplissage automatique des champs de suivi d'éditeur, le déclenchement de règles d'attribut, la transmission de messages aux objets liés et la mise à jour des annotations liées aux entités.
Quel rapport avec les sous-réseaux ? Un des outils que les utilisateurs exécutent fréquemment dans leur flux de travail d'édition est l’outil mise à jour du sous-réseau. Cet outil est responsable de la gestion des champs système sur les entités du réseau utilitaire qui décrivent le sous-réseau auquel elles appartiennent. À chaque modification de ces entités, différents événements d'édition sont déclenchés. Les modèles de données incluant des relations ou des règles d'attribut déclencheront plus d'événements lors de la mise à jour du sous-réseau que ceux avec moins de relations et règles. Tous ces événements, règles et relations ajoutent du temps supplémentaire au processus de mise à jour du sous-réseau.
Pour gérer cette situation, les administrateurs peuvent configurer les niveaux (tiers) dans leur réseau pour utiliser un mode d'édition qui utilise soit les événements normaux de géodatabase (avec événementiel) soit contourne le modèle normal d'événements de géodatabase (sans événementiel) lors de la gestion des sous-réseaux dans ce niveau. Une brève discussion sur l'évaluation des besoins métier et les meilleures pratiques pour prendre cette décision se trouve à la fin de cet article. De plus, vous pouvez également utiliser les champs déclencheurs pour contrôler précisément quelles modifications font réagir les règles d'attribut afin d'atténuer les impacts des événements d'édition pendant la mise à jour du sous-réseau.
Mais pour l'instant, examinons quelques exemples de configurations différentes. Dans chaque exemple, nous verrons comment un ensemble d'entités réagit dans certaines conditions. Chaque entité est étiquetée avec 4 champs, et lorsqu'une valeur est modifiée, le champ/valeur apparaîtra en gras :
- ID Entité – C'est un identifiant unique pour chaque entité. Il est rempli lors de la création de l'entité.
- Date Modifiée – C'est le champ de suivi éditeur maintenu par la géodatabase.
- Nom du Sous-Réseau – C'est le champ du nom du sous-réseau maintenu par le réseau utilitaire.
- Région Réseau – Ce champ est maintenu par une règle d'attribut qui utilise le nom du sous-réseau pour récupérer une valeur 'région' depuis une table de correspondance.
Remarque : Si aucune règle d'attribut ne nécessite l'utilisation d'informations provenant du sous-réseau, alors toutes les règles peuvent être configurées pour ne pas se déclencher lors des mises à jour effectuées pendant la mise à jour du sous-réseau afin d'atténuer l'impact sur les performances causé par ces règles.
Mise à jour sans événementiel dans default
Le premier exemple que nous allons examiner est quelque chose que chaque projet fait au moins une fois : exécuter la mise à jour du sous-réseau sur la version default dans une base toute neuve. Dans ce cas, tous les champs nom du sous-réseau dans la base ont la valeur ‘Inconnu’ et le reste des champs ont leurs valeurs initiales issues du chargement des données. Vous pouvez voir un exemple dans le graphique ci-dessous.
Figure 1 État initial de la base de données
Après avoir exécuté la mise à jour du sous-réseau sur Network A, on constate que le champ nom du sous-réseau a été mis à jour sur toutes les entités du sous-réseau, mais ni le suivi éditeur ni les règles d'attribut n'ont été déclenchés durant ces mises à jour. Si certaines classes avaient des annotations liées aux entités, celles-ci n'auraient pas été modifiées non plus lors de cet événement.
Figure 2 Mise à jour du sous-réseau dans default sans événementiel
Ensuite, comparons cela avec le comportement du système si nous effectuions la même action mais avec le mode d'édition réglé sur avec événementiel.
Mise à jour avec événementiel dans default
Lorsque le réseau utilitaire est configuré pour mettre à jour un sous-réseau avec événementiel, cela signifie que tous les comportements liés à la géodatabase seront déclenchés lorsque la mise à jour du sous-réseau mettra à jour les attributs d'une entité. Si l'exemple précédent avait été exécuté avec événementiel, les résultats ressembleraient au schéma ci-dessous.
Figure 3 Mise à jour du sous-réseau dans default avec événementiel
Vous pouvez voir qu'en plus de remplir le champ nom du sous-réseau, le champ Dernière Modification a également été mis à jour par le suivi éditeur, et le champ Zone Opérationnelle a été mis à jour par notre règle d'attribut. De plus, si des annotations liées aux entités faisaient référence à un ou plusieurs de ces champs, elles auraient été mises à jour.
Cependant, tous ces déclencheurs et mises à jour supplémentaires ont un coût en termes de performance. Donc, si vous avez beaucoup de règles d'attribut et/ou classes d'annotations liées aux entités, vous devriez réfléchir attentivement à l’impact que cela aura sur votre système.
Mise à jour sans événementiel dans une version nommée
La situation la plus intéressante est d'observer comment se comporte la mise à jour du sous-réseau lorsqu'elle est exécutée dans une version nommée sans événementiel. C’est le comportement par défaut car c’est celui qui offre les meilleures performances.Lorsque la mise à jour du sous-réseau est exécutée dans une version sans événementiel, cela présente l'inconvénient de ne pas pouvoir mettre à jour les informations du sous-réseau sur les entités qui n'ont pas déjà été modifiées dans cette version. Si vous n'aimez pas ce comportement montré dans ces exemples, rappelez-vous que nous avons introduit une nouvelle option pour dépasser ces limitations discutées dans la section suivante (Mise à jour avec événementiel dans une version nommée).
Pour bien aborder ce sujet, nous considérerons deux exemples distincts où exécuter la mise à jour du sous-réseau dans une version peut produire des résultats inattendus. Il convient de noter que même si l’outil peut ne pas produire les résultats attendus dans une version selon certaines conditions, il produira le résultat correct une fois que cette version aura été fusionnée (postée) vers default et que la mise à jour sera exécutée dans default.
Entités nouvellement créées
Notre premier exemple s'appuie sur notre exemple précédent. Supposons que nous ayons une base sans information sur les sous-réseaux remplie et qu'avant d'exécuter la mise à jour du sous-réseau dans default nous décidions de créer une nouvelle version nommée et y ajouter un nouveau service. Voici un graphique montrant nos nouvelles entités créées dans notre version avant exécution :
Figure 4 Nouvelles entités créées dans une version nommée
Après avoir exécuté la mise à jour du sous-réseau sans événementiel dans cette version nommée, vous remarquerez quelque chose d’étrange.Seules les entités créées dans cette version voient leur nom de sous-réseau renseigné.
Figure 5 Mise à jour des nouvelles entités dans une version nommée sans événementiel
Lorsque la mise à jour du sous-réseau s’exécute sans événementiel dans une version nommée, elle ne peut mettre à jour que les entités créées ou modifiées dans cette version. En effet, si l’entité n’a pas encore été modifiée dans cette version, il faudrait déclencher un événement géodatabase pour insérer cette modification dans la version.
Entités existantes
Pour notre prochain exemple, nous examinerons un autre cas pratique où exécuter la mise à jour du sous-réseau sans événementiel dans une version nommée peut produire des résultats inattendus. Nous verrons comment elle réagit lorsqu’une modification entraîne un changement d’appartenance des entités entre deux sous-réseaux.
Nous commençons avec deux sous-réseaux (Network A et Network 
) séparés par un dispositif liaison (interrupteur ouvert, vanne fermée etc.). Tous les sous-réseaux ont été mis à jour dans default donc tous leurs attributs sont correctement renseignés. Notez qu’un dispositif liaison appartenant à plusieurs sous-réseaux voit son champ nom délimité par des points-virgules.
Figure 6 Deux sous-réseaux dans default
Dans cet exemple, nous allons changer le dispositif liaison entre ces deux réseaux passant du dispositif 3 au dispositif 1. Cela arrive fréquemment en pratique lorsque circuits ou zones de pression sont reconfigurés pour s’adapter aux variations saisonnières ou durables de demande client. Pour cela nous changeons le statut ouvert/fermé des deux dispositifs afin que Device 1 devienne dispositif liaison et Device 3 cesse son rôle barrière.
Figure 7 Dispositif liaison mis à jour
Ces changements se reflètent sur le diagramme ci-dessus car l’indicateur dispositif liaison a bougé du Device 3 au Device 1 ; la date dernière modification est actualisée ; et nous avons changé visuellement leur couleur pour indiquer leur appartenance au réseau si on trace chaque réseau séparément. Les noms restent cependant inchangés car nous n’avons pas encore lancé update subnetwork. Ci-dessous un diagramme montre tous les changements attribués qui auront lieu quand update subnetwork sera lancé ici.
Figure 8 Sous-réseau mis à jour en version nommée
Comme prévu on voit que le champ nom du sous-réseau est mis à jour sur les deux dispositifs modifiés dans cette version.Cependant, les entités connectées auparavant au Network A mais maintenant au Network B conservent leurs anciens noms et valeurs zone opérationnelle. Parce qu’elles n’ont pas été modifiées dans cette version update subnetwork ne peut pas modifier ces entités sans déclencher d’événements.
Ces deux exemples illustrent les limites de la mise à jour des sous-réseaux dans des versions nommées sans eventing. Pour de nombreux clients, ces limites sont acceptables en raison des avantages de performance de ce mode d'édition, et parce que les données apparaîtront correctement une fois que les données auront été publiées dans default et que la mise à jour du sous-réseau sera effectuée, permettant à tous de voir les résultats. Cependant, d'autres clients étaient prêts à accepter que la mise à jour du sous-réseau prenne plus de temps afin de répondre à certaines exigences métier. C'est pourquoi nous avons introduit la possibilité de mettre à jour le sous-réseau en mode édition avec eventing comme nous le verrons dans la section suivante.
Mise à jour avec eventing dans une version nommée
Reconsidérons les deux scénarios ci-dessus mais examinons comment ils se comportent lors de la mise à jour du sous-réseau dans une version nommée lorsque le niveau est configuré pour avoir un mode d'édition avec eventing.
Nouvelles entités créées
Ci-dessous, nous pouvons voir le premier exemple, où il y a un mélange d'entités existantes et nouvelles qui doivent être mises à jour.
Figure 9 Nouvelles entités dans une version
Et voici le résultat après l'exécution de la mise à jour du sous-réseau avec eventing.
Figure 10 Mise à jour du sous-réseau avec eventing dans une version nommée
Comme vous pouvez le voir, toutes les entités ont le nom correct du sous-réseau et la zone d'exploitation correcte. Le réseau prendra plus de temps à traiter car il édite plus d'entités et parce que chaque entité déclenchera des modifications supplémentaires pour gérer le suivi des éditeurs, les règles d'attributs, etc.
Entités existantes
Ensuite, examinons le deuxième exemple où nous avons reconfiguré plusieurs sous-réseaux. Ci-dessous se trouvent les données avant l'exécution de la mise à jour du sous-réseau.
Figure 11 Entités dans une version avant la mise à jour du sous-réseau
Et ci-dessous l'état des entités après l'exécution de la mise à jour du sous-réseau dans une version nommée avec eventing.
Figure 12 Nouvelles entités dans une version
Encore une fois, vous pouvez voir que tous les attributs sur l'entité ont les valeurs correctes. Il convient de préciser que cela prendra plus de temps que d'effectuer la même opération sans eventing. Cependant, le temps nécessaire sera directement lié au nombre/complexité des règles d'attributs que vous avez configurées sur vos entités ainsi qu'au nombre de relations avec messagerie activée (y compris l'annotation liée aux entités). Il est important de mesurer et de considérer ces coûts de performance avec l'importance de l'inspection visuelle/la révision des attributs des informations réseau lors de votre processus d'assurance qualité.
Configuration
Maintenant que vous avez vu comment ces comportements fonctionnent, examinons comment ils sont configurés dans un utility network. Ces options sont configurées en utilisant l'outil Set Subnetwork Definition. Comme cet outil vous permet de modifier la configuration pour un niveau spécifique dans votre réseau, cela signifie que vous pouvez définir différents comportements pour chaque niveau (par exemple System et Pressure). Bien qu'il soit agréable d'avoir l'option d'avoir différents comportements pour chaque niveau, la plupart des clients préfèrent que tous leurs niveaux se comportent de la même manière afin d'assurer des flux de travail d'édition cohérents pour les éditeurs.
Lors de la définition du mode d'édition pour votre définition de sous-réseau, il y a deux champs différents, chacun avec deux options différentes. Cela signifie qu'il y a quatre combinaisons de valeurs que vous pouvez configurer pour vos modes d'édition :
- Sans eventing dans default, sans eventing dans les versions nommées (par défaut)
- Sans eventing dans default, avec eventing dans les versions nommées
- Avec eventing dans default, avec eventing dans les versions nommées
- Avec eventing dans default, sans eventing dans les versions nommées
Avant de passer trop de temps à vous inquiéter du choix parmi ces quatre options, sachez que les modèles de données fondamentaux utility network fournis par Esri ont déjà leurs modes d'édition configurés. Chacun de ces modèles de données dispose d'un ensemble recommandé de configurations développées par des experts sectoriels en collaboration avec leur communauté afin d'avoir une configuration qui conviendra au plus grand nombre possible de flux de travail pour ce secteur.
Même si ces configurations répondent aux besoins de la plupart des clients, il est toujours conseillé d'examiner ces configurations dans le contexte de vos exigences métier et des modifications apportées au modèle/configuration des données afin de garantir que la configuration typique reste la plus appropriée.
Bonnes pratiques
La question la plus fréquente que je reçois est : quelle est la meilleure pratique pour configurer votre mode d'édition dans utility network ? Il n'y a pas une seule réponse qui convienne à tous les clients. Cependant, plusieurs critères peuvent vous aider à décider quelle option est la plus appropriée pour vous. Ces considérations tombent généralement dans trois catégories différentes : flux de travail, annotation et règles d'attributs.
La première considération est votre flux d'édition versionné. Si votre flux d'édition nécessite que vous effectuiez une assurance qualité dans des versions nommées, et que ce processus inclut l'utilisation d'outils ou couches qui dépendent des attributs stockés sur les entités (nom du sous-réseau, valeurs propagées, etc.), alors vous voudrez définir votre mode d'édition pour les versions nommées sur « Avec Eventing ». Cela garantit que les champs du sous-réseau sont toujours correctement remplis pour toutes les entités dans votre version afin qu'ils puissent être utilisés pour l'assurance qualité. Si votre processus QA peut être effectué entièrement dans default, ou si votre processus QA peut utiliser le traçage au lieu de dépendre des attributs des entités, alors vous pouvez définir votre mode d'édition pour les versions nommées sur « Sans Eventing ».
La deuxième considération est si vous avez de l’annotation liée aux entités. Si vous n'avez pas d’annotation liée aux entités ou d'expressions d'annotation qui n'incluent pas d'informations provenant du sous-réseau (nom du sous-réseau, valeurs propagées, etc.), alors n'importe quelle option de mode d'édition vous convient. Les classes relationnelles avec messagerie activée, comme les classes d’annotation liée aux entités, ont un coût en performance associé à l'édition qu'il faudra surveiller attentivement. Cependant, plus important encore : si votre annotation liée aux entités inclut des informations sur le sous-réseau, vous devez prendre certaines décisions. Stocker des informations sur le sous-réseau dans des classes d’annotation n'est pas considéré comme une bonne pratique en raison du caractère statique de l’annotation, du caractère dynamique des sous-réseaux et du coût en performance pour maintenir les deux synchronisés. Vous devriez envisager de remplacer ces annotations liées aux entités par des étiquettes. Toutefois, si c'est une exigence stricte, alors vous devrez définir votre mode d'édition sur « Avec Eventing » tant pour les versions nommées que pour default afin que le texte dans votre annotation soit mis à jour lors de l'exécution de update subnetwork mais soyez conscient que cela impactera la performance de update subnetwork.
La troisième chose à considérer est les règles d'attributs que vous avez définies sur vos entités utility network. Toute règle d'attribut configurée pour se déclencher lors d'une mise à jour sera évaluée chaque fois que cette entité est mise à jour, quel que soit le champ auquel elle est assignée. Cela signifie que si vous utilisez le mode édition avec eventing, toutes les règles immédiates seront déclenchées lors de update subnetwork sur toutes les entités mises à jour. Si c'est une exigence stricte et que vous êtes prêt à accepter le coût en performance, vous devriez revoir vos règles d'attributs pour s'assurer qu'elles sont écrites avec une logique de sortie anticipée pendant update subnetwork afin de minimiser ce coût en performance. Si vous avez des règles d'attribut qui dépendent des changements aux champs du sous-réseau, sachez que ce n'est pas considéré comme une bonne pratique. Cependant, si c'est une exigence stricte alors vous devez définir votre mode édition sur « Avec Eventing » afin que la règle soit déclenchée lors update subnetwork.
Avec ces considérations en tête, passons en revue les quatre options et voyons où elles sont les plus appropriées.
Sans eventing dans default et sans eventing dans les versions nommées. Cette option est le comportement par défaut du système. Elle offre la meilleure performance mais présente des limites concernant la mise à jour des entités dans les versions et l’annotation liée aux entités.
Sans eventing dans default et avec eventing dans les versions nommées. Cette option trouve un équilibre entre performance et fonctionnalité. Elle offre la meilleure performance lors de la mise à jour du sous-réseau dans default et la meilleure expérience assurance qualité dans une version nommée.
Avec eventing dans default et avec eventing dans les versions nommées. Cette option offre le plus haut niveau fonctionnel mais aussi le coût en performance le plus élevé. Si vous implémentez cette configuration, vous devriez revoir toutes règles d'attribut configurées pour s'exécuter lors modification des entités afin qu'elles soient configurées avec une sortie anticipée pendant update subnetwork.
Avec eventing dans default et sans eventing dans les versions nommées. C'est la configuration la moins courante. Elle s'adresse aux clients qui ont besoin que leurs annotations ou règles d'attribut s'exécutent dans default mais pas dans les versions.
Conclusion
Maintenant que vous avez lu cet article, vous devriez comprendre les avantages/inconvénients des différents modes édition utilisés pour la gestion des sous-réseaux et être capable de déterminer quels modes conviennent à votre modèle de données, vos flux éditoriaux et vos exigences métier.
Si vous souhaitez apprendre comment atténuer l’impact sur la performance des événements éditoriaux sur les règles d’attributs, lisez l'article Attribute Rule Triggering Fields.
Si vous voulez en savoir plus sur la gestion des sous-réseaux ou essayer quelques tutoriels pratiques, vous pouvez trouver des exemples spécifiques par industrie sur la série pédagogique Getting Started with ArcGIS Utility Network.
Si vous souhaitez obtenir plus détails et approfondissements sur les capacités gestionnaires des sous-réseaux du utility network, je recommande vivement certains autres articles techniques disponibles sur la page communautaire ArcGIS Utility Network. Esri
