I'm trying out the new version 2022.0 of FME Server, and is looking at handling engine assignments.
I imported a backup from our normal production server (2020.2), and it created all my queues, and matched these with the engines on the old server (though I had to redo this part due to the wrong naming).
But the coupling of jobs and engines is rather different in 2022 from 2020.
One thing that puzzles me, is that the restore created some "properties" for each engine, but I cannot find these anywhere in the interface. E.g. properties "22434", "WIN64" and "FME-SERVER003_Engine1" (see picture below).
What are the purpose of these properties, and how can you use them ?
And how can you delete them, if you don't want them ?
Cheers
Best answer by merlinegeorge
Thanks for providing the reason for deleting these engine properties. At this point, these system-created properties cannot be deleted from the FME Server Web UI.
When creating a new Engine Assignment Rule Property, if Engine Property "Custom" is specified, you can enter a Property exactly as it appears on the Engines page [the system-created properties]. You can then create a rule with this custom property as it would then become available as a choice in the "Rule" drop-down. For example, to specify any dynamic engine on a server called "WHISTLER" (a Custom property), create a rule as Dynamic AND "WHISTLER".
Did this help you find an answer to your question?
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
This is a new option in FME Server 2021+ for managing FME Server engines and queues.
Engines can now be assigned to queues based on either engine properties or engine names. Engine properties by default are the OS, the build of the FME Server, the license type, etc. Users are also able to add their own engine properties. When an FME Engine connects to FME Server, it reports information to the FME Server Core and that’s what we see exposed here.
I don't believe these system-created properties can be deleted from the FME Server Web UI.
Please see our blog for an introduction to Analyzing Job Statistics in FME Server. A tutorial series on Queue Control will also be available online in the near future.
@Lars I Nielsen - Could you please elaborate on why you would like to delete them? Is it just a part of clean-up since you do not use them at all or do you have any other concerns? The engine properties are only used in queue control and are not involved in any other FME Server operation.
@Lars I Nielsen - Could you please elaborate on why you would like to delete them? Is it just a part of clean-up since you do not use them at all or do you have any other concerns? The engine properties are only used in queue control and are not involved in any other FME Server operation.
In general, I don't want a lot of automatically added information cluttering up the interface. It's unnecessary and confusing. That's why I want to delete the unnecessary tags, like "version", "os" and "server name".
I get how assigning specific repositories to specific queues is beneficial, and how "free" queues can be used to cater for special circumstances, but I cannot fathom how the new "properties" are to be used.
Apparently I can create a new "custom property" (in "engine assignment"), but what is it good for ?
And what are the differences in usage between "job routing" and "engine assignment" ? They seem to facilitate the same, but are still somewhat different.
Thanks for providing the reason for deleting these engine properties. At this point, these system-created properties cannot be deleted from the FME Server Web UI.
When creating a new Engine Assignment Rule Property, if Engine Property "Custom" is specified, you can enter a Property exactly as it appears on the Engines page [the system-created properties]. You can then create a rule with this custom property as it would then become available as a choice in the "Rule" drop-down. For example, to specify any dynamic engine on a server called "WHISTLER" (a Custom property), create a rule as Dynamic AND "WHISTLER".
Thanks for providing the reason for deleting these engine properties. At this point, these system-created properties cannot be deleted from the FME Server Web UI.
When creating a new Engine Assignment Rule Property, if Engine Property "Custom" is specified, you can enter a Property exactly as it appears on the Engines page [the system-created properties]. You can then create a rule with this custom property as it would then become available as a choice in the "Rule" drop-down. For example, to specify any dynamic engine on a server called "WHISTLER" (a Custom property), create a rule as Dynamic AND "WHISTLER".
Yes, I believe it should work if the custom property created [in this case WHISTLER] isexactly as the engine properties appear on the Engines page. So for your case, you should be able to create custom properties like "22434", "WIN64" and "FME-SERVER003_Engine1"
Hi list.
I'm trying out the new version 2022.0 of FME Server, and is looking at handling engine assignments.
I imported a backup from our normal production server (2020.2), and it created all my queues, and matched these with the engines on the old server (though I had to redo this part due to the wrong naming).
But the coupling of jobs and engines is rather different in 2022 from 2020.
One thing that puzzles me, is that the restore created some "properties" for each engine, but I cannot find these anywhere in the interface. E.g. properties "22434", "WIN64" and "FME-SERVER003_Engine1" (see picture below).
What are the purpose of these properties, and how can you use them ?
And how can you delete them, if you don't want them ?
Cheers
Page 1 / 1
Hello @Lars I Nielsen ,
This is a new option in FME Server 2021+ for managing FME Server engines and queues.
Engines can now be assigned to queues based on either engine properties or engine names. Engine properties by default are the OS, the build of the FME Server, the license type, etc. Users are also able to add their own engine properties. When an FME Engine connects to FME Server, it reports information to the FME Server Core and that’s what we see exposed here.
I don't believe these system-created properties can be deleted from the FME Server Web UI.
Please see our blog for an introduction to Analyzing Job Statistics in FME Server. A tutorial series on Queue Control will also be available online in the near future.
@Lars I Nielsen - Could you please elaborate on why you would like to delete them? Is it just a part of clean-up since you do not use them at all or do you have any other concerns? The engine properties are only used in queue control and are not involved in any other FME Server operation.
merlinegeorge wrote:
@Lars I Nielsen - Could you please elaborate on why you would like to delete them? Is it just a part of clean-up since you do not use them at all or do you have any other concerns? The engine properties are only used in queue control and are not involved in any other FME Server operation.
In general, I don't want a lot of automatically added information cluttering up the interface. It's unnecessary and confusing. That's why I want to delete the unnecessary tags, like "version", "os" and "server name".
I get how assigning specific repositories to specific queues is beneficial, and how "free" queues can be used to cater for special circumstances, but I cannot fathom how the new "properties" are to be used.
Apparently I can create a new "custom property" (in "engine assignment"), but what is it good for ?
And what are the differences in usage between "job routing" and "engine assignment" ? They seem to facilitate the same, but are still somewhat different.
Are the any good examples available ?
Thanks for providing the reason for deleting these engine properties. At this point, these system-created properties cannot be deleted from the FME Server Web UI.
When creating a new Engine Assignment Rule Property, if Engine Property "Custom" is specified, you can enter a Property exactly as it appears on the Engines page [the system-created properties]. You can then create a rule with this custom property as it would then become available as a choice in the "Rule" drop-down. For example, to specify any dynamic engine on a server called "WHISTLER" (a Custom property), create a rule as Dynamic AND "WHISTLER".
On the "Table of content" on the demo page, you can go to "Advanced job control" to jump to the demos.
We do have a detailed tutorial series on Queue Contol coming up soon.
merlinegeorge wrote:
Thanks for providing the reason for deleting these engine properties. At this point, these system-created properties cannot be deleted from the FME Server Web UI.
When creating a new Engine Assignment Rule Property, if Engine Property "Custom" is specified, you can enter a Property exactly as it appears on the Engines page [the system-created properties]. You can then create a rule with this custom property as it would then become available as a choice in the "Rule" drop-down. For example, to specify any dynamic engine on a server called "WHISTLER" (a Custom property), create a rule as Dynamic AND "WHISTLER".
On the "Table of content" on the demo page, you can go to "Advanced job control" to jump to the demos.
We do have a detailed tutorial series on Queue Contol coming up soon.
Thanks for the link, I'll look into it asap.
A quick question though: Creating a custom property named "WHISTLER" automagically ties this property to a server called "WHISTLER" ?
Yes, I believe it should work if the custom property created [in this case WHISTLER] isexactly as the engine properties appear on the Engines page. So for your case, you should be able to create custom properties like "22434", "WIN64" and "FME-SERVER003_Engine1"
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.