Shape the future of FME with your ideas
Open ideas have been reviewed by our Product Management and are open for commenting and voting.
***Note from Migration:*** Original Title was: Allow run workspace (incl. feature caching and partial run) for linked custom transformers, too Hello :-)This option would be great, if you are using linked custom transformers and you want to debug them.Right now the way to go is, to use a linked custom transformer inside a (blank) workspace, convert it to an embedded one and then use the run-options from the new workspace.It would be nice for development, if you can debug it directly.Best greetingsFlorian
This came up during a training course today.When the list of readers and writers in the navigator is rather long it's not very easy to see where the readers end and the writers start. An option to add some visual separation between them would be nice.I've simulated it here by adding a NULL writer and blanking out its name (which, I guess, could be a useful workaround)
It's good to see consistency everywhere in FME Desktop.To match the main menu commands names reflected in the Navigator pane, please add two main nodes to group Readers and Writers, this will make it easier and faster to head directly towards the Readers or Writers.So it will look like this:--+Readers--+Writers--+Transformers--+Bookmarks--+..(See snapshot)
Because we harvest FME workspaces in a catalogue it would be nice if we can ask the FME workbench command line to retrieve a PNG of the workspace.
***Note from Migration:*** Original Title was: In Workbench, add a Save as PDF (or other image format such as PNG) menu option. I believe such capability will make documentation and process development easier as the image of the workspace can be opened or distributed to people without FME workbench.I found this old post, https://knowledge.safe.com/questions/4529/saving-a-workspace-as-an-image.html, but I thought the solution was inadequate as the screen capture had limited size and resolution.
After workbench execution, we will be ended up with log file which have necessary technical information for failures/warnings/information.If we want to review feature count verification, we have print the entire workbench to PDF file. PDF fie does not have feasibility to review in correct order we have to search for order.So, it is better if we have print to jpg/png such that we can print entire workbench irrespective of size and we can review results as required and can print if required
I would like to be able to save down the Feature Count of a workspace run so I can restore it later. Sometimes I want to come back to an earlier result for debugging purposes or simply to compare numbers after making changes to a workspace or updating input data. At the moment there is no way to see what the counts were after closing a workspace or after re-running it. Even better if FME Server could export the feature counts into some sort of log file so I can view it on desktop without having to track through the log file.
It will be nice if I can open a workspace and display feature counts on connections from the last run of that workspace. Is it possible to store these numbers somewhere and load it into the workspace without running it again?
After completion of translation/execution of the workbench, information related to feature count like how many features read and how many written can be seen in log file.I suggest to have option to save all the feature count numbers as last executed at each transformer. This will help us to review in later stages / later processes to review and take decisions.
we have almost a hundred database connections finding, replacing and managing them is a pain when we cannot sort or filter. Is this something that can be added.
It would be great to be able to right click on a reader and update its features. I know this can be done through the Readers menu but a right click option would make this easier for workspaces with a lot of similar readers.
I think it would be useful to be able to right click on a given reader and refresh the attribute list of the reader from the source dataset. When columns/fields are added, removed, or changed in the source dataset it would require a full re-creation of the reader. I think this call also be useful on a writer to update the columns without having to re-create it.
Hi there,I would like the ability to customise the sign in buttons in FME Flow to they can say something like "Company Name Enterprise Sign In" or similar, rather than the default "Sign in with Microsoft" on our Azure AD SSO button.
Hello It will be great if we can customise the Server App login Page since we are already able to customise the app page Thanks
At the moment it is not possible to snap vertices on connections, and bookmarks, to the grid. On connections this prevents me from making perfectly horizontal/vertical lines, which is a bit annoying.The location of bookmarks can be snapped, but on a resize it does not snap. This makes it hard to create a visually pleasing bookmark layout.My proposal would be to add full 'snap to grid' functionality to these two workspace items.
The OCD (Obsessive Compulsive Disorder) part of me would like to be able to resize Bookmarks, Annotations and I guess Transformers and snap them perpendicular to the edge of similar features thus making the same dimension. Or a context menu option to make the size the same.
The ability to snap a transformer onto an existing connector when moving it 'can' be useful, but can often cause problems - and lots of CTRL-Z frustration.With the complex corporate workspaces we deal with on a daily basis, it is all too easy to inadvertently make incorrect connections.This could be solved with a menu button to toggle this on or off and/or a context menu option on the transformers themselves.
As a user of FMEI would like to have the option for a non-unique transformer name visible together with the transformer typeso I can use transformer naming to tidy up and clarify the workspace without losing information on what kind of transformer it is.From a developer background, function naming is important. A clear and concise name is generally all that's required for function documentation, and it's something I'd love to see in FME.Currently:Adding multiple copies of a Transformer gives it numbered names like 'AttributeCreator_17' which is ugly.You can name a transformer, but the name has to be unique, and you lose some information on the type of transformer used.Summary Annotation could be used, but that gives more detail than necessary and isn't very pretty.
I'm just watching a webinar with @Mark2AtSafe (or maybe @MarkAtSafe, not sure!) where the topic of renaming transformers is briefly referenced.I very rarely do this because it's more important to me to be able to see which type of transformer it is, and I can use annotation to describe why i'm doing what i'm doing. I see similar arguments in previous discussions here.But, I have an idea for middle ground - why not describe the current Transformer names as 'transformer types' (which is more accurately what they are), and allow the user to set a custom 'name' for that type of transformer?Here's how it would work: if I put down a Tester, it would appear just as it does now. But if I then change the name of the Tester to say "Test for Parks in Barnsley,' the main transformer header would rename but it would add 'Tester' beneath, perhaps in smaller text and/or italicised. That way, I can both rename my transformers and see at a glance what type it is.The downside I guess would be that it would use more canvass space.What do we think? Good idea, or too much meddling with something that can be relatively easily overcome with annotation?
Feature Caching is a great addition to FME that gives the user a much better ability to inspect what happens inside of a workspace. One addition that I would like to see to feature caching is the ability to cache multiple runs/iterations from a transformer. This would be of a help for iterative workflows when creating a workspace. For instance, I'm working with OCR-reading and rasterization techniques at the moment trying to find the parameters that gives the best OCR-reading result from tesseract. A task that is far from clear cut and that relies heavily on trial and error. Having the ability to cache multiple runs would help this iterative workflow a lot in comparing which changes give the best result. Ideally multiple-run caching would be set on a transformer level, as to not exponentially increase the amount of memory that is used. With a parameter that specifies the amount of runs to cache.
***Note from Migration:*** Original Title was: Allow users to pre-cache destination datasets before running so you can rewind or undo translations of you need to make changes
While editing a complex workspace, sometimes happens to disconnect unintentionally a connection with a slightly rough mouse operation. It would be nice if the user can switch lock (uneditable) / unlock (editable) a connection, in order to prevent unintentional disconnection of important connections.
The idea is to improve FME by adding the possibility of "freezing" the connector and transformer wires to prevent other connector wires from connecting to them. It often happens to me to insert, on large workspaces, a transformer further to the right than those already inserted and to connect it to a reader much further to the left, that is by making my "wire" cross the workspace near other entrance doors of other transformers located in the middle, thus bringing a wire closer to the input ports of other transformers. This problem arises especially when I want to move transformers into very advanced workspaces. The "danger" arises when I try to rearrange the transformers in the workspace, sometimes I happen to accidentally connect as I didn't want to.
Please set the Inspector to use bright colors by default for all features when working in Dark Mode. At the moment the Inspector uses dark colors throughout and features are often hard to see and symbology must be changed manually.
The 'User parameters' dialog in Version 2101.0.1 (Build no: 21313) is lagging the functionality of changing the parameter type in GUI interface. It always requires to create new parameter with different type rather than modifying the existing parameter to a different type. But this was not the case until 2019.2 version. It was so helpful during development/troubleshooting phase.Please reconsider in bringing this feature back.
In-depth courses for all FME skill levels.
Explore our extensive collection of how-to guides and tutorials.
Log an issue with us. Our support team is ready to help.
