Skip to main content

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

4500 Ideas

kathyross
Participant
kathyrossParticipant

FME Flow Jobs Completed Sub Name / ParameterNew

FME Flow currently has columns in the Jobs Completed screen like the workspace, source, date/time, engine, etc.What happens for bulk dynamic data replication is you need to run the same fmw multiple times with differing parameters. e.g. a SQL Server to SHP Downloader that runs on a single table at a time.Whilst yes you COULD run the workspace only once (reading hundreds of thousands of features), this not only adversely and unnecessarily affects server resources but means a single error affects all data. Instead, it’s best to run the workspace multiple times (once per SQL Server table) via say a FMEFlowJobSubmitter.In FME Flow this means you get the Jobs screen full of hundreds of the same workspace with a differing date. There’s no way to tell at a glance what parameters caused the 10 out of 200 jobs of the same workspace to fail.I’d like to see a parameter exposed in the Jobs screen so that I can see at a glance that Table ABC and XYZ failed. Not that Workspace123 failed 10 times with unknown parameters. Yes, I’m aware you can click into each job manually and that yes we could setup a log-reader workspace to do this. Or that we could setup a postprocessing task. I have setup such before - but it’d be nice out-of-the-box in the Jobs screen.This could be a standard parameter or a FME Flow parameter that can be set by the author (e.g. linked to a Published Parameter).Thanks.

Terminator improvementsGathering Interest

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...?