Allow marking arcgis server services as deprecated

[stevegourley]

Services come and go. They serve their purpose or are replaced by a more authoritative source and are deleted. Clients of these services are not notified of this change. We try our best to reach our users but the best possible approach is through the software. Pro projects and web maps will continue to load with a broken service reference but the administrators/users can't tell the difference between a service outage and a thoughtful decision to remove a service.

This is related to https://community.esri.com/t5/arcgis-online-ideas/use-deprecation-flag-through-platform/idi-p/941737 and will fill a missing gap in an often forgotten about life cycle management stage of services.

I propose the creation of a new "shadow" service type or the addition of new service states (currently started and stopped) on existing services to express the intent of the final life cycle stage of a service - deletion. Once the state is set to deprecated, users would be allowed to enter some sort of rich text to explain the situation, link to related issues or articles to help the customer repair their service. This would be served out in the services metadata so the rest of the arcgis platform has the able to react to this data and display it in Pro, web maps, etc. 

ArcGIS Server logs would not fill up with clutter about services not being found when they were removed on purpose. It would be great to have analytics on how many clients are still trying to use the deprecated service.

[jblairpdx]

I like this. It might be good at an API level as well if the shadow service/state responds with appropriate HTTP response status codes - I'm thinking mainly 301 (Moved Permanently) or 410 (Gone).

[cdickerson]

I like the idea. Added functionality to set a turn off date to stop the service. With this setting you could also set a delete date that is not on by default. Consider a check box that enables a prompt for another date.

[MichaelVolz]

Excellent idea

[KathleenCSki]

You could include a message pointing users to a new service that may work as a replacement for a deprecated service. Also it might be helpful take comments or request to delay to the stop/deprecation date for a service in use.  Customers may need time to modify code using the service that is ending and incorporating the replacement service. 

[stevegourley]

@jblairpdx I second this. ArcGIS Server using http verbs and status codes "correctly" would be a nice touch.

@cdickerson I would want to keep this ask as simple as possible to see it get implemented quickly. It's not a huge ask of people to push the button on a schedule but it would be a nice feature. Having an admin endpoint to toggle the changes would be a nice trade off so we could schedule the job in chron or windows scheduler.

@MichaelVolz thanks! 👏

@KathleenCSki Yes, that is the idea of the metadata. Provide all the information you can with links to posts/issues where they can read about the decision and workarounds etc.

Your suggestion could certainly influence having more states. For instance, a marked for deprecation state, which could trigger a warning to users with a custom message. Something like,

This service is marked for deprecation on such and such date. Follow this link for more information.

That would be a much better user experience and more polite rather than hoping they see or read your deprecation communications before pulling the rug out from under them.

[DEWright_CA]

I like @jblairpdx idea of using status-codes, where we can mark it as deprecated and set a "new" url/endpoint so that a redirect will be possible if a flag is set.

[jill_es]

Hi all - to confirm the concept this Idea is proposing, would this be for standalone ArcGIS Servers?  And would you envision this message being reflected on the items at REST, within the client consuming the service, or...?

[stevegourley]

@jill_es I don't see any reason to restrict this idea to standalone server. It seem appropriate to manage the entire lifecycle of services from any place where services can be published.

The message properties should be available from the REST endpoint. When viewing the endpoint as HTML, highlighting that message would  be useful. All the esri clients consuming the service should have the ability to display the messages.

[jill_es]

@stevegourley, thank you for that additional information!