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.
Hi all,
I have a similar view to some here that on analyse it would be very useful to know if the layer ID's have changed sequence. I have a project with a lot of layers and changes frequently, layers added and some taken away before being republished. This has led to problems when using the service in an application like experience builder. The layers go out of sync so in the app you can check a layer on to display but what appears on the map is actually a different layer in the layer list. The only fix is to go back to the project and manually renumber the layer ID's so they are back in numerical order and republish. If this was only 5-6 layers then not much of a problem but I have lots! A warning before republishing would be good and also a way to quickly renumber the layer ID's in the project so they are sequential. So if I made a project and published, then went back later to add 6 more layers in the middle of the list I didnt have to then manually renumber all the layer ID's for there to be no errors in experience builder!
In Pro 3.5, when overwriting a web layer or service, there is new functionality to compare sublayer IDs in your current map and the existing service, allowing you to identify potential changes before publishing.
Great news! Are there any plans to add this as a patch update to older versions?
@stevegourley Unfortunately, it is not possible to provide this new functionality in a patch as it involves significant UI changes. You will have to upgrade to Pro 3.5 when it becomes available.
For more information about this new functionality available in Pro 3.5, see Compare IDs when overwriting web layers.
Is #8 on this list the implementation of this idea? https://community.esri.com/t5/arcgis-ideas-blog/your-ideas-in-arcgis-pro-3-5/bc-p/1621263#M77
Attempting to overwrite a feature layer (copy all data) does not appear to honor assigned relate IDs (ArcPro 3.3 with Enterprise 11.5). All other layers appear to work, except relate IDs. Having multiple relationship IDs with a single fc appear to be assigned randomly and change after each overwrite. Any idea if this is planned to be implemented? Does not quite seem to make any sense, and breaks connections when using multiple related records with any single fc. This appears to be a flaw in the overwrite process.
@DavidOGrady, just to clarify, did you encounter warning 24171 when analyzing? The help topic states that unique relate IDs are not honored when sharing a web feature layer that copies all data.
Thanks @JonahLay Yes, I did receive the warning. A listed 'Solution' was to publish using 11.3, so I've upgraded as I thought this issue may have been rectified in the new version, which doesn't appear to be the case. I realize it is stated that this is expected behavior, but it makes no sense to not honor relate ids, when all other ids are honored. Just curious if you're aware of a fix expected in the future? This prevents me from using multiple related records in an application. In my case, during the overwrite, the relate ids appear to be assigned sequentially for each fc with a single relate (which is predictable and acceptable) , until the system reaches an fc with multiple relates and appears to assign the ids in an unpredictable random sequence, breaking the connection in the web map.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.