Problems adding a new layer into a service that is already part of an app
We have had major problems when we need to update a map service which is already part of an existing app.
Case in point: We needed to add a new layer to a map service.
There are a couple of ways to add this to the layer list of an app:
Method 1. When we use the existing map service (that is now republished with a new layer), and use 'Include layers and map services' in the Layer List tab and try to include the new layer from the map service, it corrupts the entire application and we have to start a new app from scratch. After you try this method and then exit and try to reopen the site, you will get errors on random layers that can only be remedied by removing whatever layer shows the error and re-adding it. Because we have everything in all the layers already configured, feature descriptions, popups, etc, this is not an acceptable option.
Method 2. When we go to Add Map Service and just add the new layer into the app by itself, it seems to work. Unless you try to take it OUT of the app after that, at which point it appears to be removed but we can still see it in the map. It's not in the layer list, not in the app as a service, but still visible in the map. We cannot get it to disappear from the map, and reloading the site does not fix it. Now we have a corrupt app.
WHAT IS THE RECOMMENDED METHOD FOR ADDING A NEW LAYER TO AN EXISTING APP? Again, we do NOT have the option to remove a map service and re-add it to the app, as everything is already configured (and this is hours and hours of work). We should not have to do this in order to add in a new layer to the app.
0
-
A common problem with updating map services after configuring a GCE app to use the service's layers is with layer ID updates. It's possible that you are experiencing this behavior for other reasons, but I suspect from what you describe that this is what you're bumping up against.
If you navigate to an ArcGIS map or feature service layer's REST endpoint and examine the url you'll notice that the layer is accessed with its layer id; the layer id is a part of the url to access the layer and consequently this is how Essentials binds into the layer as well. If you (carefully) crack open a site's xml configuration then you'll find that the configurations, layer by layer, include a "NativeID" property which is where Essentials keeps track of this.
One other thing that you might notice about these layer ids is that they are numbered sequentially through your service. When publishing with default configurations, ArcGIS asigns each layer an id sequentially as it iterates through the publishing .mxd. Fun fact: ArcGIS always does this numbering sequentially. This means that if you've switched the position of two layers in your mxd that they've also switched ids. See the problem? Now guess what happens when you insert a new layer to the top of your .mxd's layer list? Yup... all of your layers now have new ids and new urls to access them... but your Geocortex site (and anything else for that matter) is still trying to apply its configurations to the old ids. This confuses the Geocortex, which activates its defence mechanisms as you've already seen.
TL;DR: what to do. The first thing, which we always caution our clients of, is to make sure that you're happy with your services before you bring them into a web app. This is like trying to settle on a schema before building data management workflows: a more stable low level results in less duplication of work further down the road. Of course, in either case this isn't always doable. To get around this, we configure the data frame in the .mxd to manually assign layer ids on publishing, which makes the id a property of each layer and turns off the auto-numbering. The ESRI article "Map authoring considerations (https://enterprise.arcgis.com/en/server/latest/publish-services/windows/map-authoring-considerations.htm) " has instructions on how to do this.
A less effortful option is to make a point of adding new layers in a service to the bottom, which won't muck up the ids higher on the layer list. If you are using any tables in the service, though, this will still affect their ids which always fall after the spatial layers.0 -
The new layer (in the updated Base service) ArcGIS REST endpoint and the GCX rest endpoint are the same - they are both 110. We have been very careful with this, as we are aware of the issues with the layer IDS.
The current problem is twofold, because we have two apps are currently corrupted and seemingly there is no fix. The Site.XML file shows that the new layer with ID 110 is NOT visible in the layer list and yet...
1. We added the new layer to our development app in the Layer List, and the labels did not show up. We REMOVED the layer from the layer list, yet the layer continues to show up in the map. It cannot be removed from the map, even though you cannot see it in the layer list. This is not good, because now it cannot be turned off and is always visible.
2. We did NOT add the layer to the layer list in the staging app which uses the same updated Base service, but the new layer shows up there even though we did NOT add it to the Layer List in that app. This is REALLY bad, because that app is our backup for production, so if we need to update production for any reason we cannot at this time because it has a layer in it that we are not ready to display in production.
We are going to attempt to republish the Base service again without the new layer and see if that brings us back to an uncorrupted state. If that works, at that point we will figure out a different solution for including this new layer in the app.
Tami0 -
After we removed it from the Base service and republished it, the layer finally disappeared from both apps. We will figure out an alternate solution for including this new layer in our apps. Appreciate the response.... 0 -
Well, if layer ids are stable I can't speak more to your errors without access to your rest manager and possible server... perhaps a support case would help here.
I can, however speak to the behavior of seeing a layer in the map after having removed it from the layer list. The layer list configuration is separate from the layer configuration, thus you can have a layer configured in a service that's visible in the map viewer without it being present in the layer list. This will often happen when configuring a layer in the list and then removing it from the layer list but leaving the layer in the map.
I recommend fully removing unused layers from the app, which you do in the "Map Services" tab of the "Map" page in your REST Manager. If you want to be really sure that you've removed something, look at the services configuration's "Add/Remove Layers" Tab and make sure that the layer in question is excluded.0 -
15 years from now kids wont even realize how nice they have it.....
when they can add and remove layers from a map service, and an apps (any app, not just geocortex) exisiting layer configurations will remain or be instantly nullified based soley on the preserved map service layer id (which I do indeed use yet it is still a 4 hour nightmare to reconfigure an app if I want to change the layer list)
sigh0 -
one trick I have to avoid bricking an app is to remove the entire table of contents and services list first, save the app and close it, then republish your map service with changes, then add the map service and layer list back in to your empty but still working app. At least then that way you dont have to wait 1 minute per layer that is missing or has moved. But you still have to re-configure everything (sometimes copying and pasting from a backup site.xml, and sometimes copying and pasting from an excel sheet containing all text and options from layer configs 0
Please sign in to leave a comment.
Comments
6 comments