Architecture Conceptuelle
Event Editor est une application web compagnon pour l'édition de données d'événements référencés linéairement. Cette application JavaScript est alimentée par les services de référencement linéaire publiés via l'extension ArcGIS Pipeline Referencing (APR) Server. Une architecture conceptuelle d'APR est présentée ci-dessous. Le déploiement des composants de la solution nécessite une planification minutieuse, en examinant diverses options d'implémentation.
Considérations de Déploiement
Les récentes versions ArcGIS Pro 3.3 et ArcGIS Enterprise 11.3 d'ArcGIS Pipeline Referencing offrent plusieurs options qui doivent être prises en compte.
- La version ArcGIS Enterprise 11.3 inclut les widgets Experience Builder LRS. C'est l'application web à long terme et tournée vers l'avenir pour l'édition d'événements. Il est recommandé aux clients utilisant ArcGIS Enterprise 11.3 et plus de choisir cette option.
- Event Editor (héritage) est téléchargé depuis My Esri et déployé en tant qu'application web autonome sur un serveur web. La version 11.3 d'Event Editor sera la dernière version de l'application, selon l'avis de dépréciation d'Event Editor.
- La capacité d'édition d'événements LRS a été ajoutée dans ArcGIS Pro 3.0, compatible avec ArcGIS Enterprise 11.0. Les éditeurs peuvent effectuer une édition complète du LRS dans un environnement desktop unique sans quitter ArcGIS Pro.
Une question fréquemment posée est « Ai-je besoin de l'extension APR Server et/ou d'Event Editor ?». Une autre façon de poser la même question est « Est-ce qu'APR pour ArcGIS Pro me fournit toutes les fonctionnalités nécessaires pour l'édition des pipelines ?»
Depuis le lancement initial d'APR (à ArcGIS Pro 1.4) jusqu'à ArcGIS Pro 2.9, la gestion du réseau de routes s'effectuait exclusivement au niveau du bureau Pro tandis que l'édition des événements se faisait dans l'application web Event Editor. Bien que le référencement linéaire avancé pour la gestion des données de pipeline puisse être modélisé et testé dans l'environnement ArcGIS Pro, vous avez besoin du serveur APR pour les déploiements en entreprise avec géodatabase versionnée (version branche) et édition multi-utilisateurs basée sur des services. La boîte à outils Location Referencing dans ArcGIS Pro permet le chargement en masse des événements LRS et la maintenance des événements suite aux modifications des routes.
Suite aux demandes des utilisateurs, les capacités d'édition d'événements LRS ont été ajoutées à ArcGIS Pro. Ceci est particulièrement nécessaire pour les organisations dont les éditeurs effectuent toutes les étapes d'un travail sur pipeline dans un seul flux de travail. Pour eux, une expérience simplifiée consiste à réaliser toutes les étapes dans ArcGIS Pro, plutôt que de devoir effectuer certaines tâches d'édition dans Event Editor. Cependant, l’édition interactive basée sur la carte des événements doit être réalisée en utilisant des services de fonctionnalités avec référencement linéaire. Ainsi, vous avez besoin à la fois de l’extension APR dans ArcGIS Pro, de l’extension APR Server et de l’application web Event Editor pour disposer de capacités complètes à l’échelle de l’entreprise.
Bien que ce soit une excellente nouvelle pour la communauté utilisateur, cela incite à revisiter la question posée précédemment : « Ai-je besoin de l’extension APR Server et/ou d’Event Editor ?».
Vous avez toujours besoin du serveur APR qui alimente les services LRS – l’édition des événements dans ArcGIS Pro utilise le service de fonctionnalités. Comme discuté, les déploiements ArcGIS Enterprise (avec serveur APR) offrent des capacités robustes et complètes tirant parti de la géodatabase versionnée en branches et de l’édition multi-utilisateurs basée sur des services.
L’avantage unique d’Event Editor reste : une application web légère, facile pour les utilisateurs non-GIS, non-utilisateurs LRS. ArcGIS Pro sera trop complexe, peut-être écrasant pour ces utilisateurs – Event Editor fournit juste le bon ensemble d’outils pour éditer et gérer les quelques couches de données qui les intéressent. L’ajout d’ArcGIS Pro et de l’extension APR engendre également des coûts supplémentaires de licence. L’application web Event Editor (une ou plusieurs instances) n’est pas un composant nécessitant une licence et utilise le logiciel existant du serveur APR.
Serveur Fédéré avec Portal
Comme indiqué dans le schéma ci-dessus, un déploiement complet d’ArcGIS Enterprise est requis pour APR. Cela inclut ArcGIS Server avec l’extension APR Server, fédéré avec Portal. Pour clarifier davantage, vous devez disposer d’un site ArcGIS Server licencié pour l’extension APR Server (aucune installation nécessaire). Le serveur APR doit être explicitement fédéré avec Portal ; ArcGIS Online ne supporte pas ce modèle.
ArcGIS Enterprise peut être déployé simplement sur une seule machine. Dans ce cas, Event Editor peut être installé sur cette même machine. Cependant, dans une configuration multi-machines, Event Editor est généralement déployé sur le serveur web aux côtés d’ArcGIS Web Adaptor. Event Editor est enregistré auprès de Portal en tant qu’application cartographique web et un « app ID » est généré. Event Editor hérite désormais du contrôle d’accès utilisateurs et groupes depuis Portal.
Déploiement à Instance Unique
Toute mise en œuvre en production d’APR comprend au moins une instance unique d’Event Editor. Dans ce scénario, le(s) réseau(x) LRS, tous les événements et couches redline sont publiés en tant que services. L’extension APR Server ajoute la capacité de référencement linéaire au service cartographique. La gestion des versions devient disponible lorsque les couches LRS dans la géodatabase sont versionnées en branches. Une carte web doit être créée dans Portal en utilisant le service cartographique référencé linéairement. Cette carte web est ensuite utilisée pour la configuration d’Event Editor(héritage), comme illustré ci-dessous. Event Editor exploite du contenu en ligne tel que les fonds de carte depuis ArcGIS Online. Le service cartographique, la carte web et Event Editor sont sécurisés et partagés avec le groupe d’éditeurs Portal.
Déploiement à Instances Multiples
Dans les grandes implémentations APR qui comptent plusieurs équipes avec divers utilisateurs propriétaires de couches événementielles spécifiques, plusieurs instances d’Event Editor ont été déployées. Event Editor, étant une application web légère, est facile à utiliser pour les non-utilisateurs SIG qui peuvent ne pas connaître les concepts avancés du référencement linéaire. Event Editor limite les modifications au niveau des événements et grâce à l’édition versionnée, il y a peu de risques que les nouveaux utilisateurs commettent des erreurs ayant un impact sur tout le système.
Cependant ces organisations ont une longue liste d’événements LRS à gérer. Dans le cadre de la planification et conception, les événements sont catégorisés en groupes gérés par des équipes métier spécifiques. Par exemple ci-dessous, l’équipe Intégrité possède la couche « Pipeline Risk » et est responsable de mettre à jour les scores de risque sur les segments linéaires selon les paramètres du modèle de risque. Dans ce scénario, la propriété des données est plus distribuée entre équipes métier tandis que l’équipe SIG soutient le contrôle qualité et la publication des modifications dans la géodatabase. Les équipes métier se sentent responsabilisées et contrôlent principalement les couches qu’elles jugent importantes. L’édition des couches événementielles est aussi isolée ; ainsi par exemple, l’équipe Contrats Fonciers ne peut pas modifier un « Segment HCA ».
Opérations | Intégrité | Contrats Fonciers | Dégagement ROW |
Plage Pression Test | Risque Pipeline | Droit de Passage | Gestion Végétation |
Plage Pression Opérationnelle | Segment HCA | Usage Opérationnel Ligne | |
Dans ce modèle de déploiement, la publication des services cartographiques avec capacité Référencement Linéaire est standardisée. Cependant, une carte web différente est créée pour chaque équipe métier avec leurs couches sélectionnées. Par exemple ci-dessous, la carte web X est destinée à l’équipe Intégrité et la carte web Y à celle des Contrats Fonciers. Des copies de l’application web Event Editor sont déployées sur le serveur web en renommant chaque instance du dossier web. Par exemple sous IIS, le chemin par défaut du dossier web sera « C:\inetpub\wwwroot\EventEditorX » et « C:\inetpub\wwwroot\EventEditorY ». À Configuration de Event Editor (héritage), la référence au paramètre de la carte web correspondante est mise à jour dans le fichier config.json. Chaque instance de Event Editor est enregistrée auprès de Portal en utilisant une URL unique et le portalAppId respectif est mis à jour dans le fichier config.json. Le même schéma est suivi pour les instances supplémentaires de Event Editor selon les besoins.
Opérations | Intégrité | Contrats fonciers | Dégagement ROW |
Même - | - LRS - | - Carte - | - Service |
Carte web W | Carte web X | Carte web Y | Carte web Z |
EventEditor W | EventEditor X | EventEditor Y | EventEditor Z |
portalAppId W | portalAppId X | portalAppId Y | portalAppId Z |
Typiquement, Portal aura des groupes pour chacune des équipes métier. Exploitez les groupes Portal et le partage pour accorder le contrôle d'accès au service de carte, à la carte web et à l'application Event Editor aux équipes spécifiques. Seuls les utilisateurs disposant des privilèges suffisants seront autorisés à voir et modifier le contenu de chaque instance d'Event Editor. Une variante de ce schéma est lorsque le service de carte LRS est également individualisé et isolé pour chaque instance d'application. Notez le cas d'utilisation où une couche d'inspection est maintenue par des sous-traitants tiers et doit avoir accès au service et à l'application Event Editor en dehors du pare-feu de l'organisation. Dans ce cas, un service de carte LRS distinct est publié, ajouté à sa propre carte web et référencé via un proxy par une instance d'Event Editor située dans la DMZ.
Une autre bonne pratique recommandée pertinente pour ce modèle de déploiement est que divers éditeurs créent des versions publiques pendant leurs sessions d'édition. Cela permet à l'équipe SIG/aux administrateurs SIG de contrôler la qualité des modifications effectuées par chaque équipe métier et de concilier & publier les versions. Event Editor offre également un contrôle granulaire sur les paramètres de versionnage, qui peuvent être définis avec des valeurs différentes pour chacune des instances d'application selon le niveau de confort des utilisateurs.
Paramètres de versionnage d'Event Editor :
- allowReconcileAndPost : true ou false
- allowChangeVersions : true ou false
- allowCreateVersions : true ou false
- allowDeleteVersions : true ou false
Conclusion
Les considérations de conception et les paramètres de configuration abordés aident davantage à fournir une application web ciblée très définie pour les éditeurs LRS. Les administrateurs SIG et les utilisateurs métier disposent désormais de plus de choix sur la manière de répartir le processus d'édition entre les utilisateurs ainsi qu'entre les applications desktop et web. Nous nous attendons à ce que la communauté des utilisateurs tire pleinement parti des composants de la solution et élabore des flux de travail appropriés selon leurs propres besoins organisationnels.
