Keep Service Definition Files?

[DanikBourdeau2]

Hello,

Whenever I publish features to ArcGIS Online a service definition file remains in the ArcGIs Online Account, after the successful creation of the feature service.  Is it necessary for this file to remain for the feature service to work, or is it ok to delete the service definition?

Thanks,

[KeisukeNozaki]

I have the same question and hope someone will answer.

Thank you.

[KellyGerrow]

Hello,

There is no functional reliance of a published feature service on an SD file. As Denik mentioned, once the feature service is published, the SD file doesn't interact with the Feature Service moving forward. You can delete the SD file after publishing without affecting your service, but I will outline a few considerations below regarding this choice:

Are you going to republish this data or  have another organization publish the same service?

The SD file can be used to republish the same data in your organization or can be shared for others to publish the same Feature Service. This may be helpful for test data which needs to be republished often or a publishing environment where items are moved from Staging to production in different organization. When you have an SD file in your content in ArcGIS Online, you can easily hit the publish button if a new service needs to be created, instead of having to re-upload the same data.

Will you be overwriting the Feature Service from ArcMap as a regular workflow?

Currently, there is a known issue with overwriting feature services from ArcMap if the SD File has been deleted. If this will be a common workflow, then store the SD File in your content.

A note on credits. The credit charges from the SD file will come from Tile and Data storage at a cost of 1.2 credits per 1 GB per month. So depending on you SD file size, credit charges will be minimal.

In the end, the choice is yours for keeping of deleting the SD file.

Let me know if you have any questions,

Kelly

[RyanMonk1]

The Service Definition items stored in our ArcGIS Online organisation appear to be consuming the Database Storage credits, not File Storage, so the credit charges are becoming significant.

[KellyGerrow]

Hi Ryan,

I suggest that you contact Esri Technical Support​ regarding this issue. They can help to look into where the data is stored and address any issues if needed. When you look at the Storage graph in the view status page, click on the File Storage tab. This is where the SD file storage values will be reported.

Feature storage shows the amount of space the organization is using to store hosted feature layers. There are two values, Database storage (data in the feature service) and File Storage (any attachments added to the feature service).  Database storage is charged at the the rate of 2.4 credits per 10 MB per month. File storage is charged at the rate of 1.2 credits per 1 GB stored per month. The SD file storage should not be contributing to the storage values under the Feature Storage report.

View status—ArcGIS Online Help | ArcGIS

-Kelly

[MelanieRosenberg2]

Will there be any progress on the bug mentioned above? It appears to be an old bug by now, so does it still persist in the latest update of AGOL?

[KellyGerrow]

Hi Melanie,

Depending on which app you are publishing from will determine whether you need to keep an SD file for overwriting. If you are overwriting a service from ArcGIS Pro, the ArcGIS Online Item details page or the Rest API, then you won't need an SD file present. If you are overwriting from ArcMap, you will need to have an SD file present in your content.

-Kelly

[AdamMesser1]

Kelly Gerrow‌ it appears that your original answer may no longer be valid. The documentation  About hosted layers—ArcGIS Online Help | ArcGIS  indicates that "You cannot delete the service definition file until you delete the hosted feature layer." Can you revisit your answer to determine why this is? What functionality has been implemented that requires the sd file be maintained for the hosted feature layer?

As of last weeks update to AGOL we cannot delete either shapefile or service definitions while the hosted feature layer exists. However, we can still send an api delete command to remove the service definition content item without error. We are now concerned that there will be lost functionality or errors that result from this deletion. Thanks - adamm

Bill Daigle‌

[AndrewHansford]

Hi KGerrow-esristaff I have noticed the same here. So if you were to have a large file lets say some aerial imagery then you have to maintain the tile package (xxMB) and the Hosted Tile Cache (xxMB). Does this mean that you are doubling up on Credit Usage?  ajh22‌

[KellyGerrow · Accepted solution]

Hi Andrew,

With the December update to ArcGIS Online, some additional functionality was added in regards to deleting files that have dependencies to other layers. For example, if you want to overwrite a feature service from ArcMap or update services from CSVs or FGDBs its required that the source data is present in your content. You will see a similar error message if you try to delete the primary hosted feature layer that has dependent view layers created. This was put in to help users understand the dependencies between different content in their organization and the relationship with other content.

If you don't need the dependency (won't be updating your tiled service) then it is possible to delete the source data from your content without deleting your service. To do this you will need to delete more than one piece of content, so do this when you need to delete multiple items or create a web map for deleting.  Navigate to your content and select more then one item, then hit delete. This will successfully delete content with a relationship to other content.

Thanks for providing this feedback. We can look into how to improve this workflow in the future.

Are there ever any cases where your tiled services are updated from the TPK or do they tend to stay static? I would suggest logging an idea on https://community.esri.com/community/arcgis-ideas?sr=search&searchId=7d64a60a-5646-4b6d-af77-0dc90e7...‌ to discuss this in more detail.

-Kelly