When a FeatureWriter fails for whatever reason, is the expected outcome that nothing is output from any of the ports, even if some or all other feature types are successful? In my example I have 2 feature types in a FeatureWriter and 1 of the 2 writes successfully, the other fails (I’ve forced it to fail to test this functionality). I want to be able to take the information from the successfully-written feature type further in the workspace for processing. Is this not possible? Currently I’ve resorted to 40 separate FeatureWriters for 40 different feature types in case 1 of them fails and the other 39 are successful. I do have Rejected Feature Handling set to Continue Translation. This is FME 2024.1.1.1 (B23620).
Below is my example. The 312 features for for the one feature type successfully write to my database (ArcSDE GeoDB). I’m ok that the Translation Failed and is actually a good thing, I just want to use the summary and feature counts to write to log tables further along in the translation.
Any advise or thoughts are appreciated.
Thanks
Page 1 / 1
You can possibly achieve this by setting the FeatureWriter into Group Processing Mode. With Group By set to the Feature Class/Table name (Add an Attribute to the Features with this value if it does not already exist). This will cause FeatureWriter to execute each Feature Class / Table Write independently, and likely will then output on the Summary Port for each successful Group write.
Eg. Similarly induced failure here on Feature Class B, and we get on the Summary Port that only Feature Class A wrote.
Summary Port
There is an important “but” here: a FeatureWriter will stop writing once it fails. If for instance, the first Feature Class Group caused a Transformer Failure, then it won’t try to write the second, third etc. Feature Class, even if those Feature Class Groups are valid.
To be honest I would not generally allow a FeatureWriter to fail and to continue translation as a “good” Workspace design. It is a better Workspace design to instead build the logic that filters for failing Features before they enter a Writer, and handle these separately Eg. Send to the an Inspector, or use them in a logic gate transformer arrangement (or say a Terminator) for any further downstream Transformers.
Thanks @bwn .
Appreciate the insight and what you’ve proposed makes sense as it does answer my question about the summary output when the FeatureWriter fails.
For my workspace purposes, however, I’ve ended up using individual Feature Writers per feature type as I want all other feature types to write successfully if one fails. The success or failure of each feature type dictates what is done with it in downstream processing.
In testing this more, does a failed FeatureWriter fail/end the entire workspace run at that time? I have developed a workspace with numerous FeatureWriters with the intention that if one fails, the rest will still run. This worked a few times but I think that was due to the order in which the successful FeatureWriters happened to complete, prior to the failed one.
Does anyone have a thought on a workspace with multiple feature types to write, and for each feature type I want to write additional information given a successful outcome of said write - update a history table and log results, ONLY if that feature type wrote successfully?
