I'm trying to build some simple service checks (map, feature and gp services) that are published on our ArcGIS Server site(s). Example: Check a folder for stopped services—Documentation (10.3 and 10.3.1) | ArcGIS for Server is what I'm attempting to implement but having difficulty with the request at fetching the token.
I've been provided with the serverName and serverPort parameters (lines 22 and 23 of the sample code) by our AGS admin but I keep tripping the error at line 137. If I print the response.status it shows a response of 302 and response.reason is "Found".
Any input or success implementing this script?
Solved! Go to Solution.
James,
Have you found that services need time to stop or that ArcGIS Server needs to recover before the next stop or start request is sent in. I was testing the stop functionality with a large number of services and soon found that I need to introduce a delay if I can expect ArcGIS Server to respond to each request in a reliable fashion. So this meant that I had to increase the token's expiration time as well as insert a time delay to ensure that the server is ready to respond. Otherwise I get an urllib error saying that the process has timed out. Still early days in terms of using this in production in our org.
Thanks
Subu
Hello,
Please use this script and make stop command in place of start
Also you can scheduled stop and start operation in given folder services.
Hello Avinash,
I did not realize that you had made a separate post till I followed you. Thanks for the script. Now I can see what you have done.
I used urllib2 to access the right server URL for https/ssl enabled services.
Regards
Subu
Yes Please Check and Please suggest if need to be implemented.
I can see the delay being a requirement. However, my scripting was for very basic reporting on service statuses (stopped or started) and that's it, I really have no need to actually stop/start them.
Our organization is about 6 months into building out our AGS environment(s) with new waves of more data migrating out of old sde into new sde db's, more map/feature service publishing is planned. As we found in the first wave of this, not everything is published perfectly and requires making adjustments, so when you have other products being developed and built from these services that are prone to change (schema, attributes, layer indexes, etc.), those products tend to be susceptible to breakage. So... by incorporating a single-point GP service that has the single job of checking to see if a service is stopped or started, error and process handling can be built into the apps using those services.