GeoprocessingJob.Start missing JobID

Question

Hi,

When starting an asynchronous job on ArcGIS Server using Runtime SDK, I'm expecting the jobID to be available after the call to start(). It seems that I have to wait for some arbitrary amount of time before it is available. Is there a sure way to get the jobID?

var gpTask = await GeoprocessingTask.CreateAsync(new Uri(toolUrl));
...
gpJob = gpTask.CreateJob(gpParameters);
...
bool started = gpJob.Start();

TomKjaer · Answer

Well, I actually want the jobid for multiple reasons.

First of all, when there is a jobid, there is a job on the server and I can use the jobid for troubleshooting. This is especially important for our customers that can report a problem and then the jobid.

Another use is customers with on-premises ArcGIS Enterprise solutions. They typically have client applications that start long-running gp services. It's a great feature to be able to re-attach a client to a running service.

Finally, we also use jobids for logging. We obtain lists of jobids through the admin rest interface, then check and store job information, etc., since client apps might not do it. ArcGIS Server eventually cleans up old jobs.

I think the biggest problem is that we are not sure when enough information is available to restore job connections. Its a minor thing to have to keep track of a complete json string rather than a single jobid.

JoeHershman · Answer

I would guess that is maybe not the best description of the return, I don't know what condition could actually cause a false to return.

I think you describe it correctly, Start basically kicks off a separate thread that then starts the post operation and performs the status checks (firing a ProgessChanged each time).  So the first ProgressChanged really comes from the initial statusUrl returned in the primary Post request.  This way from the Runtime application you have a true synchronous method to kick it off without waiting on anything (even the initial post response).

What are you wanting the JobId for?  Or do you just want a little better feedback in the calling method to confirm the job truly started.  I do see how providing a method described makes sense

TomKjaer · Answer

Hi, so this is sort of what I'm doing already.

It's a little unclear to me what the runtime is doing. When calling start(), does that start the actual job on the server or does it start some thread inside GeoProcessingJob that monitors the job on the server?

Documentation for the return value states:

false if already running or cannot be started or resumed; otherwise, true.

I guess I wish for a method

bool b = await gpJob.StartAsync()

that actually waits for the job on the server to return a jobid.