Latest Contributions by stevegourley

Layer id values in pro projects are assigned when a layer is added to a project. I don't understand the rules for how the values update when new layers are added, removed, and reordered in the project. But these id's cause issues for publishers who don't understand the importance that they stay consistent.  When a service is published to arcgis online, the layer is accessed by it's layer id. Depending on how a publisher updates that data, the layer id can change. These change happen without the publisher knowing it caused a breaking change for consumers. As a consumer, it is akin to whack-a-mole trying to keep up with some publishers as the id seems to change on every publish. Some days, they create a new project, add the data, and overwrite the service creating a 0 index. Other days it seems they create a project with a bunch of data and publish creating a layer id of 4. They publish again and it's 6. It's very difficult to trust these publishers and ultimately that boils down to the platform and the tools coming up short. The best place to educate publishers that the id's will change is during the analyze step of publishing. I am aware that some customers do not enjoy the amount of information displayed there now which can lead to it being ignored. But where else could it be displayed? What other hook is available? Are there any optional analyze tools that can be triggered by the responsible people who are interested in this information? My idea is to create an analyzer that can spot id's changing and allow publishers to read about the subject and assign an id to a layer to avoid the breaking change. It could link to a thoughtful article explaining the nuances of changing id's and yada yada. If this doesn't fit into the required analyze step, then I propose creating an optional analyze step or a way to enable "advanced" analysis. I think you get the idea.   ... View more

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. ... View more

ArcGIS Server logs two items when a request for a service does not exist; A java exception and a nicer log that X service was not found. While I understand it can be important to know when requests are being made for services that do not exist, it would be nice to remove some of these requests entirely as they produce a lot of noise. We delete services when they are no longer required by an application. We specifically tell people to not take them on as a dependency in their own applications, maps, and other systems. Yet, we find our logs piling up with messages that service x no longer exist; 1000's per week. It is almost impossible to find and notify these people to update their services based on the logs provided. We are able to block REST requests at our load balancer so they do not show up in our arcgis server logs but SOAP requests are more difficult to block. If there was an admin configuration endpoint area where we could maintain a list of services we know to be deleted and do not want to be warned about any longer, we could reduce the amount of noise in the logs to help find errors that are more important. ... View more