Shape the future of FME with your ideas
Open ideas have been reviewed by our Product Management and are open for commenting and voting.
Would be great to have a Search Filter In the dialog which is handy when there are several workspaces in the same repo.
Idea: cancelling a job will rollback the whole transaction of all features for Snowflake WriterObserved behavior: cancelling a job in FME Flow will stop additional features from being written, but features that have already been written to Snowflake are already committed without any rollback of the transaction. There is inconsistency between “Features Written’ as recorded in the job log and actual features written according to Snowflake logs. The job log records zero features written while there have been many features written to Snowflake despite job being cancelled.Desired behavior: cancelling a job in FME Flow will stop additional features from being written and rollback any partial changes the job has just done. Outcome: improved management of jobs.
It would great and highly beneficial to see the exact processing time for each individual transformer directly on the transformer. This feature would allow users to easily identify bottlenecks and optimize workspace efficiency without manual benchmarking in the log.
When downloading data using Data Download service (e.g. from an FME Workspace App), a Zip file is created containing the output files. The zip file is automatically named something that looks like “FME_4B425D3A_1772473610895_13172.zip”. It would be nice if an option was implemented to allow customizing that name to something that is more user friendly. For example allow authors to specify what exact name the Zip file should have, or allow the use of parameters to create a string to use as file name. Even if the final filename has to have some extra characters at the end like 4B425D3A_1772473610895_13172, giving authors some customization capability would be beneficial.
Hello,To continue with data platform integration, is Safe discussing with Databricks to be added to its Marketplace, like with Snowflake? @irenemunoz maybe.
I’m trying to write features to an esri feature service, but getting “fatal errors” from the feature service that is causing the entire FME workspace to fail. I should be allowed to decide what to do if a “fatal error”, much in the same way that I can choose how to handle rejected features (Terminate Translation or Continue Translation).FME should just “fail” that single request and continue writing features out. Examples of where this would be useful:
When writing PDF it would be good if I could choose to write PDF/A version of the files. PDF/A is an ISO standard specialized for the digital preservation of electronic documents and in several cases it's a requirement when delivering PDF-files to a customer.
Since it does not seem possible to automatically shutdown an instance in FME Flow Hosted, one workaround we found is to apply schedules to shutdown the instances. However, this is done manually and can be easily forgotten. A good way to ensure the instance has one is to suggest a schedule at the creation, with having a certain default value created. Hope this makes sense, let me know if this sparks any more ideas or if you need further information on the subject!
This implementation focuses on adding a dedicated log window to the FME Flow Web Application UI. The log window will display real-time and historical execution logs, enabling users to monitor data flows more effectively. It improves transparency, simplifies troubleshooting, and enhances the overall user experience by providing immediate access to process details.
It should be possible to define default pagination parameters at the Data Virtualization API level, while still allowing bespoke pagination configurations for individual endpoints.Currently, pagination must be configured within each workspace, which can complicate workflows and, in some cases, negatively impact processing performance. This configuration also needs to be repeated for every workspace endpoint, leading to unnecessary duplication.A more efficient approach would be to manage pagination at the parent API level, with the following capabilities: A configuration option at the API level to enable or disable pagination globally A configuration option at the endpoint level to determine whether the endpoint inherits the global API pagination settings A parameter to define the default pagination size (i.e., the number of results returned per page)
***Note from Migration:*** Original Title was: Add Support for Aggregate Geometry Type (Esri ArcGIS Online (AGOL) Feature Service Writer) Add support for writing Aggregate features with the Esri ArcGIS Online (AGOL) Feature Service Writer.Currently this is not supported: https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/arcgisonlinefeatures/quick_facts_arcgisonlinefeatures.htmExample of community discussion of this feature: https://community.safe.com/s/question/0D54Q000080hRcE/cannot-write-to-esri-after-using-aggregator-mutipart-geometry?t=1619549337262
Level up to the parquet format (updates and snapshot)
Being able to reorder the attributes on a transformer is awesome. However, it's also tedious. Repeated right-clicks and selecting "Move Up" or "Move Down" in a long attribute list is painful.It would be great if you could drag/drop attributes to change the order. So instead of clicking and dragging anywhere on the transformer to move it on the canvas, clicking and dragging an attribute should allow it to be moved up or down the list. Then transformers would only be moved on the canvas if you clicked the top of the transformer (where the name is displayed) and dragged it around.
Is it possible to add the 'Attributes to Read' option from the Readers to the FeatureReader transformer, too?For the same basic reason: not to read unnecessary data when the feature type is large.
Possibility of including images inside Annotation . Is better when we want to document our Workspace with images.
Introduce the ability to add Dynamic input ports to the PythonCaller.
It would be nice if the ChangeDetector match all attributes could exclude unexposed workspace level attributes like multi_reader_id, multi_reader_full_id, multi_reader_keyword, multi_reader_type.As it is, I need to either use match selected attributes and select them all (not possible in dynamic scenarios) or expose the multi_ attributes prior to the ChangeDetector so that match all except can be used.
Please add support for reading PLY - Polygon File Format, a 3D model format, also known as the Stanford Triangle Format: http://paulbourke.net/dataformats/ply/
***Note from Migration:*** Original Title was: Add support for integrated Windows Authentication (IWA)/ Single Sign On (SSO) for rest services (fmedatastreaming) If you configure fmeserver for integrated Windows Authentication (IWA)/ Single Sign On (SSO), it affects the web UI only, not rest services (as far as I know). This enhancement will make it easier to access fmedatastreaming with published parameters etc. in a secure environment.
The problem The documentation for FeatureMerger mentions a "Suppliers First" mode that can reportedly be very beneficial to performance (and, I would imagine, crucial for Streams), but comes with the constraint that all suppliers must have arrived before the first requestor comes in. To my knowledge, there is currently no way in FME of upholding that guarantee in a reliable manner. The timing between Readers, Creators, FeatureReaders and SQLExecutors is not something I can claim to understand, and the completion order can change based on whether caching is turned on or not. This is already troublesome when editing workbenches, but it can be expecially problematic inside custom transformers, where you don't have control over the delivery order of features in your input ports. This isn't merely an issue with FeatureMerger; it's going to be a problem at any time where you rely on input ordering for a transformer to work properly, with specific attention given to Streams and Feature tables. If I have a PythonCaller that configures itself based on data coming from TransformerA before it's ready to accept data from TransformerB, there isn't a lot of options for reliably dealing with out-of-order input. Holding onto features is illegal when bulk mode support is advertized, so the PythonCaller must either opt out of it (which hurts downstream performance) to accumulate any features it's not ready to process until the configuration features have come in. Even then, it can't know when TransformerA has closed, so unless it only expects one configuration feature, it's dangerous to start processing before close() has been called. This might be clearer when considering the attached screenshot: Python_MapAttributes needs the output line from JsonTemplater in order to work with the data coming from MappedInputLines. If MappedInputLines starts sending features first, the PythonCaller can't do anything yet, and can only crash (undesirable) or start buffering features (illegal in Bulk mode). The solution The idea would be to have some sort of Semaphore transformer, something like a FeatureHolder, but with (at least?) two input ports: a "Priority" port, which lets features through normally, and a "Held" port which buffers features until the other port has closed and no more features can go through it. This would ensure that no feature from the "Priority" side can ever arrive before a "Held" feature, thus allowing workflow and transformer designers to guarantee feature ordering downstream without breaking bulk mode. Other relevent use cases One might also consider having a Terminator node which should stop the translation when an assertion or a join fail in some unexpected way, but should wait until every faulty feature has arrived to give proper context instead of immediately stopping at the first one. Bad features could be sent through the priority port and then the priority port routed to a terminator, so that no feature can be passed to the next step until it has been verified that none exist that would trip the Terminator. This would also allow the Terminator to be changed to wait for all features to have arrived before stopping the translation, instead of aborting at the first one (which currently makes sense, as the more you wait, the more you risk that downstream writers will have already started to write incomplete data).
As noted here, it would be nice to have the ability to write additional components such as Classification, Intensity etc, with our Cesium writer.
I see the Aggregator has an option to calculate average values weighted by area. It would be handy to see a weighted by length when used for lines. it’s easy enough to handle this calculation without the help of the Aggregator but it would be a nice little improvement.
Include the possibility to align text (left/right/center and topmiddle/bottom in the PDFStyler.Currently the alignment of text (coming from e.g. a LabelPointReplacer) in the PDFPageFormatter needs to be done by trial and error, and still this does not give satisfactory results when text length can differ.
FME24 provides an overly simplified and bland user interface and experience. Even as a long time FME user I find it difficult to use and even train new users. Personally, I’m yet to find a single benefit of the change.E.g. Simple icon colours which categorise items in the navigator (Purple = Parameters) are gone.Similar to being able to select dark mode, I think it would be extremely helpful to enable users to select the theme and icon styles that improve their user experience.
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.
