Skip to main content

Open ideas have been reviewed by our Product Management and are open for commenting and voting.

Filter by idea status

Filter by product area

4512 Ideas

mel
Contributor
melContributor

Dynamic SQLExecutor and FeatureReader that returns all attributesOpen

This question has been asked so many times and is ridiculously confusing and hard for something that should have been added ages ago. I have a table that has table or layer names that I want to process in FME. I should be able to Dynamic SQLExecutor or FeatureReader to read the list and add them in to form without having to know the schema ahead of time. The issue is the schema they read comes from the input table and not the features it reads. The attributes are returned so you can write them with a dynamic writer, you just can see or use them in form. It needs the ability to dynamically return a value as defined in the source table (for example the @layerID or allow a wildcard to return all fields) and the fme_feature_type, fme_basename and fme_dataset not from the initiator but from the dynamically read table/layers. In this case I have the layer/table name and the ID I want to expose in the initiator table there just doesn’t seem to be a way get the attributes to dynamically read from the imitator table or to just dynamically read all attributes back.fme_attributes should come from the feature it is reading not the initiator, same with the schema it should be the schema of the feature it is reading not the initiatorIt can read the list of tables in but cannot read the attribute I want dynamically. For example, when it reads TRAILSIGNS the attribute I want returned is TRAILSIGNID  

Terminator improvementsIn Development

Some general improvements for the Terminator transformer I am thinking of:The ability to terminate with a FME_FAILURE or ABORTED or maybe even a new TERMINATED status (relevant for Server). An FME_FAILURE happens when FME crashes or experiences some other problem (e.g. missing transformer). When the Terminator caused the workspace to quit, this typically happens because of a "user handled exception", which might also be interpreted as a cancellation, but now it's always FME_FAILURE as well. Either way, it gives me better insight in what went wrong if this status type could be changed.The ability to set custom data that should be sent upon failure, which can then be used as the "Data To Post" for notification topics. Upon failure, nothing gets written to the "Data To Post" writer, but it would be nice if we could at least get something back. In this case, that would be the custom data that was set in the Terminator.I would like the error message that I specified in the Terminator to stay exactly the way it is. When a job terminates on Server, it passes the Termination Message on to the statusMessage attribute from the job result. Just like in workbench, it always prefixes this message with "<Transformer Name>: Aborting Translation as directed by mapping file. Message is ...". I would love to see that prefix removed, because now I need to remove it myself since it is confusing to an end user who is not familiar with FME. Might as well officially integrate the functionality of the MessageLogger by 1Spatial.Any other suggestions...?