Keeping consistent layer ids when publishing a service

1518
17
12-18-2023 03:30 PM
Status: Open
Labels (1)
stevegourley
Occasional Contributor II

Layer id values in pro projects are assigned when a layer is added to a project. I don't understand the rules for how the values update when new layers are added, removed, and reordered in the project. But these id's cause issues for publishers who don't understand the importance that they stay consistent. 

When a service is published to arcgis online, the layer is accessed by it's layer id. Depending on how a publisher updates that data, the layer id can change. These change happen without the publisher knowing it caused a breaking change for consumers.

As a consumer, it is akin to whack-a-mole trying to keep up with some publishers as the id seems to change on every publish. Some days, they create a new project, add the data, and overwrite the service creating a 0 index. Other days it seems they create a project with a bunch of data and publish creating a layer id of 4. They publish again and it's 6.

It's very difficult to trust these publishers and ultimately that boils down to the platform and the tools coming up short.

The best place to educate publishers that the id's will change is during the analyze step of publishing. I am aware that some customers do not enjoy the amount of information displayed there now which can lead to it being ignored. But where else could it be displayed? What other hook is available? Are there any optional analyze tools that can be triggered by the responsible people who are interested in this information?

My idea is to create an analyzer that can spot id's changing and allow publishers to read about the subject and assign an id to a layer to avoid the breaking change. It could link to a thoughtful article explaining the nuances of changing id's and yada yada.

If this doesn't fit into the required analyze step, then I propose creating an optional analyze step or a way to enable "advanced" analysis. I think you get the idea.

 

17 Comments
stevegourley

Thank you for clarifying @TanuHoque. There does seem to be a lot of uncertainty around how the id's function.

Let's try to not get distracted with how the id's are created and focus our conversation on how to improve the product to help guide people to make less mistakes that cause breaking changes with ArcGIS Online services.

RandyCasey

@BillFox I do not believe those are being identified here. This has to do specifically with the layer index of map services, which is derived from the map layer index of the layers when a service is published from ArcGIS Pro. If that map layer index is changed at any point after the first publish and the map is published again as a service, the layer indices of those specific REST endpoints get changed as well. This can and will cause issues, as applications, automation scripts, etc., will be pointed to a specific REST endpoint (ex., https://myfictitousdomain.com/arcgis/rest/services/fakeserverfolder/fakeservice/mapserver/3) but because the map index was changed in ArcGIS Pro and was published with the change intact, the REST endpoint has now changed (ex., https://myfictitousdomain.com/arcgis/rest/services/fakeserverfolder/fakeservice/mapserver/8 ), thus breaking the preexisting URL connections causing the domino effect of all applications, scripts, etc., to break as well. This is the specific behavior that this post is trying to call attention to and would like to address.

BillFox

Hi Randy,

just curious, this issue seems to bleed back to at least 2015 here:

https://community.esri.com/t5/arcgis-web-appbuilder-questions/with-portal-for-arcgis-10-3-1-has-anyo...

 

stevegourley

@BillFox This idea is to help fix the root issue and your issues are related to this but downstream. I think if esri can help solve this problem, the issues you highlight start to happen less and less.

RandyCasey

@BillFox Yes and no. The original problem of, if a layer is moved in the TOC of the map after publishing, and is republished with those moves, there is no alert that you have changed the layer indexing, and it no longer matches the service definition has taken a new twist. In ArcGIS Pro 2.5x (I think), ESRI introduced a new feature, where you can now manually assign layer indexes regardless of where it is placed in the TOC (so long as you turn on the functionality). This is great if you want to position your layers wherever you want on the TOC and not have to deal with messing up your service indexes, but where this dovetails, is ArcGIS Pro will assign new indexes whenever new layers or tables are added to the Map. So, if you duplicate a layer, and replace an existing layer with the duplicate, it will have a much higher index number, as it will get assigned the next index in sequence. Repeat this enough times, and you could have all new indexes in your map. Republish that map in that state, and you have now broken every REST endpoint that previously existed for those layers. And still, just like back in 10.3x, there is no alert advising the user that they are about to republish with a non-matching index of the service definition.

stevegourley

When I open the Item Details of the layer in the map, it results in an error, and it's pointing to ...Video_Coverage/MapServer/0
However, when opening the layer from the REST service, the actual ID number is 2 (...Video_Coverage/MapServer/2)

I don't know what happened. An easy fix is to just remove the version on the map, and add it again - that works fine, but then some of the functionality in the app is lost (namely, when you start a video, it no longer zooms to the road).

 Here's another example of someone changing id's without knowing it and breaking an application