Shape the future of FME with your ideas
Open ideas have been reviewed by our Customer Success team and are open for commenting and voting.
Background:As an FME Flow administrator, part of my role is managing user accounts, which includes registering new users and retiring users who are no longer with the organization. A crucial aspect of this process is searching for items owned by users to ensure proper account maintenance.Problem:Currently, FME Flow only allows searching for one specific item type at a time, which can be inefficient when managing multiple item types associated with a user.Proposed Solution:Enable a unified search feature that allows administrators to search across all item types simultaneously.Benefits:This enhancement would save administrators significant time and effort by eliminating the need to manually search through each item type individually. It would allow for a quicker and more efficient analysis of user accounts, particularly when determining which items need to be reassigned or removed during the account deactivation process.Acceptance criteria:Unified Search Functionality: Administrators can now search across all item types (e.g., connections, automations, flow gallery apps, etc.) simultaneously, without needing to filter by type. Of course, filtering by type should still be possible as well. Idea has minor overlap with the following:
Dashboard and even sample workspaces are overwritten on FME Flow when a restore occurs.Restoring older versions of the dashboard workspaces has resulted in issues which are simply resolved by using the newer versions of the same workspaces.While best practice would be to download the workspaces before a restore, however I believe it would be handy to have them available online to avoid needing installing FME Flow elsewhere to obtain them.
In FME Flow 2023 the geometry picker window for a geometry-type user parameter would fill almost all of the screen. We upgraded to 2024.2, and in this version the window only fills about a quarter of the screen, and the size can’t be increased. We’ve received complaints from customers that use our Flow apps that the smaller geometry picker window is much harder to use. It would be nice if the old max size of the window could be brought back. Also, with the new version there’s no lower limit on the window size, so you can make it disappear entirely, which is a bit inconvenient.
Neo4j is an open source, versatile graph database solution that can be applied in many different situations. With all of the data piling up at companies across the globe, being able to identify relationships and dependencies among that data will be critical going forward.
Would like to see the ability to have multiple output ports - one per predicate.
I use the grid a lot in Workbench, and I often need to quickly toggle it on or off—either for clean screenshots or to help align transformers.Right now, the process is a bit tedious:- Click *View*- Click *Grid and Guides…*- Check or uncheck *Show Grid*- Close the dialog- Repeat every time I need to toggle itIt would be a great quality-of-life improvement to have a simple toolbar button to toggle the grid. It wouldn’t get in the way for users who don’t need it, and I imagine it wouldn’t be too complex to implement.
Plant3D reader and writer. Currently, Plant 3D does not support IFC export and Plant3D DWG files cannot be read with FME without losing information. Converting Plant3D DWGs using the EXPORTTOAUTOCAD command in Autodesk creates Proxy Entity geometries which can’t be read without loss of information.
Error messages encountered in translation logs should have an authoritative place to look up that error for a fulsome explanation. Twice in the last 20 minutes I’ve encountered new-to-me errors and there’s zero mention of them in the documentation or in the community forums. This experience occurs often.When a fault occurs often enough that a developer writes code to handle the situation there should also be user facing documentation, or some other systematic means of following up that’s not blind “ask the internet”.
The AreaAmalgamator uses both the Overlay and PolygonDissolver factories, which require tolerances, but there is no tolerance parameter. This leads to log messages like the below It would be useful to be able to specify a tolerance like one can with the AreaOnAreaOverlayer and Dissolver transformers.
FME repairs duplicate points in polyline geometries on read.For dwg file auditing we need an option to read the raw uncorrected duplicate vertex.Please see Autodesk AutoCAD DWG/DXF repairing polyline on read | Community
I think the title probably says enough. Transformers like the AttributeCreator and the AttributeManager now have the option to set the data type of attributes.It seems logical that this would also be an option in the ParamterFetcher transformer.
Feature caching is grat but hits performance. It would be nice to be able manually select particular transformers to feature caching while the all rest will not cache. Idea is to have 3 stages of caching by adding one in the middle1. No caching. 2. Caching only on manually selected transformers/readers/writers3. caching on all transformers.
When Feature Cache is turned on there are too many warning messages in the translation log that contribute more noise than information, making it harder to see warnings I actually care about, that make _this_ workbench different from the others. Only one of these are worth thinking about: Feature Caching is ONThe workspace may run slower because features are being output and recorded on all output ports regardless of whether or not there is a connection.Stop At Breakpoints is ONThe workspace may run slower, even when no breakpoints are present. In particular, Bulk Mode is not supported with this enabled.Coordinate system of reader identified by keyword `R_2' has changed from `YT_ALBERS' to `'-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~--~ ~--~ Feature caches have been recorded at every stage of the translation. ~--~ To inspect the recorded features, ~--~ click the feature cache icons next to the ports. ~--~ ~--~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- This idea is to add a Warning Level or Severity number so that cache messages can be hidden most of the time.Slapping the warning button in FME Desktop (Form) will toggle between:Warnings, Normal Warnings, All (a.k.a. Strict) None
Hi,It would be great to leverage the power of the Generic pattern to run a WorkspaceRunner using a unique generic parameter.Since we can use an attribute to run a workspace, you need to preload the workspace to access all parameters.If we could have a checkbox to switch it to a Generic call, it would allow us to pass only one parameter as a JSON. This way, we would only need to prepare the JSON with the Parameter/Value pair to pass to the workspace for execution.This would enhance the benefits of using Generic calling.Thank you,Jean
Hi,It would be awesome if you could provide more details on features when they output from the Succeeded and Failed ports, such as:The process ID associated with the job. The workspace name used. The full path of the workspace. A list of parameters used (since parameters can be linked with attributes, this would help determine the values being passed). If possible, the log filename created during the execution.I know the Summary provides some information, but it’s impossible to determine which output port (Succeeded or Failed) the information is linked to.The reason for this request is that when using Wait for Job to Complete = No, it's difficult to take full advantage of multitasking while ensuring that the subprocess has truly succeeded. Right now, the Succeeded port only confirms that the WorkspaceRunner was able to launch the process, but not whether the subprocess actually completed successfully.If the Succeeded port included the process ID, we could implement a waiting mechanism to verify that the subprocess has fully completed by checking the associated log file. Some tasks after the WorkspaceRunner must be fully successful before continuing. Currently, in a multitasking scenario, there's no built-in way to ensure everything has finished correctly without running in waiting mode.Right now, I use a Python script to:Retrieve the Summary information. Loop through the process IDs to confirm that no subprocesses are still running before proceeding. Verify that the process ID is still associated with fme.exe and not another process. Ensure that each subprocess generates a unique log filename so I can check whether the result state is SUCCESS or FAILED.I know that with the FMEJobSubmitter, you can use the FMEServerJobWaiter to ensure the Job ID is complete and retrieve the result afterward. However, in FME Form, I haven’t found an easy workaround for this.Thanks,Jean
When writing to ArcGIS Online any text fields that contain special characters are flagged as having invalid HTML content due to ESRI’s security policy on such fields in the AGOL context. Encoding these as HTML works, but the TextEncoder currently only allows encoding of a single field at a time and it could be expanded to do multiple fields at once.
When reading a file from the web the only options available to configure the client is the Authentication section. In some cases it is needed to tweak some of the client settings in order for requests to properly get though. Sometimes it would be nice to add custom headers or change the SSL settings for example.Of course the workaround is to just stick a HTTPCaller followed by a feature reader, however, this also means that you need to deal with temp files etc etc which just adds complexity to the workspace
As a very active user of Safe Software FME, I am very sorry to say that I do not like the 2024 layout at all.Especially the transformer layout is in my opionion tearful.Take the HTTPCaller: one of my favourite transformers when it comes to layout.Within one FME version, this transformer has transformed from a beatifully shaped one to just another cheap looking box. Safe is getting rapidly more expensive, while its layout is rapidly looking cheaper.And then there is the cange in user experience: from being just one click away to setting the parameters to multiple clicks.I would really appreciate a 2023 layout for at least the transformers. I also do not fancy the ribbon layout where every button now looks the same, but I will save that idea for others.
Based upon the question that I had: I still like to work more with FME transformers then using python callers to do same things.The systemcaller currently shows the command that it executes in the log file. It should be possible with an option to not show this command (like echo off or something like that) as the command can show passwords in plain text.
When creating User Parameters there is an option to add a Database Connection. When you use that the user running it has the option to select all database connections. It would be a nice enhancement if you could choose which database connections are available to the user.
I have multiple instances of FME running on my desktop.When opening fmw files I regularly get a message that the file is created with a newer or older version of fme. This will delete transformers or suggest to save a backup file.I would like an intermediate program that reads the file to determine what FME should be used to open the file and would like it to be part of the fme suite, not maintained by other users.# Command line to run this workspace:# "C:\Program Files\FME21821\fme.exeor#! FME_BUILD_NUM="21821"or#! LAST_SAVE_BUILD="FME(R) 2021.2.6.0 (20220727 - Build 21821 - WIN64)"
Currently, the Excel writer parameter "Overwrite Existing File" got two choices “Yes” and “No”. When choosing “No" the Excel writer append the written features to an existing Excel file. Therefor it would be more intuitive if the choices would be renamed to “Append to existing file if present” and “Overwrite existing file if present” instead of the current choices “Yes” and “No”.
When running a workspace with FME, part of the logfile is dedicated to the command line arguments. But it looks like this:And I find that very hard to parse through when I need to debug this, especially if it's for a workspace that a client sent in to support and I don't exactly know what the parameters are. So I would like to suggest putting all the parameters on individual lines, like so: And on an unrelated note, why are some parameters prefixed by a single dash instead of two and why is there no consistency in \ and / usage in the paths mentioned?
When managing web connections in FME Form and creating a new Token Service (OAuth 2.0 Credentials Flow) we need the possibility to base64 encode the consumerKey and consumerSecret in the header according to the following pattern: "Authorization: Basic <base64 encoded consumerKey:consumerSecret value>"The current workaround is to bas64 encode the requested information with the TextEncoder transformer and then hard code the encoded value(s) in the web connection template which isn’t that generic.
When using the WorkspaceRunner you often want to do something after that transformer with the results of the child processes that it spawned. Sometimes this involves launching another Workspace. At the moment there is no easy way to understand if all the child processes from that WorkspaceRunner have been fully completed.This is the crux of the problem, from the help:If the Wait for Job to Complete parameter is set to No, the initiating feature is output through this port if the request was successfully submitted, though whether or not the workspace completes is unknown in this case.One option might be a new port that releases a feature when the child processes have all been closed off, or some new parameter/mode. At the moment you need a workaround or you need to throttle the process and use 'Wait for job to complete'.
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.
