POST
|
This BUG-000112935 is designated as fixed in ArcGIS Pro 2.3.
... View more
08-22-2018
01:13 PM
|
0
|
0
|
510
|
POST
|
Problem summary Migrating to service publishing from ArcMap to ArcGIS Pro following federation leads to profound failure when attempting to use ArcGIS Pro to update/overwrite a service published by ArcMap pre-federation. Background I am testing migration to ArcGIS Enterprise with ArcGIS Server federated to Portal, and I've run into a problem related to migration of publishing services from ArcMap pre-federation to ArcGIS Pro post-federation. I'm running ArcGIS 10.5.1 on Windows servers for all components. The test configuration is a single server ArcGIS Enterprise 10.5.1 installation with all the usual components. Prior to federating the ArcGIS Server in this environment I published a number of services from ArcMap and registered them as items in Portal to mimic the production environment and to observe the effects of federation. After federating, as was expected, each service was registered as a new item, effectively duplicating the existing one. Here comes the problem I wanted to explore, post-federation, how service updates were to be handled. If I update a service MXD in ArcMap (10.4.1), say by changing symbology, and then overwrite the service by publishing again from ArcMap, all is well. But, the intent is to migrate to ArcGIS Pro in concert with the new Enterprise configuration. So, I imported the MXD into ArcGIS Pro (2.1.2) and attempted to update and overwrite the service, selecting the Portal item that was registered during federation, and the result was a catastrophic failure. The service was stopped (and not updated), and because it was stopped, the registered items in Portal no longer had a working source. Meanwhile, If I publish from ArcGIS Pro as a NEW service, it works fine, so my MXD import does not seem to be a problem, but publishing a new service is not what I want. So, is this a bug that should be addressed by Esri? The failure is not at all graceful. If this is never meant to be, then what is the prescribed method to migrate from ArcMap publishing to ArcGIS Pro publishing to update existing services that were then federated? Thanks, Marc
... View more
03-13-2018
11:14 AM
|
0
|
2
|
807
|
POST
|
Melanie, This is not the behavior I am observing. The popup for my test layer in Pro is Enabled (that state appears to be the default when adding a layer) and all fields are checked ON to be included. In the Portal map with the shared and registered layer in it, the popup is configured with only a subset of fields checked ON. When I overwrite the Web Layer to Portal I do not see a change to the set of fields checked ON in the layer within the map in Portal, nor do I see a change in the popup itself . As another test, I UNchecked one of the fields in the Pro layer, and again there was no change to the popup for the layer in the Portal map, and the field UNchecked in Pro remained checked ON in the Portal map. Have I done something incorrectly so as not to see the behavior you described? Or, were you just adding to what Tim stated and saying that the popup is completely overwritten only when there is a schema change? Thanks, Marc
... View more
03-05-2018
11:53 AM
|
0
|
3
|
2919
|
IDEA
|
In ArcGIS Pro (2.1.2) when performing an Overwrite Web Layer function, a warning is issued stating, "If you overwrite this web layer, any popups configured or changes made to the web layer after it was initially published will be lost. This may affect existing clients using the layer by changing layer order or available fields." In my first test of this the warning turned out not be true as nothing was apparently lost. I posted an inquiry under ArcGIS Pro regarding this and got the following response from an Esri member, When overwriting a web layer the new layer you are publishing can have an entirely different schema than the existing layer. If the schema differs (i.e. different field names, new fields, deleted fields) than the pop-ups will be lost and need to be re-configured. If the schema is the same, then the pop-ups should maintain. My response to this was, I have to question the wording of the warning as it leaves no room for uncertainty. It says that configurations and changes "will be lost." I think it is alarming and, by your explanation, it is also inaccurate. At the very least, I believe "will" should be changed to "may" and, even better, a concise explanation should be included. I believe that the warning for this function, and perhaps others related to Overwriting, needs to be reviewed for accuracy and content so that users, both experienced and inexperienced, will have the proper information to proceed with confidence in the process and the outcome.
... View more
03-02-2018
10:34 AM
|
4
|
1
|
849
|
IDEA
|
In ArcGIS Pro (2.1.2) when performing an Overwrite Web Layer function, a warning is issued stating, "If you overwrite this web layer, any popups configured or changes made to the web layer after it was initially published will be lost. This may affect existing clients using the layer by changing layer order or available fields." In my first test of this the warning turned out not be true as nothing was apparently lost. I posted an inquiry under ArcGIS Pro regarding this and got the following response from an Esri member, When overwriting a web layer the new layer you are publishing can have an entirely different schema than the existing layer. If the schema differs (i.e. different field names, new fields, deleted fields) than the pop-ups will be lost and need to be re-configured. If the schema is the same, then the pop-ups should maintain. My response to this was, I have to question the wording of the warning as it leaves no room for uncertainty. It says that configurations and changes "will be lost." I think it is alarming and, by your explanation, it is also inaccurate. At the very least, I believe "will" should be changed to "may" and, even better, a concise explanation should be included. I believe that the warning for this function, and perhaps others related to Overwriting, needs to be reviewed for accuracy and content so that users, both experienced and inexperienced, will have the proper information to proceed with confidence in the process and the outcome.
... View more
03-02-2018
10:34 AM
|
4
|
0
|
468
|
POST
|
Thanks, Jake. That's what I sort of expected and it's consistent with what I am used to with publishing services from ArcMap, but I have to question the wording of the warning as it leaves no room for uncertainty. It says that configurations and changes "will be lost." I think it is alarming and, by your explanation, it is also inaccurate. At the very least, I believe "will" should be changed to "may" and, even better, a concise explanation should be included. Thanks.
... View more
03-02-2018
09:15 AM
|
1
|
4
|
2919
|
POST
|
I am doing a lot of testing with ArcGIS Enterprise (v10.5.1), federating ArcGIS Server with Portal, and ArcGIS Pro for publishing. One specific task I have just tested is overwriting a service created by ArcGIS Pro, or to use the latest terminology, overwriting a Web Layer. In ArcGIS Pro (v2.1.2), when I chose Overwrite Web Layer I was presented with a warning reading, "If you overwrite this web layer, any popups configured or changes made to the web layer after it was initially published will be lost. This may affect existing clients using the layer by changing layer order or available fields." I had previously added the Portal map layer item to a map and configured a popup. As it turned out, the popup was not affected following the Overwrite, but I was more than a bit worried. That warning message is very disconcerting. Why is this warning given, and under what circumstances will popups or other configurations be lost? Not knowing when configurations may be lost is not a good place to be. Thanks!
... View more
03-02-2018
08:43 AM
|
2
|
13
|
4669
|
POST
|
Hi Jake, I was not doing any tag searches. This fixed it but I don't see why as I was zoomed well outside the bounds of the data extent. Further, when I zoomed out to the entire world I would expect to see the layers listed even with the box checked since the map area is the entire world, but they still don't appear until I uncheck the box. I've already been working under My Content for these tests. In fact, I am pretty much forced to go to My Content to see my services because selecting Portal for ArcGIS pulls in all the Living Atlas data. Yes, I have disabled bringing in Living Atlas data in the Portal settings but apparently there's a bug where Administrators still see it all anyway. So, even though unchecking the box for 'Within map area' fixed my problem, I still feel something is wrong for the reasons I stated in #2. Thanks, Marc EDIT: I looked further at the behavior of the map area checkbox and the listed data. If I zoom out to the entire world with the box checked, the layers don't show up. But, then if I uncheck the box, the layers show up and I discovered that they stay visible when I check the box again and start zooming back in to the point where I get close enough and they disappear when I toggle the box. So, I see now that the layer list does not actively change with map area so it must be toggled. Comparing the behavior in our production Portal, it has no problem listing the same data published from the same MXD when the box is checked and the map area is the same. I'm back to thinking there is something going on when publishing to this Server federated to Portal. EDIT 2: I registered one of the offending layers from this Enterprise test Portal (10.5) to our production Portal (10.5) using the REST endpoint URL from the Enterprise test Server to test visibility behavior when searching Layers to add to web map. It turns out there are no issues when the 'Within map area' box is checked. It behaves quite properly and Layer shows up in the list right off. I'm definitely thinking there is something going on in the Enterprise system. ONE MORE THING: I discovered on the Enterprise test Portal that I only had to zoom the map out one step for the published layers to appear in the list with the 'Within map area' box checked. All this makes it look like publishing to the Enterprise system changes the extent of the service when it automatically registers it with Portal. Sounds totally crazy, but not out the realm based on other behaviors I've run into over the years.
... View more
04-21-2017
10:06 AM
|
0
|
1
|
1946
|
POST
|
We have assembled for testing a single ArcGIS Enterprise 10.5 server with all three components (Server, Portal, Data Store), and with the Server federated to the Portal. We already have a Portal in production, so we are familiar with it, but we have no experience with federation until this test configuration. Here's a problem I have encountered during testing: feature layers published from ArcMap to the Enterprise Server and automatically registered as items in Portal do not appear in the list of available layers under Search for Layers when attempting to add content to a web map in Portal. If instead of using Search for Layers under the Map Add, I choose Add Layer from Web and provide the REST endpoint URL, it will find the layer and add it to the map. Meanwhile, other items I manually registered from an independent non-federated and unrelated production Server do appear in the list when using Search for Layers under Map Add. Is this a bug, an annoying feature, or did we do something wrong? Thanks much.
... View more
04-21-2017
06:48 AM
|
0
|
3
|
3782
|
POST
|
Would there be a problem with running Web Adaptors of different versions, e.g., 10.3.1 and 10.4, on the same machine? I will have servers (production and testing) running ArcGIS Server at different versions so I want the Web Adaptors running on the web server (no AGS installed) to be at the same version for the server they will connect to.
... View more
05-05-2016
09:13 AM
|
0
|
2
|
1750
|
Title | Kudos | Posted |
---|---|---|
1 | 12-03-2014 07:55 AM | |
4 | 03-02-2018 10:34 AM | |
4 | 03-02-2018 10:34 AM | |
1 | 03-02-2018 09:15 AM | |
2 | 03-02-2018 08:43 AM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|