Overwrite Web Layers: Auto-fix WebMap Layer IDs

[DenisLalonde]

When using "Sharing->Overwrite Existing Web Layer" from Pro and the new layer happens to have a different Layer ID than the one it's going to overwrite, there NEEDS to be some sort of routine that automatically checks all WebMaps to ensure that none of them will "break" and at the very least give a warning. Ideally, there should be an option in that warning to automatically change the layer's reference in any WebMap that references the old layer's ID to match the new layer's ID.

Yes, I just discovered that layer IDs played an important role and that moving their position in Pro's TOC changes its ID. I publish all my layers individually from a Pro "sandbox" project (contains all my layers) and create/author all my maps in AGOL.

[KoryKramer]

Is this needed if you use the Allow assignment of unique numeric IDs for sharing web layers option described here: https://pro.arcgis.com/en/pro-app/help/sharing/overview/introduction-to-sharing-web-layers.htm#ESRI_...

[DenisLalonde]

Yes, especially given how concealed and unknown the Layer ID option is and the resulting havoc it can cause in existing published webmaps. For someone who only uses Pro to publish and update feature layers (via Overwrite) and only authors maps in AGOL, having to first check the layer's numeric ID in Pro, then check the layer's REST properties in its details in AGOL to make sure the IDs match is not at all user-friendly. Trying to fix the broken WebMaps by jumping into AGO Assistant to edit its JSON isn't exactly ideal or user-friendly either.

I guess that, at the end of the day, I'm probably not using the "Overwrite Web Layers" as it was intended to be used. There needs to be a better way of updating an existing published feature layers from Pro that will not break Webmaps if the IDs happen to not match.

Enhancement ENH-000108149 is on the right track. Maybe rejigging the entire "Overwrite Web Layer" functionality in Pro to "Updated Existing Web Layer" is the way to go.

[DenisLalonde]

...and also, layer IDs occasionally/randomly don't honor the layer ID that I assign to them in Pro. For example, if I know that AGOL layer being overwritten has "20" as layer ID, I force the ID of the source layer in Pro to have an ID of 20...but after the Sharing->Overwrite web layer is completed, the ID of the newly overwritten layer on Pro's end changes to some other random ID resulting in broken Web Map(s). The workaround that I found is to open a new blank Pro project, bring in that single source layer, and publish from there. Perhaps this is more of a bug, but not exactly user-friendly nonetheless.

[Anonymous User]

this is a big issue...  Kory Kramer this is not the same as a layer ID in an MXD or Pro:

If I understand, this is a symptom of the fact the webmap "service ID" changes. In the next-gen AGOL it needs to not change. At least by default. Because it is ServiceID_LayerID that layers get assigned.  And ServiceID changes. Hence the layer ID effectively changes.  This causes a lot of problems.  See my post here: https://community.esri.com/ideas/16701-keep-webmap-service-item-id-static  (if you vote, thank you!)

It is a real issue for production sites, and it unfortunately also prevents an Esri viewer from being integrated effectively in to another system via the WAB Share widget, which is (or would be) one of the best and easiest ways to integrate an Esri viewer.  AGO Assistant is unsupported and needing to edit raw JSON for production sites is a potential source of error. What I suggest for the next-generation AGOL is the Webmap service ID needs to not change, when a service gets updated. New sublayers that are added should show automatically. The webmap should stay in sync with a service automatically, essentially. The way it is now, the JSON gets set in stone and can't change. Will the new MapMaker AGOL 2.0 change this?

[kawakawa4]

Would love to get this issue resolved. Re-doing the symbology and popups of several layers across several maps every time I overwrite the data is a really poor workflow, unless there is way to avoid that?