Hello
I am having trouble configuring the Print widget in the WebApp Builder.
I am putting my print service URL into the Service URL box and its coming up with a red box saying 'The URL is not a print task'.
This exact same print service has worked many times previously and it has not changed and I have existing Web App Builder applications looking at that same print service and the printing is still working.
This is the print service I'm trying to use
Does anyone have any ideas why this isn't recognizing?
Solved! Go to Solution.
We've picked up the same problem, but we've found it only happens if you are using a print service on arc arcgis server that isn't the standard arcgis server print service that comes by default in the utilities folder i.e. if you have published a service that has custom layouts it won't acknowledge it. Put in any standard print service and it seems to work OK.
HOWEVER if you download the app code and manually change the url in the config.json file in the root of the app to point to your print service, it seems to work ok. It seems its the "builder" that has the issues with the urls - the viewers appear to work fine.
I haven't tried updating the config json for a app in ArcGIS Online using the ArcGIS Online Assistant, but i suspect that altering the service url in that will get probably work as well.
Ryan Elley
Malcom,
Are you using the http or https url? If you are using http url for WAB then you need to use the http url for the print service url.
Hi
I've tried both http and https and it doesn't seem to recognize either
Malcolm,
The main difference I recognize is that my print services are
Execution Type: esriExecutionTypeSynchronous
and your is
Execution Type: esriExecutionTypeAsynchronous
Did you build this as a custom print service so you can use custom layout template or anything?
We do use our own layouts. Our print service is currently set to Asynchronous, which is not allowed anymore, according to this?
Configure utility services—ArcGIS Online Help | ArcGIS
"You must specify the Export Web Map Task REST URL of the print service. Asynchronous print services are not supported."
Do you know what the implications might be if I change it from asynchronous to synchronous? Will our existing applications using this print service still work? (they currently are working without any issues).
I have the same problem in two cases :
I try to configure Print Widget in different ways:
==> And always the same message
For information Print GPServer executes synchronously.
Do you have any other ideas?
Thanks,
Flavie
We've picked up the same problem, but we've found it only happens if you are using a print service on arc arcgis server that isn't the standard arcgis server print service that comes by default in the utilities folder i.e. if you have published a service that has custom layouts it won't acknowledge it. Put in any standard print service and it seems to work OK.
HOWEVER if you download the app code and manually change the url in the config.json file in the root of the app to point to your print service, it seems to work ok. It seems its the "builder" that has the issues with the urls - the viewers appear to work fine.
I haven't tried updating the config json for a app in ArcGIS Online using the ArcGIS Online Assistant, but i suspect that altering the service url in that will get probably work as well.
Ryan Elley
Thanks that works. I edited the json using the AGO Assistant and changed it from the default print service to our one and that worked perfectly. Thanks heaps for your help.
This seems like a bug in the Web App Builder configuration then if the print service does actually work ok
This is a regression introduced in AGOL 5.1 update last week. We will fix it in the patch tomorrow night. Sorry for any inconvenience.
Jianxia
I just encountered the same problem listed above when setting up new Print widgets. The error returned is: "The URL is not a print task." Also, if I try to re-configure an existing print widget, I see a similar error.
In the WAB apps, the print functionality is still working fine when it was previously configured.
I'll hold off and try it again later this week after the AGOL patch has been installed.