Event Editor Version Structure/Workflows

[ColinSchut]

I am starting to explore the idea of setting up Event Editors for specific asset program units to edit their program data without my involvement, and want to use versions to do so. I am curious how other people do this, whether or not this structure makes sense or not and how to manage users and versions in event editors. Such as, versions for individual users or event editors, level of protection of versions, etc.

Two specific questions are:

-Since the version user is the service publisher, all versions are visible to all users. Does it make sense to have a version per user, or a single version for event edits?

- The point referent dataset needs to be published in the service to allow creating events by referent points (a mandatory requirement for me), but I don't want it editable by the users. Is there a way to do this?

It seems that making Default protected may be the way to go, but I'm reluctant to do so immediately without fully understanding all the implications of doing so. I have also not worked with versions in a production environment before.

Any feedback is welcome, thanks.

[KyleGonterwitz]

Good idea.  To do this you will want to track edit changes and ensure your portal group security is working with the change tracking, and yes protect your default and manage LRS Locks in event editor with a lockroot subversion from default and conflict prevention enabled in the ALRS Settings.  I would configure event editor applicatons, secured and delivered to members assigned to portal groups, and customize the cartographic content to facilitate the workflow to the maximum extent possible.  Also configure the event editor with full ability of the editor to create a version, post and reconcile, manage locks, and delete a version all with event editor buttons.  What I do is publish the services with a shared user that is only used for publishing services, not a data owner user or an active directory user but a named user in the database with privileges set for editing event data in versions.  I think in a multi-user environment you would definitely want to have at least a version per user, sometimes more depending on the situation and the number of EE configurations you set up.  It is possible to configure event editor using portal maps that can combine read-only services with the ALRS service, but snapping in the Event Editor might not work on those non-alrs services.  You can also probably add read-only connections when publishing the service to enable the reference layers to support snapping, maybe.  

For our installation it was difficult to get the federated portal all set exactly how it had to be for ADFS users and conflict prevention to work but now that we have that figured out I wouldn't want to do it any other way, and it appears this approach is going to work well to achieve your goal, and mine too, of supporting program areas in such a way that they can utilize the event editor and spread the workload horizontally into the agency.

[AmitHazra · Accepted solution]

Hi Colin

Congratulations! It sounds like your Roads and Highways implementation is really starting to mature and now you’re bringing multiple stakeholders and business units into the system. That’s awesome and exactly what the software was designed to handle but with this “power” comes a little bit of extra configuration...

There are several important issues to consider once you begin to build out your Roads and Highways solution to a more enterprise scale like you are describing (multiple Event Editor configurations for specific asset program units). The primary concern you'll want to consider is data integrity when multiple users are editing LRS networks and/or events in a versioned geodatabase. In order to avoid versioning conflicts and/or measure discrepancies on routes and events you’ll want to enable the Roads and Highways Conflict Prevention capability. This will allow your users to interactively “lock” routes and events to prevent any route and/or measure-based discrepancies as a result of geodatabase versioning.

Once you’ve enabled Conflict Prevention I suggest you have versions specific to the users who are making edits in the system. We tend to call these types of configurations “workgroup implementations” where Roads and Highways Event Editor configurations are specific to a user rather than a business unit workflow and/or role. If you’re really interested in these implementation patterns you can reference a UC tech workshop we did a few years ago.

From a configuration standpoint and assuming you’re using Conflict Prevention, you’ll want to:

• Create a portal group for each asset program and add the appropriate users to each of those groups. As you publish federated services, create web maps and apps, share each configuration item with only the groups that need access to those specific items. Portal sharing model.
• For each user, create an Event Editor geodatabase version that is a child of the Lock Root version.
• Publish your LRS-enabled services either to your Default or Lock Root version.
• Create a specific configuration of Event Editor for each user or asset program unit (e.g., myAssetProgram.json).
• For each Event Editor configuration, you’ll want to create a default web map with the LRS-enabled service and any reference layers that group needs. Here's where the Referent Points comes into play. Publish a separate map service for this layer that is not LRS-enabled and optionally, using an underlying DB user connection with Event Viewer privileges. When you configure your Event Editor webmap, add that item to your web map along with the LRS web service. Your asset program units will be able to see the referent locations but will not be able to edit them. Share each configuration of each webmap to the appropriate group.
• For each Event Editor configuration, disable the allowChangeVersions, allowCreateVersions, allowDeleteVersions versioning properties. By allowing only the allowReconcileAndPost option, they’ll still be able to release conflict prevention locks.
• In portal, create/register/share specific versions of the Event Editor for each asset program using URL parameters. Example: https://myAwesomeRHSite.esri.com/EventEditor/?config=myAssetProgram.json.
• For each user, create a browser bookmark/URL favorite to their respective Event Editor configuration and version using URL parameters. Example: https://myAwesomeRHSite.esri.com/EventEditor/?config=myAssetProgram.json&version=LRS.ColinS.

Have a look at our Smart launching in the Event Editor through URL parameters resource doc if you need more information on this type of configuration.

As to your second question about whether to protect the Default version, if you are using Conflict Prevention and the Default version is your Roads and Highways version then it must be Public so Event Editor users can Reconcile/Post edits to release event locks. If you are using a surrogate to Default to represent your Lock Root version than yes you could absolutely Protect Default and simply let users rec/post to Lock Root.

Hope this gives you a good reference point for expanding your R&H solution. Should you need further assistance please give us a call!

-amit@esri

Esri LRS Transportation Team

[RyanKoschatzky]

Colin,

NCDOT has 8 different business units using R&H. One business unit is responsible for the LRS and a few events. The rest only maintain their specific events. A data governance plan can help flush these details. Each business unit has their own wmx workflow jobs tailored to their business unit needs and permissions are controlled by their AD group (permissions is handled outside my group so I could be all off on the details). The same with Data Reviewer checks. While the jobs and DR checks have some common elements we allow each to be different because not all events are the same and not all business unit work the same. We have some with only one editor or up to 7 editors. A lot depends on how GIS experienced the business unit is and we have wide range of users. Most wmx jobs are based on a unit of work (need to fix some values, transportation project is completed, QC of legacy data, etc ) and can be open for one day or for the whole quarter. We go to state zero (no versions) 4 times a year as part of our publication and maintenance plan.

Here is an example of the wmx jobs we have created for our LRS editors.

Other business units only have one or two different jobs. One to edit and one for QC work.

We use Default and Lock Root. Lock Root being Public and Default is Protected. We have a nightly script to post Lock Root to Default. We also have an edit and publication databases. Event owners have access to their data on edit and all other data comes from the publication stack as read only is my understanding. We use Conflict Prevention   

We can talk offline and to discuss the finer details if need be. Hope this helps.

[ColinSchut]

This is an excellent and comprehensive answer, thank you Amit. The URL parameters in particular avoid the majority of headaches I was imagining and I already have Portal groups set up to allow this workflow. 

We've always had conflict prevention enabled but our lock root version is sde.default. Are there any specific reasons to use a surrogate other than an additional layer of protection for default? For our small group I'm not certain the extra version is necessary and I'd like to keep the administrative overhead to a minimum. 

Thanks for the answers everyone, this was extraordinarily helpful. Initial tests have gone very smoothly.

[AmitHazra]

Hi Colin - Whether you use default or a surrogate for your Conflict Prevention Lockroot version the choice is mainly based on your geodatabase operational governance model. This topic is discussed here: Enabling conflict prevention in the LRS—ArcMap | Documentation 

I will mention that once an organization is ready to make the transition to Roads and Highways for ArcGIS Pro the geodatabase versioning strategy become less ambiguous. Roads and Highways Pro relies on a completely service oriented editing paradigm and will require the enterprise geodatabase to leverage Branch versioning. Branch versioning has a simplified version hierarchy allowing only one level of named versions to be created from the default version. Therefore, if Conflict Prevention is enabled the Lockroot version must be default. You can read more information regarding how to prepare your data for editing in Roads and Highways Pro by reviewing this resource document: Share as web layers—ArcGIS Pro | Documentation 

Keep up the good work!

-amit@esri

Esri LRS Transportation Team

[ColinSchut]

"Here's where the Referent Points comes into play. Publish a separate map service for this layer that is not LRS-enabled and optionally, using an underlying DB user connection with Event Viewer privileges. When you configure your Event Editor webmap, add that item to your web map along with the LRS web service."

Is the only issue I'm having. This allows you to bring the points into the map, but not to use them as a referencing method. 

Otherwise this is exactly the workflow I'll be using. 

[AmitHazra]

Hi Colin - for the purposes of characterizing new point or line events using referent offset location methods the referent point feature layer must be in the same map service as route/network layer.

-amit