Open ideas have been reviewed by our Product Management and are open for commenting and voting.
Whilst the workspace search function is useful, I feel it could be more powerful by being able to provide context or search criteria to it, especially when searching for attribute names. For example, "first instance of an attribute", "attribute used" (i.e. used in the parameters of a transformer - ignoring the attribute manager when set to 'Do Nothing'). I am sure there could be others...
Not that it's too much work to add an AttributeCreator/Manager afterwards, but it makes my workspace a little cleaner if I can set attributes immediately on the Creator, so something like this:The "creation instance" attribute wouldn't really be necessary anymore in this case.And while I'm posting this idea anyway: why not add an option to generate random (simple) geometries of a certain type (within a certain extent)? ;)
It would be handy to have the possibility to use parameter values in the Creator. For Example, now you have to combine the Creator with a 2DBoxReplacer to be able to use the parameters. Why not directly in the creator?
Would it be nice to use the custom geometry xml tab in the Creator transformer to accept any xml or json so that it can store (little pieces of) information in the workspace itself? Of course one could use a Creator followed by an AttributeCreator to accomplish this, but that goes at the cost of an extra transformer. And using the PythonCreator as in the workspace attached is using Python, which some people consider ugly in FME Workspace context.Idea: additional parameters, improving the user experience.Sample: See workspace attachedUse-case: Store some data (e.g., configuration data) in workspacePurpose: not having to bother with separate files for storing small pieces of config data
I use the Creator transformer for creating test instances when helping other members on the forums. Almost always, I follow the Creator with an AttributeCreator to recreate the schema. It would be nice to define those additional attributes from within the Creator itself. Another use case would be when using the Creator for Initiator features on WorkspaceRunners and FeatureReaders.
We run a lot of schedules on our FME Server and to troubleshoot some of the jobs, we'd sometimes have to inspect several logs at a time. Currently in the Jobs > Completed view, it is only possible to open a log within the same window or tab. It is essentially limited to viewing one log at a time, unless you download the log and open it in a text editor or do similar workarounds.Switching between the (filtered) list and log with browser back/forward takes some time due to dynamic reloading of the list, and some filters don't always persist when going back and forth. It would be great if logs could be opened in new tabs via middle click like normal links.
I'd like to be able to maintain python scripts as .py files independant from my workspace (Like I do with sql scripts and SQLExecutor). The pythonCaller doens't allow to parse python code from an existing fme attribute.That would be handy to implement an AttributeFileReader to read from the .py file and a PythonCaller to run the python script from the _file_content attribute.Advantage: proper version control of the python scripts in GIT
I've seen suggestions that an IDE should be added to FME Desktop. Sounds awful. More stuff that can break and in need of updates.I do agree, however, that there is a need for better handling of scripts. So why not allowing the PythonCaller, and the startup and shutdown scripting features, as well as any future scripting features, to load external files? Yes, I know you can load external files as modules, but you still need to write a script in one of FME's editors for scripts to do so, and these are unaware of typos and such, as far as I know, that is.I see before my eyes, a simple button that opens a dialog box in either of the current editors, a dialog box from which you could point to the external Python file and that would solve a whole lot. Then you would be able to write a script in your favorite IDE, have FME load the file and run it, edit the script some more, and have FME rerun the workbench, and you would never have to worry about syntax errors and such things (provided your IDE supports dealing with those).
Could we possibly have a menu option to import .py files into the Python windows in Workbench and .js files into the JavaScript windows?
Hi,I think that would be great if we could export the Python code from FME into a temporary working folder to let us debugging with our prefered application. (Ex: PyCharm, Eclipse, etc...)Exemple of what we could find into a PythonCaller, it's 2 new buttons:Export code for debuggingRe-import codeWhen we click export code, the Startup/Shutdown Python code needs to be exported to and a import line should be added on the script we want to debug in case we refer classes of functions from them.When we run the process, FME should use the external exported script instead of embeded code. In this way, we would be able to debug with our favorite software.Once the debug is done and perhaps the external code is modified, we should be able to re-import this code into FME.
The scenario: There are multiple databases which store datasets for the same feature types, but table names and column names are vary for each. The mission is to migrate the multiple databases to new multiple datasets which have common schema (i.e. common feature type names, common attribute names).Other than data tables, every database has two mapping tables - one defines the mapping rule between table names and destination common feature type names, another defines the mapping rule between column names and destination common attribute names for each feature type. Fortunately, schema of the mapping tables are common to every database.If it was possible to set user parameters or feature attributes to the SchemaMapper's Dataset parameters (including database connection parameters), a workspace containing a SchemaMapper could do the task with batch processing. However, the Dataset parameters cannot be parameterized in the current SchemaMapper, so you need to set the connection parameters manually for each database.In fact, I resolved this with a workflow containing Python scripts which perform schema mapping for each database based on the mapping tables, but I thought it would be easier if the SchamaMapper's Dataset parameters could be parameterized.
It would be convenient if we could select a User Parameter through the menu for Dataset parameter in SchemaMapper.
I would like to sort the Transformers listing in the Navigator Panel by Transformer Name or Title of Transformer. One could achieve this by right-clicking on the "Transformers" header and select "Sort by Transformer Name" versus "Sort by Title of Transformer". Currently there is no option to sort. The default is sorted by Title of Transformer.Most of the times, I tend to name my transformers by task then transformer name at the end. If I need to look for the Emailer transformer, because I need to change the smtp IP address, I then need to remember the Title to find it. If I sort by Transformer Name, I believe I could find it easier and also I may have multiple Emailers depending on the tasks at hand. It'd be a great way to group transformers and making changes accordingly.
Hi,I have previously proposed adding a checkbox to disable all inspectors when saving a workspace as a mapping file (and uploading to FME Server, I suppose). I'd still like to see that.Another great addition would be to enable sorting the listed transformers in the navigator by type (and name, as now), and enabling multi-selection in this list, so I can e.g. disable or enable multiple transformers in one sweep. This might also be implemented as a dialog box accessable via right-clicking the "Transformers (...)" item.Cheers.
This is actually two ideas to the same end.-1 Currently Workbench lists transformers sorted by name only. This means that transformers of the same type are spread out in the list, if given different names. It would be very nice if an option to sort by type-then-name was added to the list, e.g. in a shortcut menu.-2 Currently Workbench only lists transformers in the current tab, e.g. Main. It would be beneficial to have an option to have the list include all transformers, both in the Main tab and all custom transformer tabs. E.g. if one needs to update all transformers in a workspace of a particular type (in my case it was XMLTemplater), one can easily overlook one in a custom transformer, especially when they're not sorted by type.This should be a very low hanging fruit to implement.Cheers
Send (email) Action to include the possibility of re-using saved presets
When using many Automations and the "External Action - Send email" you do not want to input the e-mail server settings all over again for each workspace. Right now you can load a template (from Gmail, Outlook, Office, Yahoo) - however you should also be able to link to "Use FME Server System Email settings". Since you have already defined this under "Admin-System Configuration-Network&Email-System Email" . So whenever you need to update these credentials you can change it one place, and all the automations will be updated because they are LINKED (not copied). Or have I missed how to do this in FME:23 ?
Hi everyone,It would be nice to be able to directly use an attribute to define the name of the database connection instead of using a published parameter in the SQLCreator and Executor (see picture attached).I will allow more freedom when building dynamic workspaces.All the best,Aurélienhttps://fmecommunity-ideas.s3-us-west-2.amazonaws.com/sqlcreator.png" target="_blank">sqlcreator.png
In many workspace SQLExecutor and FeatureReader are used to query DB. When implementing automated testing I'd like to be able to run the workspace in "testing mode" and have my SQLExecutor / FReader reading from SQLite db files instead of the original ORACLE db.A simple published parameter could then be used to run a workspace in production (reading oracle db) or in testing mode (reading SQLite db) over multiple test scenarios.Thanks.
I would love if FeatureReader could read data from an attribute, not just from disk file (and the same way, FeatureWriter could write the contents to an attribute instead of a disk)Eg. binary data files (image, PDF, Excel, etc) are data URI encoded in JSON from a web service. It is straightforward to extract and decode back to binary to an attribute. However, this binary must be written to disk and read back by a FeatureReader. Writing and reading a disk is always slower than memory and it would be one less dependency (eg. folder and filename) to take care of if the FeatureReader could read from an attribute.
There are many times when I would like to be able to have one featureReader with the format set by an attribute instead of having to use a testfilter to fanout my data and a separate featureReader for every format.(The generic format does not work for my purposes because some of my data formats share extensions with other formats and the guess from extension is hit or miss)
It currently takes 6 transformers to read JSON or CSV or whatever from HTTPCaller with FeatureReader, because the http result `_reponse_body` needs to be written to an intermediate file before FeatureReader can utilize it. This is a lot of extra work when all the information needed is already present. FeatureReader should be able to take `_response_body` (or any string for that matter) as input in addition to files and urls.
Please add a <Rejected> port to the EsriReprojector.Currently, if the reprojection fails on a feature the entire translation is terminated. This becomes an issue when bad geometry is encountered on a single feature (out of potentially millions of features). It would be much better if that 1 bad feature could be logged and the translation continue.
Many coordinate systems have bounding boxes defined but if data that falls outside of that area is transformed the results may either be wildly unusable or (as one of our customers is seeing) can cause an infinite loop. So I would suggest adding a <rejected> port to the Reprojector and other projecting transformers to optionally reject features that fall outside of the bounding box of the target coordinate system.
***Note from Migration:*** Original Title was: Enable Rule-Configuration for the "IN" operator on AttributeValidator to be set from an attribute I often need to test if an attribute's value is compliant with a comma-separate list of allowable values (enumerated types) held against another attribute. I know I can test for this in a TESTER but it would be nice to have it all in one place, and with a TESTER I still need to build the validation error message.A workaround is to use Regex operator which does support attribute substitution.
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.
