#ENH-000108149 [Enhancement] Allow the option to refresh or reset a service in a web map

3091
11
08-06-2018 08:54 AM
MVP Frequent Contributor

User Story:
Overwriting a service is a commonly used workflow by users to be able to update their data and see the changes automatically reflected in web maps or apps. However, properties that are also controlled by the web map JSON like symbology do not automatically update. This is not intuitive to users, as they do not understand that their web map is tied to JSON code on the back end. What the user sees is that they made a change to their service and the service is not updating. 

This can be especially confusing if the user adds a layer to an MXD, overwrites their map service, and opens their new web map. The web map JSON points to /MapServer/0, /MapServer/1, etc, but does not display the newly added /MapServer/2. This leads the user to believe the publishing or the web map is broken because their layer did not update. 

There is also an argument to be made for the reverse. When a user updates a service with new symbology or additional layers, existing web maps may not need to be changed. Imagine another user in the company who needed the symbology to be a specific symbol for a specific web map. When the service is overwritten, the web map creator does not want the symbology to change. 

This usability issue has been brought up in numerous enhancements and bugs:
NIM099148
NIM085436
BUG-000092554
BUG-000093880
ENH-000094254
ENH-000080928

Each of these bugs and enhancements have been closed as expected behavior, and that symbology should be set at the web map level. Imagine a company that is adopting a new color scheme, or a new logo, and needs to have all symbology in web maps changed to reflect the new branding. This is a tedious task for users with a large number of web maps. 

To reset the symbology, etc, the current workflow is to remove and re-add the layer to the web map. This is not a feasible solution to some users, as that means pop-up configuration, filters, etc, will be lost. We can direct users to copy the JSON for the layer prior to deleting it and pasting it into a JSON editor like AGO Assistant, but users should not have to modify back-end code to preserve pop-ups. 


Steps to Demonstrate:
    1. Publish any map or feature service from ArcMap or Pro to ArcGIS Online, Portal, or ArcGIS Server
    2. Create a web map and add a the service to it, save the web map
    3. In Pro or ArcMap, open the same source data set and change the symbology. 
    4. Overwrite the service using the Overwrite workflows
        Pro: http://pro.arcgis.com/en/pro-app/help/sharing/overview/overwrite-a-web-layer.htm

        ArcMap: http://server.arcgis.com/en/server/latest/publish-services/windows/overwriting-a-service-in-arcgis-f...

    5. Open the web map created in step 2, the symbology changes made in step 3 are not reflected in the web map

Below is the request for functionality enhancement: 
    6. Open the "More Options" under the layer name in the web map (three blue dots) > choose "Reset Layer" 

ArcGIS Enterprise

11 Comments

And...

option to use layer name instead of layer ID number for services in web maps 

webmaps that do not corrupt with republishing 

Webmaps indeed can use all these concepts in our threads. Symbology doesn't update, popups don't, etc. Even though the unique layer IDs work great on Server now (republishing destroyed a webmap if layers were added pre-10.3), a service still needs to be completely re-added if you add more layers or remove them, change other things in them etc. And there might be intricate popups, symbology, etc you had set in the web map. (it would be nice to back those up somehow in a webmap 'config'; more robust than the Assistant) That is why I try to do as much as will be needed from the service side, and save only a few things for the webmap to set, as they will always get blown out.  (And of course we can't group layers or re-order some types or mix and match sublayers etc) I'm not sure how it would work but in theory, if you add layers to a service, they should just get picked up by the webmap and "just work". If symbology or something else in the service changes; again, it should just 'work', and update automatically.

I have also wired the Layer List to click certain layers open or closed, because of the lack of partial check boxes and ability to turn sublayers on in one click (like AGS JS TOC); while that is a separate issue, it relates to this. Also the Share links where you can embed a parcel address or ID in to the URL and have sites link in to your map viewer, relates. How??  Well, the service and sublayer both get a suffix id in AGOl in the webmap. Let's say, 9233 for the service and 124 for layer 124 in the service.  So YourSite.com/query=YourService_9233_124_ %2CPROP_ADDRESS%2C110%.......   would open to that parcel. Except, because we have to always be blowing out layers because of the issues above. So the service suffix i.e. 9233 always gets changed. Next time it could be 8875.  or something.  So the node I grab which has that ID changes, so I have to update that in the Layer List widget I have hacked do automatically expand sublayers for some of the layers. Also the backend to sites that link in to use would have to change and update their stuff. (sometimes, that is a big ask) So this is an issue for enterprise sites which currently necessitates more work to update when layers change, and more places for things to go wrong. The more stable web maps are and become the better it will be for efficiency and reliability.

Two solutions: One, is make webmaps automatic and resilient, so we don't have to always Re-add the service, but it will pick up the fact there are new sublayers or other things from the MXD/service. Second, I was wondering if perhaps we could elect to keep those 'suffices' static? So it would stay 9233.  So it would remain 9233 and not become 8875 for example.

see Workaround in https://community.esri.com/thread/215875-new-ags-mapservice-layers-not-showing-in-agol-webmap : in AGOL Assistant j can edit the WebMap's JSON.

I have used the assistant. It is often very useful, I recently used it to swap all service links from http to https for example in all web maps. 

However, synchronizing services with web maps should be automatic:  if I add a layer to an MXD or change a layer symbology or other aspects in the MXD and republish, it should be picked up by the web map automatically and immediately.  Second, the Assistant states it is unofficial and not supported. Since web maps can't be backed up (Save As creates new web map, new URL, works as a backstop but is not as ideal as having a true back-up that can instantly be restored with same URL) I am hesitant to use an unofficial product on production services.  

Also, when they update AGOL they could store the config of the layer list either in the web map json or WAB. But, I want the option to have some layer groups/sublayer groups expanded. I use click() now which refers to the node with the 'id' i.e. _3209 appended to each node but that changes each time I have to re-add layers to the webmap because they have this bug with not refreshing to service updates. So, this problem will fix itself when the refreshing bug/design enhancement rolls out, but perhaps this could also be another enhancement and stored via web map json, hence relevant to mention here.  I would really like those layer_id's to remain static, so Share does not break with links.

The TLS issue has elevated this issue now that most of our web app builder apps must be updated/changed to accommodate agol connections.

Some of the applications survived and some are "corrupted" that will probably need to be rebuilt with new services, web map and web appbuilder applications.

Bill, I think many orgs are seeing this as well.  I hope the 4.x milestone AGOL update will address this.  I just ran in to this with a few webmaps. I simply added a layer or two to a service, and then.... they don't appear in the web map. (a known issue)  I have to re-add the data, redo all the popups, and redo all the other settings. It is stressful if it is a production viewer as I need to carefully re-check all of this configuration. 

A more vital issue from this bug...  I realized it completely breaks the Share widget in the WebApp Builder, which is an amazing, amazing feature.  Truly an amazing functionality.  For example this URL zooms to an address https://www.sagis.org/map/?query=SAGIS2018allLayers_9233_124%2CPROP_ADDRESS%2C10%20WESTGATE%20BLVD%2...  Or I could do it by PIN or Name etc etc. But... if I add a layer to my viewer service, which is inevitable... it will change the "id" (9233) of the layer/service in the webmap.  

This prevents integration of Esri viewers with other systems.  Because let's say another agency wants to tie into my viewer. If the ID didn't change, it'd be easy, just give them the URL and tell them to append the PIN or Address or whatever, to the end of the URL. Presto, it zooms the map to a feature based on a query. But.... the second I re-add the service, this will break because the ID 9233 changes to another number. Now all they would have to do is update their URL. But... asking a government agency to repeatedly change something is definitely not feasible.  It just won't get implemented unfortunately, no matter how quick the change, it requires a change which means not feasible.

I suggest this ID remain static and unique not change. Even if we re-add the service, it should know it is the same service and have the same ID or even allow us to update the ID.  I'm sure I could change this in the JSON but I don't want to change something so drastic in webmap raw JSON unless I know it won't have any other ramifications.

Can anyone from Esri comment on this? Kory Kramer  The Share widget allows for amazing integration of Esri viewers with other systems - however, this issue a complete roadblock until we can get the ID to remain static.   Somewhat secondarily, it affects customizing the layer list because the ID gets baked into the DOM as I noted above. Not too bad for me to just update the DOM ID references. But asking other agencies to update production systems like the tax assessor each time I add a layer will not be feasible.

This is still a problem. I update a webmap, I add a layer, it has a new layer Id. It does not show up in the webmap. This is a PITA.  This was necessitated by another common workflow problem; new attributes not captured in Unique Values symbology  

Anyone ever figure out a workaround for this?  When we add new features, then republish...the webmap doesn't update.  Adding/Removing services in the webmap gets old as discussed above due to losing labels, popups, etc configurations.  Any update  would be appreciated!  Using Portal, not AGOL.