So here’s the deal: you’ve spent ages perfecting a GP model, incorporating loads of different tools and adding custom touches in python. In fact, maybe you’ve even gone the whole hog and scripted your GP tool from scratch – and it works like a charm in ArcMap. Bingo.
You publish it to ArcGIS Server, you pull up the ArcGIS Rest Services Directory and navigate through to the GP Server Rest Endpoint. You painstakingly harvest some valid JSON to define your input parameters, and patiently wade through the ‘Invalid value for parameter X’ messages. You hit ‘Submit Job’…..and it goes kaput. Nothing, zilch, nada, zippo.
Except of course:
Where do you go now? Why does a perfectly valid GP tool break the minute you turn it into a GP Service? Well, sometimes these things happen.
First things first, I extracted the whole thing to one big Python script, and I began to pepper it with arcpy.AddMessage() calls, mainly logging vital information like, err, arcpy.AddMessage(“I am here”) and arcpy.AddMessage(“Now I’m here”). I saved the script, refreshed the model in ArcMap, saved the MXD, refreshed the map/GP services, cleared the Rest cache, (did a handstand and shut my eyes), and…
Hurrah! No, wait…
So I took a different approach. And I’m delighted to say that after a lot of huffing, puffing and flapping; a few cups of tea, the odd lunch break; maybe a quick chat about the weather with someone passing by, a few more cups of tea, a comfort break; some cheese-on-toast, a quick distraction to fix a LocatorHub web service, a stroll into town, and back again….
Um. Yeah. Cheese on toast never fixed anything.
So I bit the bullet and decided to recreate my script, line by line, to pin down the problem. With a deep breath, I started out with just a simple opener:
Failed
Soon I was pegged back to this:
Failed
What is going on?
My colleague Simon suggested I take a look at some log files in C:\Program Files (x86)\ArcGIS\Server10.0\server\user\log\. That was a good start. In one of them I came across the following (emphasis added):
<Msg time=’2011-08-12T15:07:22′ type=’ERROR’ code=’20010′ target=’pipelines2.GPServerSync’ methodName=’GPServerSync.CheckMessages’ machine=’TAYLOR’ process=’3156′ thread=’6244′>Executing (GetIntersections2Model): Model1 Start Time: Fri Aug 12 15:07:22 2011 Executing (GetIntersections2): GetIntersections2 Start Time: Fri Aug 12 15:07:22 2011 ERROR 000576: Script associated with this tool does not exist. Failed to execute (GetIntersections2). Failed at Fri Aug 12 15:07:22 2011 (Elapsed Time: 0.00 seconds) Failed to execute (GetIntersections2Model). Failed at Fri Aug 12 15:07:22 2011 (Elapsed Time: 0.00 seconds)</Msg>
Then it dawned on me. While I had been carefully storing my MXDs and data in a location visible to the ArcGIS SOC process (critical for ArcGIS Server permissions) I had stuffed my python script in a folder inside my user space. ArcGIS Server doesn’t have permissions to see in there. Such a simple and obvious mistake. But such a time-waster!
Having moved the script outside my user space to somewhere more sensible, I regenerated my model, republished my MXD and once again, cleared my Rest cache, and my script succeeded first time.
But hang on a minute. Where are my debug messages?
Remember, I had bunged a load of arcpy.AddMessage() calls into my script just to try and get some debug info. Hey – I’d even got so frustrated I used an arcpy.AddWarning() just because I like to live dangerously. But now my script was clearly executing, where was my debug info?
Well, ladies and gentlemen, here’s the crux of it. Your GP service properties window has an option in the Parameters tab, called Show Messages, but its default state is unchecked. You need to turn this on in order to see any of your custom message information (and you’ll need to do this while your service is stopped).
For security reasons, debug information is not shown by default. But providing you’re aware of the risks of exposing potentially exploitable information (eg file names/paths/usernames/etc) you can turn this feature on. That way your end user sees status information, warnings and – most importantly – error messages, which could actually be incredibly useful to them. (After all, as an end user I would want to know that a call to a service has failed.) Plus as a developer I can then give users progress updates via status messages, especially for tasks that may take more than a few seconds to execute.
So in my book, the Show Messages option should be checked as long as we’re aware of the sensitivity of outputting certain types of debug/status information.
(Aside: it is also possible to achieve the same results by changing the ShowMessages property in your service’s CFG file, but you’ll need to restart your whole SOM before the changes will take effect.)
So after all that, I finally had my messages coming through:
In summary…
If you are having problems debugging ArcGIS Server GP Services
1) Make sure your GP tool works correctly in ArcMap before publishing it as a service
2) Make sure all resources for your service – MXDs, toolboxes, data, script files, etc – are stored in a location that ArcGIS Server can access (ie outside your user space)
3) Check your log files in C:\Program Files (x86)\ArcGIS\Server10.0\server\user\log\ for clues as to why your GP service is failing
4) Turn on Show Messages and use arcpy.AddMessage() to send debug information to the client.
And if all else fails, ask a colleague called Simon*
*not all colleagues called Simon may have ArcGIS Server, GP and python experience. Use of Simons is at your own risk.