Tracking Job Status

The WSDevClient class, in the sample code, includes an example method to handle tracking Job status, so that your application can wait until job completion before continuing to submit requests that may be dependent on a job completing.

The method expects to be passed a Job object, which it uses to continually query the API to detect whether a Job is done or not. We check the summaryDone property of the job to determine whether the job is complete, as this provides a more complete view of the status of any spawned child jobs as opposed to the done property. See Section 5.1.4, “Working with Jobs” for more information on this. Usually, when performing a write type request against the API, a Job object is returned in the response from the API. This allows you to obtain the Job ID to perform these repeated queries.

...
@SuppressWarnings("unchecked")
    public <T> Id<T> waitForJobComplete(final OvmWsClient api, Job job, 
             final Class<T> type) throws WsException
    {
        while (job.isSummaryDone() == false)
        {
            try
            {
                Thread.sleep(1000);
            }
            catch (final Exception e)
            {
            }

            job = api.jobGetById(job.getId());

            if (job.getJobRunState().equals(JobRunState.FAILURE))
            {
                final JobError error = job.getError();
                if (error != null)
                {
                    System.out.println(" error type: " + error.getType());
                    System.out.println(" error message: " + error.getMessage());
                }
                System.out.println(" transcript: " + api.jobGetDebugTranscript(job.getId()));
            }
        }

        @SuppressWarnings("rawtypes")
        final Id resultId = job.getResultId();
        if (type == null)
        {
            return resultId;
        }
        else
        {
            final Id<T> typedResultId = resultId;
            return typedResultId;
        }
    }

Note that to track job status, the method makes a call to the jobGetById method exposed in the OvmWsRestClient class, which contains the following code:

@Override
    public Job jobGetById(final Id<Job> jobId) throws WsException
    {
        return getById(jobId, Job.class);
    }

Earlier in this guide, we mentioned that there were some generic methods available in the OvmWsRestClient class, that can be reused to query different ObjectTypes within Oracle VM Manager. The getById method is one of these methods. In actual fact, this method calls the getResourceById method defined in the RestClient class, which in turn calls the getResourceFromURI method. The method is finally capable of using Jersey's Builder API to construct a REST GET request and to return an object. This chain of methods can get confusing to follow. For the sake of keeping things simple, we present the code for the getById method below:

public <T> T getById(final Id<T> id, final Class<T> type) throws WsException
    {
        try
        {
            final Builder b = getResourceById(id);

            return b.get(type);
        }
        catch (final UniformInterfaceException ex)
        {
            throw convertException(ex);
        }
    }

It is recommended that readers continue to follow through each of the methods called in the above code to see how the URI and request is constructed. For most developers, however, reusing the code already provided in the sample client can help to abstract the HTTP level of the REST API.