Some Living Atlas Layers in ArcGIS Enterprise Fail to templatize

[shoe913]

When using some layers from the Living Atlas, creating solution item fails in ArcGIS Enterprise.

Repro Steps: 1) Add this layer to a map in ArcGIS Enterprise: https://www.arcgis.com/home/item.html?id=cb1886ff0a9d4156ba4d2fadd7e8a139 2) Using solution.js, attempt to create a solution item from the map -- the process will work 3) Repeat steps 1 and 2 with the following layer: https://www.arcgis.com/home/item.html?id=ed59d3b4a8c44100914458dd722f054f

Issue: The solution item fails to create. Note, both layers work correctly in AGOL.

From errors it appears that we are trying to templatize this specific layer. I suspect the issue is due to how this layer is added, as it is not available via the Living Atlas drop down in ArcGIS Enterprise but needs to be added by searching ArcGIS Online.

[chris-fox]

This is related to #173. We determine if a layer is a living atlas layer by checking the item details to see if the "groupDesignations" property is set to "livingatlas". As you described above the first item exists in the Portal, So when you add it, it has an item id that we can query for in the Portal. The second item isn't on the Portal, so my guess is when you add it to the map it doesn't get an item id property or if it does it can't be resolved on the Portal because it only exists in ArcGIS Online.

[chris-fox]

@jmhauck, I looked into this more and its failing because when we hit one of the living atlas services and get the item id from the service, we query the enterprise portal for that item id and it doesn't exist. I feel like in this scenario rather than failing we could just treat it like a service that we are not going to templatize, if the service is in a different portal we have no way to get that item information and can't create a new item, so just don't templatize it and continue to reference it by its original url.

Attempt to create a solution item from this web map: https://rpubs22001.ags.esri.com/portal/home/webmap/viewer.html?webmap=df54bcad031c4ba2b14d503c5e1154da

creator1/portalaccount1

Do you have any concerns with this approach?

[jmhauck]

@chris-fox so we would never fail on missing or failure to fetch a given item

[chris-fox]

@jmhauck, i think that is the right way to go. Initially I think we didn't want people to think everything packaged properly when it didn't actually include everything, but feel like we run into issues by failing in these scenario.

[chris-fox]

@jmhauck, i tested the scenario in my comment above and its not behaving as expected. In the resulting solution item, the layer with an id of 'World_GHCND_Mly_Clim_Means_1981_2010_5776' is having its url replaced with a variable of {{ed59d3b4a8c44100914458dd722f054f.layer0.url}} and we are adding an itemId property to the layer as well: "itemId": "{{ed59d3b4a8c44100914458dd722f054f.layer0.itemId}}"

I would expect if we can resolve the item id and pull it in as a template that they url property should not be modified and we should not be modifying the itemId property of the layer either.

In addition, the resulting solution item also contains a group with the id of 'ed59d3b4a8c44100914458dd722f054f' (same id as above).

[chris-fox]

Verified