Deployment scenarios for Event Editing
Conceptual Architecture
Event Editor is a companion web app for linear referenced event data editing. This JavaScript app is powered by linear referencing services published using ArcGIS Pipeline Referencing (APR) Server extension. A conceptual architecture of APR is shown below. The deployment of the solution components needs some careful planning, reviewing various implementation options.
Deployment Considerations
The recent ArcGIS Pro 3.3 and ArcGIS Enterprise 11.3 releases of ArcGIS Pipeline Referencing offers multiple options that must be taken into consideration.
- ArcGIS Enterprise 11.3 release includes Experience Builder LRS widgets. This is the forward looking, long-term web app for event editing. Customers implementing ArcGIS Enterprise 11.3 and above, are recommended to go with this option.
- Event Editor (legacy) is downloaded from My Esri and deployed as a standalone web app on a web server. The 11.3 version of Event Editor will be the final release of the app, per the Event Editor deprecation notice.
- LRS event editing capability was added at ArcGIS Pro 3.0, compatible with ArcGIS Enterprise 11.0. Editors can perform comprehensive LRS editing in a single desktop environment without leaving ArcGIS Pro.
A question often asked is ‘Do I need APR Server Extension and or the Event Editor?’. Another way to ask the same is ‘Does APR for ArcGIS Pro provide me all the functionality needed for pipeline editing?’
Since the initial launch of APR (at ArcGIS Pro 1.4) through ArcGIS Pro 2.9, the Route Network management has been exclusively at the Pro desktop level while event editing has been in Event Editor web app. While advanced linear referencing for pipeline data management can be modeled and piloted in the ArcGIS Pro environment, you need the APR Server for enterprise deployments with versioned geodatabase (branch version) and services-based, multi-user editing. The Location Referencing toolbox in ArcGIS Pro allows bulk load of LRS events and event maintenance following route edits.
Based on user requests, LRS event editing capabilities were added to ArcGIS Pro. This is specially needed by organizations with editors who perform all aspects of a pipeline job as a single workflow. For them, a streamlined experience is to complete all steps in ArcGIS Pro, versus having to perform certain editing tasks in Event Editor. However, map-based interactive editing of events must be done using feature services with linear referencing. So, you do need APR extension at ArcGIS Pro, APR Server extension and Event Editor web app for comprehensive enterprise-wide capabilities.
While this is great news for the user community, this prompts a revisit of the question asked previously. ‘Do I need APR Server Extension and or the Event Editor?’.
You still need APR Server that powers the LRS services – event editing in ArcGIS Pro uses the feature service. As discussed, ArcGIS Enterprise deployments (with APR Server) offers robust and comprehensive capabilities leveraging branch versioned geodatabase and services-based, multi-user editing.
The USP for Event Editor still remains: a light-weight web app, that’s easy for non-GIS users, non-LRS users. ArcGIS Pro will be too complex, perhaps overwhelming for these users – Event Editor provides just the right set of tools, to edit and manage the few data layers they care about. Adding ArcGIS Pro and APR extension is additional licensing costs as well. Event Editor web app (one or multiple) is not a license bearing component and utilizes the existing APR Server software.
Federated Server with Portal
As in the schematic above, a full deployment of ArcGIS Enterprise is required for APR. This includes ArcGIS Server with APR Server extension, federated with Portal. To further clarify, you must have an ArcGIS Server site licensed for APR Server extension (no install needed). The APR Server must be explicitly federated with Portal; ArcGIS Online does not support this pattern.
ArcGIS Enterprise at its simplest, can be a single machine deployment. In this case, the Event Editor can go on the same machine. However, in a multi-machine site configuration, Event Editor is typically deployed on the web server alongside ArcGIS Web Adaptor. Event Editor is registered with Portal as a web mapping application and an ‘app ID’ is generated. Event Editor now inherits the users and groups access control from Portal.
Single Instance Deployment
Every production implementation of APR has at least a single instance of Event Editor. In this scenario, the LRS Network(s), all the Event(s) and redline layers are published as services. The APR Server extension adds the Linear Referencing capability to the map service. Version management capability becomes available when the LRS layers in the geodatabase are branch versioned. A web map must be created in Portal, using the linear referenced map service. This web map is then used for the Event Editor configuration(legacy), as shown below. Event Editor leverages online content like basemaps from ArcGIS Online. The map service, the web map and the Event Editor is secured and shared with the Portal group of editors.
Multiple Instance Deployment
At larger APR implementations, that have multiple teams with various users owning specific event layers, multiple instances of Event Editor have been deployed. Event Editor, being a light-weight web app, is easy for non-GIS users who may not have awareness of advanced linear referencing concepts. Event Editor restricts edits at the event-level and along with versioned editing, there is little chance of new users making errors that have system-wide impacts.
Such organizations, have a long list of LRS events to manage. As part of the planning and design, the events are categorized into groups that will be managed by specific business teams. As in example below, the Integrity team owns the ‘Pipeline Risk’ layer and is responsible for updating risk scores on line-segments based on risk model parameters. In this scenario, the data ownership is more distributed among business teams, while the GIS team supports the QC and posting of edits to the geodatabase. The business teams feel empowered and control the data layers, they care about most. The editing of the event data layers is also isolated, so in this example, Land Contracts team cannot edit an ‘HCA Segment’.
Operations | Integrity | Land Contracts | ROW Clearing |
Test Pressure Range | Pipeline Risk | Right of Way | Vegetation Management |
Operating Pressure Range | HCA Segment | Line Operational Use |
|
In this deployment pattern, publishing of map services with Linear Referencing capability is standard. However, a different web map is created for each business team with their curated layers. As in the example below, web map X is for Integrity team and web map Y is for Land Contracts team. Copies of the Event Editor web app is deployed on the web server, renaming each web folder instance. For example, in IIS, the default location of the web folder will be ‘C:\inetpub\wwwroot\EventEditorX’ and ‘C:\inetpub\wwwroot\EventEditorY’. At the Event Editor configuration(legacy), reference to the corresponding web map parameter is updated in the config.json file. Each instance of Event Editor is registered with Portal using a unique URL and the respective portalAppId is updated in the config.json file. The same pattern is followed for additional instances of Event Editor as needed.
Operations | Integrity | Land Contracts | ROW Clearing |
Same - | - LRS - | - Map - | - Service |
Web map W | Web map X | Web map Y | Web map Z |
EventEditor W | EventEditor X | EventEditor Y | EventEditor Z |
portalAppId W | portalAppId X | portalAppId Y | portalAppId Z |
Typically, Portal will have groups for each of the business teams. Leverage the Portal groups and sharing to grant access control of the map service, the web map and the Event Editor app to specific teams. Only users with sufficient privileges will be permitted to view and edit the contents of each Event Editor instance. A variation of this pattern is where the LRS map service is also individualized and isolated for each app instance. Note the use case where, an inspection layer is maintained by third part contractors and must have access to the service and Event Editor app outside the organization’s firewall. In this case, a separate LRS map service is published, added to its own web map and using a proxy is referenced by and Event Editor instance sitting in the DMZ.
Another recommended best practice relevant for this deployment pattern, is for various editors to create public versions during their edit sessions. This allows the GIS team/GIS admins to QC the edits performed by each business team and reconcile & post the versions. Event Editor also provides granular control on versioning parameters, and they can be set to different values for each of the app instances depending on the comfort level of users.
Event Editor Versioning parameters:
- allowReconcileAndPost: true or false
- allowChangeVersions: true or false
- allowCreateVersions: true or false
- allowDeleteVersions: true or false
Conclusion
The design considerations and configuration parameters discussed, further helps to provide a very defined, targets web app for LRS editors. GIS administrators and business users now have more choice, on how to divvy up the editing process between users as well as desktop versus web applications. We expect the user community to take full advantage of the solution components and devise appropriate workflows as they deem fit for their own organizational needs.