• EN
Solved

Bypass access-check of some writers at the start of a workbench

  • 16 August 2022
  • 8 replies
  • 0 views
hanskoudijs
Badge

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.

icon

Best answer by ebygomm 16 August 2022, 11:48

View original

8 replies

ebygomm
Rank
Userlevel 1
Badge +21

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

 

https://community.safe.com/s/bridea/a0r4Q00000HbqeEQAR/ignore-failed-writers

sigtill
Rank
Badge +21

It might also work to change the parameter "Ignored failed readers" to yes?

image

The real SigTill
hanskoudijs
Badge

It might also work to change the parameter "Ignored failed readers" to yes?

image

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!!

ebygomm
Rank
Userlevel 1
Badge +21

I'm surprised that you say this check is happening at the beginning of the workspace, as in my experience that doesn't happen. See

 

https://community.safe.com/s/bridea/a0r4Q00000HbqcWQAR/check-writer-accessibility-when-a-workspace-is-started

 

If it's not something that happens on startup there should be a way of handling it in the workspace

hanskoudijs
Badge

I'm surprised that you say this check is happening at the beginning of the workspace, as in my experience that doesn't happen. See

 

https://community.safe.com/s/bridea/a0r4Q00000HbqcWQAR/check-writer-accessibility-when-a-workspace-is-started

 

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.

ebygomm
Rank
Userlevel 1
Badge +21

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

hanskoudijs
Badge

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.

Tried it that way, with SUCCESS!!!

Thanks very much 💪 👍

hanskoudijs
Badge

It might also work to change the parameter "Ignored failed readers" to yes?

image

ebygomm's answer does the tric. Thanks anyway sigtill 👍

Reply


Community Stats

28,802
Posts
109,796
Replies
36,633
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.