Select to view content in your preferred language

Overwrite Map Service by Copy to Referenced Registered Folder

3087
10
11-25-2020 02:52 PM
KrystalPhaneuf2
Regular Contributor

We have published a service mistakenly with the data copied to the server rather than by reference.  We moved the data to a registered folder on the server and tried to overwrite.  However, it continues to fail with an error 001369 Failed to Create the Service and Failed to execute (Publish Service Definition).  We are able to publish a new service as registered to the referenced folder.  Is there any reason why the overwrite should fail when going from non referenced/copied data to referenced data?

ArcGIS Enterprise 10.8.1

Publishing from Pro 2.6.2

MicrosoftTeams-image (7).png

0 Kudos
10 Replies
by Anonymous User
Not applicable

Hi Krystal,

When you publish a service to ArcGIS server, its service workspace is defined somewhere in the configuration store. Once the service has been published, there is no way to change this either through the interface or programmatically. I would suspect that simply trying to overwrite the service definition to point to a new service workspace would fail, as not just the features but also the service definition and manifest would need to be changed.

As you have already discovered, I would encourage you to publish a new service using the desired service workspace, and then update your service URLs to reflect the new service.

-Calvin

KrystalPhaneuf2
Regular Contributor

Thank you for the response Calvin.  Is this error expected because it was originally published as a copy and not by reference?  We are planning to test publishing from a referenced folder, then changing the source to SDE and overwriting.  I am expecting this should work. Am I wrong?

0 Kudos
DanielMcCullock2
Occasional Contributor

Hi Krystal,

We have been having issues using the overwrite tool in general.

A method we have used to overcome this is the rename function via the server admin endpoint.

We re-publish the service using the same name with an "_new" at the end, such as "service_new". After testing the service to make sure it is functioning as we would like, we then rename the old service to have an "_old" and then remove the "_new" from the new service. After this we change the portal item IDs of the new service to match the old, remove the old service, then remove any new portal items that were generated in the process.

This means we only have a small outage on the service and are able to maintain the service name and portal item IDs.

Alternatively (I have not tried this for republishing but may be worth investigating), a service can be manipulated by retrieving the MSD file on the server, extracting (I use the 7zip software), manipulating the xml files which are extracted, then compressing again (using zip format and naming as a .MSD), replacing the .MSD on the server and restarting the service. We have managed to add in datum transformation information to the map.xml. There is xml files there specifically for the data.

Good luck and all the best

Danny

JohnGalambos
Occasional Contributor

Thanks Daniel, this approach is working well for us and this post helped me work up the courage to try it. I just wanted to add that this is working well for everything I've tried it on (map services and locators) with the exception of  composite locators with copied data. There appears to be an issue when renaming composite locators such that the service won't start afterwards. There are some absolute paths in the underlying service's .loc file that don't get updated after the rename. I've filed an issue with ESRI Canada.

DanielMcCullock2
Occasional Contributor

That is fantastic to hear John. I am yet to play with composite locators, I hope you can get a resolution. Please let us know the outcome.

0 Kudos
DanMcCoy1
Occasional Contributor

After this we change the portal item IDs of the new service to match the old, remove the old service, then remove any new portal items that were generated in the process.

This means we only have a small outage on the service and are able to maintain the service name and portal item IDs.

@DanielMcCullock2 , what method do you use for changing the Portal item ID?  AGO Assistant?

Thanks,

 

Dan

DanielMcCullock2
Occasional Contributor

Hi Dan,

We make the changes via the server admin endpoint.

If you click on the services you are working with and scroll down you will see the "Portal Properties" for the service.

DanielMcCullock2_0-1628636815077.png

If you scroll to the bottom of the page you will be able to select the "edit" operation which will allow you to modify the json for the service. Something I have discovered recently is that for non hosted MapServers/FeatureServers, if the portal items are set to "derived" then the derived attribute should be removed. This may also be true for hosted but I have not tested.

Let me know if you need any further clarification 🙂

 

Danny 

DanMcCoy1
Occasional Contributor

Ah, thanks.  Didn't realize you could do that from that endpoint.  I haven't found any documentation about it.  I wonder to what degree changing an items ID this way is supported by ESRI....?

It actually changes the ID of the Map Image Layer item in Portal that's associated with the map service?

0 Kudos
DanielMcCullock2
Occasional Contributor

No problem. I do not really know whether this method is supported. I also have not seen anything documented.

In regards to changing the IDs, think of the services on server and the Portal items as different entities. each item in Portal has its own ID and the link between the items and the services is the Item ID in the json of the service. The service also gets its access permissions via the portal item ID. You can have multiple portal items against a service but it will pull its permissions from the first one.

0 Kudos