Hoi @erik_jan,
You can use the REST API to query the falied jobs filter the one you are looking for and with the help of the job id,retrieve the job's logfile.
see the REST API documentation:
https://docs.safe.com/fme/html/FME_REST/v2/apidoc/index.html#!/transformations/list_get_11
https://docs.safe.com/fme/html/FME_REST/v2/apidoc/index.html#!/transformations/log_get_8
hope this helps.
Hoi @erik_jan,
You can use the REST API to query the falied jobs filter the one you are looking for and with the help of the job id,retrieve the job's logfile.
see the REST API documentation:
https://docs.safe.com/fme/html/FME_REST/v2/apidoc/index.html#!/transformations/list_get_11
https://docs.safe.com/fme/html/FME_REST/v2/apidoc/index.html#!/transformations/log_get_8
hope this helps.
But don't you need the job id to check the status of the job?
I would expect the job id to be an output attribute (same as on succeeded jobs).
It is my experience that the FMEServerJobSubmitter in 2016 is buggy in this respect. As an example, the FMEServerJobSubmitter returns a different set of attributes depending on whether the master workspace is executed on Desktop and Server.
You might want to verify if that is the case for you, in my quick test it seems the FMEServerJobSubmitter does indeed return a _job_id attribute but 1) it is not automatically exposed in the workspace and 2) it is only available then the master workspace is running on Server, not on Desktop.
I think this has been improved in FME 2017, at least the _job_id attribute is now readily available on the <Rejected> port.
If nothing else works and you can't upgrade to 2017, you might want to consider using the REST API through the HTTPCaller rather than the FMEServerJobSubmitter to execute your child workspace, at least then you're guaranteed to get a job id.
It is my experience that the FMEServerJobSubmitter in 2016 is buggy in this respect. As an example, the FMEServerJobSubmitter returns a different set of attributes depending on whether the master workspace is executed on Desktop and Server.
You might want to verify if that is the case for you, in my quick test it seems the FMEServerJobSubmitter does indeed return a _job_id attribute but 1) it is not automatically exposed in the workspace and 2) it is only available then the master workspace is running on Server, not on Desktop.
I think this has been improved in FME 2017, at least the _job_id attribute is now readily available on the <Rejected> port.
If nothing else works and you can't upgrade to 2017, you might want to consider using the REST API through the HTTPCaller rather than the FMEServerJobSubmitter to execute your child workspace, at least then you're guaranteed to get a job id.
Thanks @david_r. I will try the AttributeExposer and let you know the results.
But don't you need the job id to check the status of the job?
I would expect the job id to be an output attribute (same as on succeeded jobs).
Not with the the section command that will result in all the jobs and their id's then it's a question of issueing a second command to retrieve the log file
But don't you need the job id to check the status of the job?
I would expect the job id to be an output attribute (same as on succeeded jobs).
@erik_jan, just make sure you set the detail level to high ( when using v2 of the api) to get the ws name as part of the response.
http://yourserver/fmerest/v2/transformations/jobs/completed?detail=high&limit;=-1&offset;=-1
It is my experience that the FMEServerJobSubmitter in 2016 is buggy in this respect. As an example, the FMEServerJobSubmitter returns a different set of attributes depending on whether the master workspace is executed on Desktop and Server.
You might want to verify if that is the case for you, in my quick test it seems the FMEServerJobSubmitter does indeed return a _job_id attribute but 1) it is not automatically exposed in the workspace and 2) it is only available then the master workspace is running on Server, not on Desktop.
I think this has been improved in FME 2017, at least the _job_id attribute is now readily available on the <Rejected> port.
If nothing else works and you can't upgrade to 2017, you might want to consider using the REST API through the HTTPCaller rather than the FMEServerJobSubmitter to execute your child workspace, at least then you're guaranteed to get a job id.
@david_r This seems to be working. Thanks again.
How do I fix this error?
I may be due to a problem that occurs before FME even gets to initialize the job log (e.g. startup scripts, etc). Have a look at the FME Server system logs and search for errors there.
