You can have fme terminate if a feature is sent through a rejected/invalid port.

Warnings will be a little harder to deal with and most of them can be safely ignored, and are hard to test for in advance.

I would suggest writing to a temporary location, then analysing the log file and if there are no issues then move/copy the files to the permanent location. If it's a database format, I would create a staging table/db.

You can run the process and have a second process check the .log file. Then write the data if the log file passes the test.

@david.bondy​ FME doesn't differentiate between system warnings (i.e. feature cache is on) and data processing warnings. So it would be hard to process a log file and determine if a WARN should terminate your workflow. ERROR messages are a little more reliable on that front. To do that, you could use the FeatureWriter and then scan the log file as @jlbaker2779​ suggests.

I think we would recommend taking a more granular approach and track rejected ports as suggested by @jdh​ You could disable your writers and then run the workspace. If there are no errors, you can then run the workspace with the writers enabled.

But, I'm not sure you can really isolate the writers, since errors and warnings are often generated by the writers themselves. This raises the question of how do you recover when a writer generates warnings and errors, and you don't want the data written if a problem is encountered. For file formats this is easier, you just write to a temporary folder and if everything is OK you just copy the files to the correct location.

Things are harder if you are writing to a database. There are a couple of possible strategies:

• use a very large transaction interval. If there is an error then the entire transaction can be rolled back - this can cause issues with temp space on some databases
• writer to staging tables and if the write is successful then move the staging table to the final table location.