Shape the future of FME with your ideas
New and Open ideas are awaiting review or have been reviewed by our Product Management team, and are open for commenting and voting.
When using an SQLCreator or an SQLExecutor, and something goes wrong (for example the query takes longer than the timeout-limit, or something like that), you can use the Rejected port on the transformer to catch that - which is imperative when using in a webapp, because youβll need to give the end-user feedback. On the Rejected-port youβll get the _reader_error attribute, but the way that one is populated is not very helpful. The contents of that attribute are alwaysΒ An error has occurred. Check the logfile above for detailsIt would be very helpful and much more meaningful if the contents of theΒ Provider error, which is always in the previous log file line, was added. Because then I could catch that and show that to the user:(-2147217871) Query timeout expiredwhich is much more helpful than βcheck the logfile aboveβ (there is no above - there is nothing, because this has been handled through HTMLReportGenerators to return to the end userβs browser).On FME Form itβs not a big problem, because youβll have the logfile right there - but when you then upload your workspace and create a webapp, Iβd like to be able to provide more meaningful feedback to my users (and myself).
Assuming itβs possible, FME Form should look in the same folder as the workspace for FME related components - e.g., CustomFormats,Β CustomTransfomers.Β In FME Flow if you haveΒ a CustomTransformer whichΒ lives in the same repository as a workspace it will work. It would nice to be able to keep CustomTransfomers in the same location. As it is right now in FME Form if you want to keep all files related to a porject together you need to copy the version from the location where FME can find it (e.g., FME folder) to your project folder.The process is problematic because you quickly run into issues with copying and keeping track of the versionΒ which youβre actually working with in workbench vs what is in your project folder.
At the moment DI's Orbit mode rotates around the view window origo. Better way to rotate a 3D dataset, is to orbit around mouse click and not around the view window origo. That way you don't need to first zoom/pan and then rotate to navigate in large 3D datasets.
ProblemFME Flow currently makes it difficult to troubleshoot security and permission issues involving Tokens.After a Token has been created, the token value is permanently hidden, which is good from a security perspective. However, this also creates operational challenges when troubleshooting existing integrations.Common examples include:Existing Data Streaming URLs suddenly stop working. Permission changes are made to a Token but have no effect. Administrators cannot determine which Token is being used by an integration. Multiple Tokens may have similar names, making identification difficult. Users cannot verify whether they are modifying the correct Token.In many cases, administrators are forced to create new Tokens and update integrations just to determine whether the correct Token is being used.
Dear Community,the FME Flow Helm Charts are considering Kubernetes environments where Nginx Ingress Controller are deployed.Β https://github.com/safesoftware/helm-charts/tree/master/chart-source/fmeflowKubernetes documentation describes the Gateway API as the successor to the Ingress API.https://kubernetes.io/docs/concepts/services-networking/gateway/Will there be any additional Helm Chart resources provided by Safe with these new Kubernetes resources?Best regards,Johanna
In FME Form workspaces have an βoverviewβ parameter where a description of the workspace can be created maually or generated usingΒ AI assist. However, this description does not appear to be viewable in FME Flow after publication. This could be helpful when managing content in Flow.
The opposite of the attributeExposer. Sometimes I need to temporarily expose an fme_attribute in order to preserve it's value (ex. LineJoiner) or replace it's value (ListIndexer), but would rather not have it trailing through the rest of the workspace, especially when this takes place within a custom transformer.
The GDAL libraries are highly efficient both in terms of performance and in terms of the integration of very specific raster functions.It would be very useful if FME were to integrate these libraries natively, so that they do not have to be installed and run separately via Systemcaller. This is often difficult on FME Flow instances.A potential GDAL-Caller transformer could enable them to be executed
Add an additional option to the coordinate extractor to allow extraction of start and end coordinates/multiple specified coordinates
Β When a published (user) parameter is defined with a default value but the parameter is set to βDisabledβ in the GUI, the default value gets overwritten with the value <Unused>.I would like this behaviour to be changed so that the default value is not overwritten.My use case is that Iβm trying to build a workaround for the other (as yet unresolved and long time issue) of not being able to persist a default value. (See below)Iβm trying to give the user an option to choose a default value but not have the ability to edit it, hence having it disabled. Iβm attempting to implement this by having a choice which lets the user select βDefaultβ or βCustomβ value and then enabling/disabling the appropriate inputs.Hereβs what my interface looks like with Query Type set to βDefaultβ:And hereβs what the parameter values look like after obtaining them using a ParameterFetcher:Even though the default value is set like this:Β If I choose βCustom SQLβ as my Query Type option then everything works as expected and the value comes through -- even the default value comes through correctly because the parameter is now hidden instead of disabled.Interestingly, when initially developing the workspace and the published parameters it looks like everything works fine. Itβs only when you save the workspace, close it and re-open it that the <unused> value starts appearing.
Hi,I would like to have an administrative configuration in the FME form (perhaps as part of the security hardening?) to limit the publisher type of items (transformer/packages) that can be retrieved from the FME Hub.This configuration should determine which publisher types can be used. For example, only official or verified items should be used.The reason for the request is that this would mitigate the risk of a supply chain attack involving a potentially corrupt community item. Items that are official and verified should be more trustworthy.Best regards
Hi,It would be very useful (and a best practice) to add the checksum to the FME download page (https://fme.safe.com/downloads/) and the FME Hub (https://hub.safe.com/browse) in order to verify the integrity of an FME Form, Flow and official/verified FME Hub Item install file. In some cases this might be a must-have feature forΒ customers.Thanks in advance.
[A Message from Product Management at Safe Software] This idea has been refined from its initial posting. The original description is preserved below for reference.The built-in βadminβ user account in FME Flow lacks support for modern multi-factor authentication (MFA), including 2FA or passkey-based login. This poses a security risk, especially in environments where organizations rely on local accounts as a fallback when identity providers like Microsoft Entra ID (formerly Azure AD) are unavailable.This idea proposes adding support for MFA/2FA/Passkeys to FME Flowβs local system accounts. This is critical for scenarios where SAML, LDAP, or Entra ID integrations fail or are temporarily offline, leaving only the local admin account as an optionΒ for access.Β Dear All,I would like to see FME Flow provide native built-in feature to allow users toΒ run FME Schedule or default Dashboards -β JobHistoryStatisticsGathering.fmw use Microsoft Entra SSO (FME) SAML-based adminΒ accounts.We purposefully disable local βadminβ users, since FME Flow doesn't provide 2FA/MFA option for local users but set it up to use Microsoft Entra SSO (SAML) with mandatory 2FA.Your support is appreciated :)Cheers,Reno
Support readers/writers for Bentley's Open Roads, as many transportation agencies are using them.
A question was asked about this in the MCP and FME training, and it was suggested that an idea post be made for it. I didnβt find one yet, so Iβm posting what I was thinking when the question came up:So say I have an automation app that runs a couple of workspacesΒ as needed by my manager, and emails results to an employee they choose. I think it would be coolΒ to set it up to where my manager could tell an AI chat βemail [automation app name] results to Laurenβ and it would work with the parameters like it would with a workspace as an MCP tool.Β Or something like that -Β Iβm still fairly new to MCP, and really FME Flow, but hopefully that makes sense!
Add the "EWKT" Geometry Encoding definition to GeometryReplacer and GeometryExtractor.EWKT is a simple extension to WKT that allows to include the coordinate system with the geometry, for instance: "SRID=4326;POINT(-44.3 60.1)" instead of "POINT(-44.3 60.1)"https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometryEWKT is supported by Postgis and can be found in many open datasets.
Currently the translation log window starts with a messageCommand-line to run this workspace: "C:Program FilesFME2016.1.1fme.exe" someWorkspace.fmw --Param1 "Value1" --Param2 "Value2"but this information is not reflected in the log file itself, and unless you have a ParameterFetcher+Logger, you cannot easily recreate the settings of a workspace with just the log file.I would like an option in the Translation Log Settings to write the (published) parameter settings to the log file. Perhaps as part of the FME Configuration Inform messages?
Within FME Flow I am using several Deployment Parameters in a multitude of workspaces. When managing those, I would like to be able to see which workspaces and automationsΒ are referencing a specific deployment parameter, similar to how you can see within a workspace which transformers are using this deployment parameter.The reason why? I want to be able to see my impact whenUpdating/altering a deployment parameter βΒ which workspaces andΒ automations do I need to test Deleting a deployment parameter βΒ can I delete this deployment parameter or is it still being used?Currently the only way to see this is to open every single workspace and check which deployment parameters are being used. Or managing a separate list with an overview of all deployment parameters and workspaces + automations.
It would be helpful if the text editor supported more advanced formatting options to create a more professional-looking output, including line breaks, text styling, and font customization.
IssueThe Migrating From REST API V3 section currently documents new, moved, and removed endpoints, including V3-to-V4 endpoint mappings.However, it does not document changes to the attributes within each endpointβs request and response.Customers must therefore compare the V3 and V4 Swagger definitions side by side to identify:Added, removed, or renamed attributes Changes to required and optional fields Changes to object nesting and response structure Changes to parametersThis makes migrations time-consuming and increases the risk of missed changes, integration failures, delayed upgrades, and support cases.Proposed solutionFor each endpoint mapping, include a concise table showing attribute changes. If no attributes changed, state: βNo request or response schema changesβThis should become a standard part of future major-version migration documentation, including V4-to-V5.Β Β BenefitsReduces migration time and manual comparison Prevents customers from overlooking breaking changes Makes upgrade effort easier to estimate Reduces testing, troubleshooting, and support cases Creates a consistent process for future API migrations
Hello,We are currently expanding the use of Apache Kafka across our organization, and more and more departments are requesting access to published topics.Unfortunately, I cannot use the Apache Kafka Connector in FME to publish data because our Schema Registry is protected by authentication. When the connector tries to access the Schema Registry, it fails with an "Unauthorized" error.As a workaround, I developed a custom Python script that publishes the data directly to Kafka. While this solution works, it is far from ideal. One of the main advantages of FME is that non-developers can build and maintain integrations without writing code. Not everyone in our department is comfortable with Python, so relying on custom scripts creates an additional maintenance burden.It would be great if the Apache Kafka Connector supported authenticated Schema Registries, allowing users to publish messages directly through the native connector without requiring custom Python implementations.Best regards,FelixΒ π
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.