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...?
When a child workspace fails due to a terminator, the failure status message returned to the workspaceRunner/ServerJobSubmitter is `A fatal error has occurred. Check the logfile above for details'.
I would much rather get the message from the terminator.Yes, I noticed that too. In asynchronous mode however (so if you not wait for the job to complete), it does return the error message you specified in the Terminator (along with that prefix I mentioned above).
Add a string at the end of the translation that contains the value of "Hasta la vista, baby" ... and for every transformer do one that says "Auto bots, roll out!".
It might also be a good idea if a (custom) error code could be set by the Terminator that can be fetched in the job result (e.g. in an errorCode attribute). That way, the actual message is basically irrelevant, as the FME developer can then display a custom (localized) message to the end user based upon that code.
I've got a parent Workspace sending 2 Excel file names at a time to a child Workspace. In the child Workspace, the 2 files are read with separate FeatureReaders, then there's an AttributeValidator that checks if the Excel file has the expected column headings. If it doesn't, the Workspace is terminated. In the parent Workspace log, I'd like to be able to differentiate between the child Workspace terminating because of the AttributeValidator or something else.I really agree, this would be extremely useful for developing nice behaving workspaces to be executed by people that may not be FME developers.
Especially "The ability to set custom data that should be sent upon failure" sounds really interesting. This could be very helpful to create custom error messages for applications calling FME. Currently, I'm using a second workspace evaluating the job log in order to do that.
An option to have a Terminated status instead of the generic FME_FAILURE status in FME Server would be really helpful, under certain circumstances I want to stop the process, but that is intentional and not a failure
Has there been any update on how to provide more information in the RESULT DATA window on fme server? I currently only get FMEL_FAILURE and A fatal error has occured. Check the logfile above for more details. Would like for the message from the terminator or logger to be wieved here.
The terminator certainly needs a few different statuses (success, abort, failure etc), because we may terminate for a range of reasons and the level that we care about that specific termination varies. For instance, I have terminators in an automation and some terminate because the process should not run because of some specific factor or it may terminate because the data is not correct. Any termination immediately comes out the failure port and recorded in the automation log, but I may only want this for a data issue and not for a specific factor. I may instead want it to come out of the success port, or no port at all.
I would like to second the ability for the terminator output a success message for automation, In order for the automation application to continue as if the workspace succeeded normally. I would also like for the transformer to be able to function as: normal, blocking or lowest priority.
Normal: as it works now, when a feature enters the terminator activates
Blocking: Features can only enter when all upstream transformers have finished, such as a merger
Lowest priority: Features can only enter when all other transformers have no available tasks.
Currently I am working on a workspace that finishes everything within the workspace, but gives no completion signal to the automation application(Neuron), to force the WS to finish I use a transformer. Which I made blocking through a samper, and (simulated) lowest priority through a decelerator. After which it has performed its job, but will still give a failed message to Neuron.
Ideally I can make it so that everything else in the workspace has completed before the terminator can be activated, at which point the workspace is terminated with a succes message to Neuron.