PrintingTools (GP server) Export Web Map Task -> execute fails - 404 error

[SebastianRoberts]

I have an ArcGIS server 10.1 installation with the GIS server behind the firewall, and the Web adaptor installed on a public web server.  I am trying to test our server's Utilities->PrintingTools (GPServer)->Export Web Map Task->execute function using the REST services directory.  I have all the parameters correct and can Exectute (POST) from inside our network.  When I try to execute it from outside our firewall I am able to get to the execute page, but when I hit the Execute (POST) button, I get a 404 page not found error.  The utilities folder and the Printing Tools service are unsecured on our server.  I am able to access our other published unsecured map services and am able to carry out a function such as Query (POST) on that map service from outside our network. 

Does anyone have an idea of why this might be happening, or suggestions for troubleshooting methods? 
Thanks in Advance,
S. Roberts

The url for our print service is http://webServer/arcgis/rest/services/Utilities/PrintingTools/GPServer/Export%20Web%20Map%20Task/exe...          where webServer should be replaced with gis.nevcounty.net

I am using these parameters
Format: PDF
Layout Template: A4 Landscape
Web Map as JSON string:
{"mapOptions":{"extent":{"xmin":-13469468.571186269,"ymin":4768589.386064244,"xmax":-13440441.609695012,"ymax":4781488.134587351,"spatialReference":{"wkid":102100}},"spatialReference":{"wkid":102100}},"baseMap":{"title":"Shared Imagery Basemap","baseMapLayers":[{"url":"http://gis.nevcounty.net/ArcGIS/rest/services/web_public/web_cache_base/MapServer"}]},"exportOptions":{"dpi":300,"outputSize":[500,500]},"layoutOptions":{"titleText":"TestMap","scaleBarOptions":{"metricUnit":"kilometers","metricLabel":"km","nonMetricUnit":"miles","nonMetricLabel":"mi"}}}

[RobertMacQuarrie1]

Hello Sebastian,

Can you check if your Firewall has a POST requests size limitation?  This could be causing the issue if the output of the process is larger.  You may need to contact your IT staff to change this.

-Robert M.

[SebastianRoberts]

Robert,
Thanks for the suggestion.  I took a look at the firewall settings with our security officer and the post size limit looks to be well above the size of the request.  We looked at the Barracuda firewall log for the denied requests, but it didn't get any more information that the 404 response header that you can see using developer tools in Chrome or IE.
Thanks again for your suggestion.  Let me know if you can think of any other potential cause.
Regards,
Sebastian

[KeG]

are you able to execute against any of the other Utilities or the Geometry service?
have you tested with another output type other than pdf?
i would try to simplify the call to see if there is some param that is messing it up.
it is a rather odd issue that you would get a 404, that sounds like the request is not even getting to your IIS server to be processed. so you would not see anything in the iis logs correct? and the ags logs are probably not much help either because the requests doesn't get there either.
that would lead me to think this is some kind of iis issue. you are using IIS yes? what version? do you have ags running in it's dedicated IIS app pool?
perhaps you could try using the ip of the server in the request instead of the server name. maybe there is a DNS issue related to the naming of the site - although it seems like you wouldn't be able to even get to the execute page if that were the case.
just throwing things out there....

[SebastianRoberts]

Thanks for your responses.  We found that the culprit was a "max parameter value length" on the firewall.  The POST request size had thrown me off because the post limit was sufficient, but hadn't looked at the allowed parameter value lenght.  On our Barracuda firewall, the default was 1000 characters, which won't be sufficient for many map requests.

[KeG]

when you say 'custom' export task - did you create this yourself using python, or within arcmap maybe?
It sounds like you are close to a resolution in that the output directory stamping is incorrect.
You do get an image generated, it is stamped to disk, its just that the response has an incorrect url.

I work mostly in js not silverlight so this may not be as applicable to you.
you have two approaches as i see it - you try to fix the output response or you workaround and rearrange that url when it is returned.
For the fix, maybe you can recreate the custom print tool the way you did it originally but with a design for its external use. Part of the issues with gp tasks, publishing and ags is that esri has a single solution for desktop and server. But sometimes you are creating tools that have no desktop counterpart or are never intended for the desktop. yet you must go through arcmap.
For the workaround - if the url is in a predictable format, and you have a chance at accessing it in code before it is resolved then maybe you could use regex or something similar to modify that url and correct it.

With the js api there is a print task widget that makes it easy to call print jobs. But it also takes control away from the developer. In this instance you want the control back so you can recreate the print calls yourself and not rely on a widget so that you can access the response url and reorder it the way you want.

[KeG]

yeah. that is kind of the crux of my issue with the way gp tools work in general.
at 10.1 esri has forced us to run the gp tool in ArcMap and publish the result.
Well, newsflash, many tools are not designed to run in arcmap, ever.

is there an output directory that you specify when you create the tool?
If so try to point that to your adapter machine.

I'm not familiar with the setup you have so its hard for me to comment.
I'm just saying that is one area to look into.

Another area is that when ags publishes your gp tool it fundamentally alters it (in the name of 'improving' your code)
Dig and try to find out where that py script is being published on your server and then edit that directly to get the print output where you want it.

[KeG]

good deal.

[AndrewBrown1]

Thanks for this... it helped the print task deliver the PDF/JPEG/PNG to the client.

Our GPPrintTask tries to utilize the external URL to obtain the layers, but the GPPrintTask cannot use the external URL as it sits on the internal URL.

Do you know how to force the GPPrintTask to utilize the internal URL to retrieve the layers for printing?

Thx.