Skip to main content
  • EN

Filter tasks can be added to FME Server 2019 Automations, as demonstrated during the FME World Tour.

The example shown during the WT was filtering incoming Shape file datasets after a Directory Watch trigger had fired so that the subsequent workspace would only process files with a .shp extension. However, when the Automation logs are viewed, it indicates that a filter.fmw workspace is being run to apply the filter. Does this filter workspace tie up an available Engine license? If so, could it cause contention on a system with only 1 available Engine?

I am not in a position to try this out right now but I don't think it's an issue. Even if it does tie up an engine it will only do so for the filtering. Then when that process is finished the engine is freed up and can move on to running the appropriate workspace.

Hi @nic_ran

 

You could test this fairly easily by publishing and then running a job with a Decelerator set to wait 6o mins per feature.

 

Then Trigger the automation with the filter. If the filter works then you know that it doesn't need an engine. If it did it would have to wait.

The filter does run a workspace which requires an engine. As mentioned it is a quick job so won't hold up anything else, however if a long running job is using your only engine then automations will be delayed until the engine becomes available.

The old Notifcations system is still available if this is an issue.

Hi @nic_ran,

Yes you are correct, both Filter and Log in FME Server Automations trigger workspaces to run to perform these actions. These workspaces are located in Repositories > Tools.

The FilterMessage.fmw simply contains a Tester that checks if the conditions specified in the Automation FIlter are met, causing it to end in failure through a Terminator if they do not, due to the nature of the translation I would expect the workspace duration to be only a matter of seconds.

Using the World Tour example in an FME Server single engine system you would observe the following behaviour:

  1. Directory Watch would send 4 messages to the Filter essentially triggering 4 FilterMessage jobs. As only one engine is available 3 of the jobs would be queued and run when the previous one is complete.
  2. The successful FilterMessage job will then trigger the final workspace that processes the data. if all 4 FilterMessages are not yet complete this will be sent to the queue to run when the engine becomes available.

Since the Filter jobs perform a simple, short run translation I do not think you would see any delay in the final workspace.

The only time this could cause contention is if you're automation was not going to be running any jobs. E.g. going from a Trigger to an External Action uses fme core processes so adding in a filter means the automation is also relying on the engine when it wasn't previously. However in the above example since the Automation was already going to be relying on engine availability i don't think you would see an impact.

Let me know if you have any questions.

Reply


Community Stats

30,099
Posts
114,258
Replies
37,729
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.