Updating a service URL creates a mismatch with AGOL item id

[mwellsesriuk]

If you have a webmap containing an operational layer is tied to an item in ArcGIS Online, the webmap json contains an 'itemid' field for that operational layer. For example:

If you use the tools to update the layer's service URL, the item id effectively becomes mismatched. This means when you view the webmap in ArcGIS Online, the 'item details' hyperlink on the operational layer links through to the wrong item.

Further, you also begin to get strange behaviour in the webmap reflecting the item's properties - for example with editing - I think AGOL may be providing functionality on an operational layer by enumerating its properties via this 'item id'. Therefore if your operational layer links through to the wrong item id, AGOL may be assimilating incorrect item properties through to the web application to provide layer-based capabilities (eg editing).

[ecaldwell]

Good catch. I had not noticed this behavior. What do you think makes the most sense for how to address this? Adding a warning on layers with an itemId? Additionally, should it prompt you to update the itemId? I can't think of any graceful way to do it automatically.

[mwellsesriuk]

Hmm I've had a good think about this. Here are some options; I favour option 3.

1. A warning.
   I don't think this is good enough, because it doesn't allow you to actually fix it. You're basically left with either (a) not using the tool, and not being able to update your URL; or (b) use the tool and end up with a broken web map.

2. A warning plus automatic removal of the itemId.
   This would do as a minimum: layers do not have to have "itemId" properties; if a layer doesnt have an "itemId" then the "properties" hyperlink will link straight through to the REST endpoint. This is workable.

3. Radio buttons - URL or ItemId.
   If you specify the URL, the tool warns (and disassociates any ItemId).
   If you specify the ItemId, the tool goes away and populates the URL automatically from the item properties. This would mean it would not be possible for a user to "break" the association between ItemId and URL. I think this is the most graceful approach.

[ecaldwell]

I like your third option. I may need to try the second option as a stop gap until I've had time to implement the additional steps required for 3.

[phoeffler]

I believe I just experienced this problem - I updated the service URL for a layer and then again for that layer in a web map and the web map was effectively lost, replaced by another web map, probably due to the mismatch mentioned above.
Is it possible to remove the service URL for a layer from the web map so that it is referenced only by the itemId and such that the URL can be updated in each layer and not in each instance of each layer in each web map?
Thanks for any advice on updating service URLs without losing maps and layers.

[ecaldwell]

Thanks for the feedback. I've got an update that I'm putting the finishing touches on that let you edit the JSON directly. I don't think it will prevent the problem you experienced, but may be an alternative approach or at least a way to patch the webmap when it breaks. Stay tuned.

[phoeffler]

That sounds perfect - I look forward to trying it out.
I'll try to keep an eye on github for it.
Thank you!

[ecaldwell]

Editing JSON is now available (#64). It still requires user interaction, so it's not as elegant as Option 3 you provided, but it may be a good stop-gap.

3. Radio buttons - URL or ItemId.
   If you specify the URL, the tool warns (and disassociates any ItemId).
   If you specify the ItemId, the tool goes away and populates the URL automatically from the item properties. This would mean it would not be possible for a user to "break" the association between ItemId and URL. I think this is the most graceful approach.

[phoeffler]

That's great, thanks for making the update. Any thoughts on when it might become available at https://ago-assistant.esri.com/, or if creating a local install might be the most prudent course to get the JSON editing functionality?

[ecaldwell]

It's there now. Clear your cache and reload. It shows up as an icon in the item's JSON.

[mwellsesriuk]

Thanks Evan! We'll take a look.

[amarinelli]

Just came across this now...@ecaldwell, just curious, how come the "Update the URLs of Services in a Web Map" tool only updates url property to point to the new service and does not also update other properties such as title and itemId in the web map JSON? What are the risks of modifying this tool to change everything about the operational layer in the web map JSON to point to the new feature service?

[ecaldwell]

@amarinelli I'm not sure of the implications. Hopefully, most of that info would just flow through and not break anything else in a web map or application built off of the web map. I think the biggest challenge in changing those other properties is how to look them up. Right now, the app just rips and replaces the URL provided by the user. To add itemId and title we'll need to somehow find a service's corresponding item. More complicating is that one service could potentially be registered several times.

I think an approach worth trying first is to try and build out a new UI component that lets the user search for the service to replace it with. Then, we'll have all the other properties we need. If they choose to just do the existing option of pasting a URL directly, then we can remove any extraneous properties (and hope that doesn't break anything else).

What do you think?

[amarinelli]

@ecaldwell, thanks for the details, I now see how just the URL does not give the app enough information to find the correct itemId, among other details. I agree that adding a new UI component would be really useful for searching and providing the full service details that are currently missing. Maybe a simple alternative could be to update the services in the web map by specifying the itemId and the layerId instead of just the url.

[JoelWhitney]

Not sure if there has been any updates on this front, but we have a lot of users running into this scenario when copying items between environments.

Explorer for ArcGIS fails to load layers that have an incorrect itemId after using this tool.

[jgravois]

#191 is relevant

[geompc]

Continuing here from #231 . There might be a problem with removing itemID as it appears to be used for linking to Layers on the Web Map Overview page (highlighted in image below). This was how I first picked up itemID wasn't being changed with a URL update.

I ended up manually editing the JSON to make the itemID update. As @amarinelli suggested there would need to be the option to specify itemID and layerID as some items have multiple layers. This seems more robust than URL replacement.