I have 2 different (postgis) writers (A and B), one of which is sometimes temporary not accessible. FME checks at the start if all writers (A and B) are accessible, and if not, fails to execute the workbench.
So I wonder if it is possible (e.g. by the use of a parameter specifying which (only) writer to use) to bypass the "accessibility-check" of e.g. writer A so that only writer B is being used and the workbench is still being executed?
I use this in a batch-script where I "ping" to A and B, and therefore know at the start whether A and/or B are accessible.
Best answer by ebygomm
Well, probably not specifically on start up, but (I think) it first tries to perform to write 1 feature to (all) writers (and quits or not, according the "Ignored failed readers"-parameter). But in order to write to a (database)writer 1) you have to have access to the (location of the) database (ip-connection) and 2) you have to have acces (authorised, database not locked etc) to the database. It looks now that if 1) fails it is enough to stop the workbench no matter the "Ignored failed readers"-parameter.
The check is not upfront so you can just check whether the database is accessible in your workspace and then stop features from hitting the writer if the database isn't accessible. I'd test just using a simple Select 1 statement in an SQLcreator and then use that result to determine the flow of features in the workflow
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
If you switch to FeatureWriters instead of standard writers I think you'll be able to handle the failure via the rejected port so the workspace will still complete.
I've just realised the FeatureWriter doesn't have a rejected port, was thinking of a FeatureReader
It might also work to change the parameter "Ignored failed readers" to yes?
Tried this one, but it failed. I think because there's no ip-connection to the database and thus FME cannot "check" if it can write to the database. It probably will work if there is a connection, but the write fails. Thanks for the tip anyway, cause I had not noticed this parameter before!!
If it's not something that happens on startup there should be a way of handling it in the workspace
Well, probably not specifically on start up, but (I think) it first tries to perform to write 1 feature to (all) writers (and quits or not, according the "Ignored failed readers"-parameter). But in order to write to a (database)writer 1) you have to have access to the (location of the) database (ip-connection) and 2) you have to have acces (authorised, database not locked etc) to the database. It looks now that if 1) fails it is enough to stop the workbench no matter the "Ignored failed readers"-parameter.
Well, probably not specifically on start up, but (I think) it first tries to perform to write 1 feature to (all) writers (and quits or not, according the "Ignored failed readers"-parameter). But in order to write to a (database)writer 1) you have to have access to the (location of the) database (ip-connection) and 2) you have to have acces (authorised, database not locked etc) to the database. It looks now that if 1) fails it is enough to stop the workbench no matter the "Ignored failed readers"-parameter.
The check is not upfront so you can just check whether the database is accessible in your workspace and then stop features from hitting the writer if the database isn't accessible. I'd test just using a simple Select 1 statement in an SQLcreator and then use that result to determine the flow of features in the workflow
Well, probably not specifically on start up, but (I think) it first tries to perform to write 1 feature to (all) writers (and quits or not, according the "Ignored failed readers"-parameter). But in order to write to a (database)writer 1) you have to have access to the (location of the) database (ip-connection) and 2) you have to have acces (authorised, database not locked etc) to the database. It looks now that if 1) fails it is enough to stop the workbench no matter the "Ignored failed readers"-parameter.