Open ideas have been reviewed by our Product Management and are open for commenting and voting.
Currently, The Testfilter transformer returns entities to the output port that responds to the first conditional statement that the entity verifies.However, as indicated in the title, there is some cases where I would be interested for the same entity to be able to exit by zero, one or more output ports at the same time depending on the number of conditional statement it verifies.It would therefore be duplicated as many times as it checks a conditional statement.In my opinion, this feature could be implemented through a new TestFilter transformer parameter or a new transformer.
Hi,SchemaScanner contains a regular expression IgnoreAttributeContaining parameter. If its value is based on a user parameter or on attribute, the regular expression is not recognized. It would be great if we could do that!
Add another selection to the workspace "Rejected feature handling" options: "Redirect to:"If a user selects "Redirect to", they will be asked to select a transformer to redirect to. This transformer can then handle any rejected features. This would be like traditional programming exception handling.I know it's possible to manually connect <Rejected> output ports to transformers but this would offer a catch-all option for generic error handling.
Hello,It's possible to resquest the event of FME Server via API REST with this resquest :https://docs.safe.com/fme/html/FME_REST/apidoc/v3/index.html#!/systemevents/listCompleted_get_4But we can't choose a date rage. This option could be very usefull for interact with monitoring toolsThank you
Would it be possible to expose the requested service as a server parameter, eg.: FME_SERVER_REQUEST_SERVICE ?It would make it easier to provide different outputs in a schedule and download/streaming service (eg. different file format or file names).There is a workarund ro calculate it from FME_SERVER_REQUEST_URI but it is not that elegant and it may fail if someone changes the Service endpoints in Server Configuration.
We are currently on V3 of the FME Server REST API and, even though the documentation claims "FME Server REST API V3 is our stable REST API", this is not actually the case. A quick look at the REST API documentation for an FME Server 2017 installation, compared to an FME Server 2019 installation will reveal significant differences.It would be great to have a query that could be run against the API to return the true version (I REALLY hope that Safe is tracking changes to the API as difference versions...). At least if the version was available, then users of the API could program their solutions to take account of the differences if possible.It would also be great if the documentation could indicate in which version of the API a certain functionality added or updated/modified.As an example, FME Server 2017 offers the following endpoint:GET /transformations/jobs/< section >where <section> can refer to Completed/Running/QueuedIn response to a query to this endpoint, the "request" item contains a "workspacePath" value which can be used to extract the repository and workspace details but there is no direct response item for these values.FME Server 2019 offers documentation on direct endpoints, such as:GET /transformations/jobs/completedA response to the above query contains additional information in the "job" portion of the response, which provides access to the repository and workspace names (not available in 2017).In summary, an application written to work against "V3" of the REST API is not guaranteed to work if the underlying FME Server version changes.Please update the REST API to make it simple to programatically query the true version of the API being used or, even better, to programatically query the API itself to determine its capabilities and query/response schemas.
It would be very convenient to see the values of parameters in triggers/actions in an automation at first glance and always up to date. We use simple annotations and write those values as text in them. But obviously, these annotations cannot be relied upon too much, as it's easy to forget to update the annotation, when a parameter changes...
Often I need to recalculate attributes based on its own values. Sometimes the fields are basically the same, and therefore the formula is the same. But because the AttributeFieldName is different, every time I copy the formula, I also need to adjust for the changing fieldname. Which can easily introduce errors, especially when you have a lot of fields.Why not have an operator which specifies the value of the current field. That way in the AttributeManager would look something like:FieldA conditional value if <thisAttributeName> has a value then @Value(<thisAttributeName>)else if 10<@Value(CheckField) then 'G'else nullFieldB conditional value if <thisAttributeName> has a value then @Value(<thisAttributeName>)else if 11<@Value(CheckField) then 'G'else nullinstead of:FieldA conditional value if FieldA has a value then @Value(FieldA )else if 10<@Value(CheckField) then 'G'else nullFieldB conditional value if FieldB has a value then @Value(FieldB )else if 11<@Value(CheckField) then 'G'else null
The AttributeCreator adds new fields before exisiting attributes. It would be an improvement if there was an option to chose to add the new fields before or after existing attributes. This would save use of the AttributeManager which is often needed just to remedy this.
An integrated transformer that simply filters "candidates" based on whether there is a match in "filter." This could be based solely on matching attributes (definitely the most important component), or could function similarly to the Matcher (allowing for required differences and geometry). I have attached two workspaces: my "FilterByJoin" transformer, which I use no fewer than 5 times in any workspace I create (and relies, in turn, on two other of my custom transformers), and the beginning conceptual development of a "MatcherFilter" in a few different forms (with some pretty significant performance kinks to work out)Filtering by matching attributes can currently be achieved in its most-basic form by passing data to a FeatureMerger with candidates as the Supplier and filter as the Requestor, then using the "UsedSupplier" and "UnusedSupplier" outputs, but streamlining that into something that is more transparent in its purpose requires additional steps in a transformer like the "FilterByJoinExample" I've attached! NOTE: The "Add Attachments" button isn't bringing up any dialogue, so if clicking "Create Idea and Next" posts this and I am not able to add attachments after posting... well, then disregard I guess!
After a translation has finished, I'd like to be able to right-click on a connection and save the feature count to annotation attached to that connection.
The dynamic engines capability is a very good extension of the FME Server capabilities. At this moment, it is possible to assign repositories to a dynamic engine. However, I think it would be interesting to be able to assign specific workspaces to a dynamic engine. I that case it is possible to only use specific workspaces with this functionality without the need to put these in a separate repository. It would be even more interesting to be able to separate bought credits for dynamic engines so we can assign different budgets for different workspaces.
HiIm not sure if the title is accurate, but im trying to explain what would be nice to have.Im having the geometrypicker for constructing a box, now i would like to limit or at least show that a maximum length of a side is reached. And this would be nice to see after constructing the box (without the need of starting the workspace).Like i want to be length of the sides limited to 500m, so after geometry is set, another parameter (e.g. python scripted) calculates the lengths and at least shows it, so the users sees that it is too long and can correct it.
I like the idea of the FeatureWriter that has Attribute Connections. But I think it is more powerfull to do this with this idea: AdvancedAttributeCreator. In the manager you set the AttributeNames and the DataTypes these Attributes need to have. It should be inspired by the SQL create Table parameters. And you should be able to connect the inputs to the correct attributes.
If you workspace has a dynamic reader, it's possible on startup to select dynamically the featuretype you want to process. This changes when there is another type of data provided for that reader format.I'm looking into similar functionality, but on attributes. So that users can select on startup a certain attribute that is present in their provided source. This allows dynamic workspaces to be much more efficient at my side as I'm not hampered if the input data has a different attribute name then what I'm using in the dynamic workspace
I would like to be able to export field mappings in the Attribute Manager transformer to an output file such as a CSV. Currently the only option to right-click the transformer and Show Summary Annotation. This has limits on the number of rows.
I really like the AttributeJSONPacker, I think it should be promoted to a full transformer. However, I miss the possibility of adding attributes as JSON arrays from lists.
Can we add the option to save any sql scripts created via FME can be saved in the *.sql file format.
When deleting items in FME Server a confirmation dialog is displayed asking "Are you sure you want to delete this item?", or "Are you sure you want to delete the 99 selected items?".The problem is, the Actions > Remove menu option is at the top of the page and if the number of items exceeds the page length, then it is not possible to double-check which items are being removed.It would be nice if the dialog could list the names of the items being removed.
It would be really nice to be able to control access to ESRI SDE Connection files by FME Server roles, much like we can for named connections in FME Server. We have to embed authentication into the sde conneciton file itself (using the passwrod override in the fmw itself is not a solution, that has it's own set of issues), so access to these sde connection files needs to be controlled. I would imagine the architeture of FME server would make this a challenge, but it is worth exploring in our world of ever needing tighter security on things.
Hello all,It would be great to be able to define a python function in a workspace that is then callable from within the Arithmetic Editor of Transformers within that workspace. Similiar to how you can call the the built in functions such as @degToRad(<float>), @min(<float>,<float>,...) etc.This would be useful in situations where the value you are trying to find requires some temporary state or where the logic is complex. As an example of the former I regularly find I need to calculate the smallest difference between two angles. I then have to write multiple entries in an AttributeCreator to do this. If I could write a Python function in the workspace then call it from the Arithmetic Editor I would only need to define one entry in AttributeCreator. This also has the advantage that the function can then be used in multiple places in the workspace without having to redefine that logic each time.Original post about this:https://community.safe.com/s/question/0D54Q000083BN47SAG/is-it-possible-to-add-functions-to-be-available-in-the-arithmetictext-editorLet me know what you think.ThanksMichael
When a job fails and there are a lot of parameters to populate, it would be very handy to have a "Resubmit with Edits" option that lands you in the Run Workspace page and populates all parameters & settings as configured for that job. This would let you make any tweaks/edits before submitting again.
There's a "sorted" option in attribute transformers that doesn't seem to do anything. It would be great to be able to toggle attribute name sorting on and off.
***Note from Migration:*** Original Title was: Named ports of collapsed bookmarks should show up in Data Inspector/Visual Preview If ports of collapsed bookmarks are named it is mandatory that these names are displayed in Data Inspector/Visual Previews "Data Control window" and "Feature Information window". Currently names of underlying Transformers are displayed which causes confusion during inspection.Situation in Workspace:Situation in Data Inspectors "Data Control Window"Situation in Data Inspectors "Feature Information Window"
Currently, when attempting to update workspace published parameter values for an Automation, if the parameters contain any password fields then no parameters can be updated without also re-entering the password values.It would be good if other parameters could be updated without requiring all passwords to be re-entered.If this is not possible then at least the error message could be updated to be something more friendly than the current: "javax.crypto.IllegalBlockSizeException: Data must not be longer than 245 bytes"See these two related postings:https://knowledge.safe.com/questions/93897/javax-error-when-saving-fme-server-automation.html?&childToView=112885#answer-112885 https://knowledge.safe.com/questions/104498/fme-server-automation-error-javaxcryptoillegalbloc.html?smartspace=automations-fme-server
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.
