Geoprocessing service works when run in Experience Builder or Pro, fails as task?

AlfredBaldenweck

I have a geoprocessing service that basically does a bunch of field calculations.

It has one input parameter, which the user does not see. This parameter takes a json file that points the tool to the right tables. When tool was published as a service, that json file went with it.

I got it uploaded and it works great. I'm using it in Experience Builder.

In Pro, when I open the tool from the Portal, it displays that input parameter and it shows the original file path, rather than what that file should be on the Portal's server.

In any case, the GP service works great in Pro, too.

However.

I heard that you can make an automated task via Pro by clicking the dropdown on the Run button. So I did that, and set it to run every night at midnight.

(Note that the exclamation points are from my project not being saved)

Unfortunately, when I go to check the task the next morning, it has always failed.
I was able to change the time a touch (from like 5AM to 5:15) and that appeared to largely work, but when I changed the time to 5:30, it didn't work anymore

What's the deal, here?

On a related note, how can I get more information about the task's run? Only seeing "Succeeded" or "...

ShareUser

Can you try setting up a Windows Scheduled Task outside of Pro to see if you can get it to run in that environment? You would need to have it run whether user is logged on or not and with highest privileges.

I would also suggest calling the python script (exported from the geoprocessing tool) from a bat file in this scenario with logging from both that bat file that calls the python script and from within the script itself. In this way you can tell if the bat file is running but somehow the python portion is not if logging from the python script does not get written.

AlfredBaldenweck

The bat file is actually exactly what I'm trying to avoid.

We do all of our GIS work on a virtual desktop, so I don't think windows tasks would work for me? So instead we generally do them via scheduled bat file (I don't know how they make that work), which can run hourly or daily or semi-daily depending on the file. The issue with the bat file is that my thing would get stuck behind several other workflows and end up getting delayed by several hours. Versus for a portal task, I can just set it up to run every day at 6AM and call it good. There are not any other scheduled portal tasks running on this portal right now, and honestly I don't anticipate having too many more, so provided I can make this work, it reduces a lot of busywork for us in making this process run.

AlfredBaldenweck

Weird enough, it failed yet again as a task. Also failed in Map Viewer online, but no real error message given.

Worked great when I ran the web tool in Pro this morning, though.

AlfredBaldenweck

Update: I've added an Idea to give us more details on a task's run

Tasks: Show any print statements/add messages, etc... - Esri Community

ShareUser

You can always modify the link provided by clicking the Result so that you can obtain the job URL of that run. Job URL will have a format like https://<task-url>/jobs/<job-id> as documented at Jobs | ArcGIS REST APIs | Esri Developer

You should be able to see the job messages indicating the reasons of the failures from the job URL.

DavidSolari

When you schedule a task in Pro a folder with the same name as the task is created in "%LOCALAPPDATA%\ESRI\ArcGISPro\Geoprocessing\ScheduledTools". That folder has a "task.py" file and that is the script Windows Task Scheduler runs through the current Pro Python environment.

As long as you don't screw with the logging mechanisms you can do almost anything in these scripts. In your case you can update the tool call to use a local copy of the configuration file instead of whatever (probably invalid) path is used by default.

AlfredBaldenweck

Sorry, to clarify, this is a Portal task, not a Windows one.

DavidSolari

Ah shoot, that's what I get for skimming over the images! Looks like Portal scheduled tasks ultimately boil down to the task scheduler on some machine, if you can work with your IT team to go through the Enterprise machines you might be able to find the scheduled task, which should lead to whatever is calling the tool. From there you can try and correct whatever bad parameter was saved in the task.