Skip to main content
  • EN

Hi,

Since we upgraded FME Server a few months ago from 2016 to 2017 I've been unable to chain jobs together successfully when using the FMEServerJobSubmitter Transformer.

I have two workbench's on server which need to run in sequence, the workbenches are run in sequence by creating a third workbench utilising the FMEServerJobSubmitter transformer. Since upgrading to 2017 the 3rd workbench used to chain the jobs together just hangs on server when run until i eventually cancel this?

 

All jobs are set to run on the same engine, it's as if the the chain jobs workbench is waiting for the 1st workbench to run, however because the chain jobs workbench is running it needs to clear before the first workbench can run!? Never has this issue with Server 2016?

It's worth noting that since we upgraded from 2016 to 2017 we increased our server engine capacity from 1 to 2. I can of course set the chain jobs workbench to run on a different engine, however for operational purposes this isn't a viable solution, plus the fact the both engines would be taken up for the same process.

Thanks in advance.

Chris

you can use fme server job waiter, this transformer will makes to wait till the first job id completes.

You can also use job queue functionality available inside fme server which will send the jobs to predefined engine. you can create one attribute in master script for to segregate which job goes to which engine.

you can use fme server job waiter, this transformer will makes to wait till the first job id completes.

You can also use job queue functionality available inside fme server which will send the jobs to predefined engine. you can create one attribute in master script for to segregate which job goes to which engine.

Unfortunately using the Job Waiter transformer hasn't worked, again because the chain jobs workbench is calling the 1st workbench but as they are both set to run on the same engine the 1st workbench can't run until the chain jobs has finished! interesting how we never experienced this issue on 2016?

 

 

Hi @clang

 

 

This article should explain some of the behaviour from 2016 to 2017

Hi @clang

 

 

This article should explain some of the behaviour from 2016 to 2017
Hi, thanks for this but it doesn't really answer my question. In the article it mentions this is a common problem but doesn't offer up a solution?

 

 

thanks,

 

Chris

 

Hi, thanks for this but it doesn't really answer my question. In the article it mentions this is a common problem but doesn't offer up a solution?

 

 

thanks,

 

Chris

 

Have you deleted the FMEJobSubmitters to ensure you have the latest version, when publishing to FME Server 2017? I see version 3 as the transformer in FME 2017.

 

 

Based on the table in the article, I would expect that when Wait = Yes, and 'In Sequence' is set then you would see:

 

  • FME Server accepts a new job when the previous job complete
  • Runs one child workspace as a sub process on the one engine
  • Child workspaces will display in the history as their own job and the engine id will be tagged with the parent job id. Eg. engine1@job123

     

Do you see the same behaviour if you remove the job queue from the FMESJS parameters?

 

 

Hi @clang

 

 

This article should explain some of the behaviour from 2016 to 2017
Thanks for this, clearing the job queue parameter did the trick.

 

 

Populating the job queue parameter in the FMEServerJobSubmitter Transformer caused a conflict, leaving this parameter empty ensured both the parent and child job ran on the same engine.

Reply


Community Stats

30,147
Posts
114,431
Replies
37,790
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.