To provide high availability of data, client is having two data servers. We need to check for existing database connection failure in FME Work flow and pull data from backup data server. If there is no failure at 1st connection, then no need to proceed for backup server. Is there any possibility for this king of approach in FME?
+53
I would try and use a FeatureReader (Initiated by a Creator) reading from the first connection. Then a NoFeaturesTester, if no output use a second FeatureReader with the second connection. Rejected Feature Handling should be set to Continue Translation. You can set this in the Navigator, under workspace parameters, translation.
+31- Influencer
nielsgerrits wrote:
I would try and use a FeatureReader (Initiated by a Creator) reading from the first connection. Then a NoFeaturesTester, if no output use a second FeatureReader with the second connection. Rejected Feature Handling should be set to Continue Translation. You can set this in the Navigator, under workspace parameters, translation.
If using a FeatureReader you can just initiate a second FeatureReader from the rejected port in the event of database connection failure
+51- Celebrity
How are you ensuring data is the same across the two databases?
A more robust approach would be to setup the servers in High Availability and have the failover at the database level rather than relying on the clients to switch over in the event of an outage
+51- Celebrity
nielsgerrits wrote:
I would try and use a FeatureReader (Initiated by a Creator) reading from the first connection. Then a NoFeaturesTester, if no output use a second FeatureReader with the second connection. Rejected Feature Handling should be set to Continue Translation. You can set this in the Navigator, under workspace parameters, translation.
A question on this approach is what constitutes a failure on the first reader?
- if you get no features returned, is that because the DB failed internally, or an SQL statement returns no features?
- What if it times out? is that because the database is down/running slow, or there is just a lot of data
- Obviously a failed to connect/rejected output is valid failure
+2- Participant
hkingsbury wrote:
How are you ensuring data is the same across the two databases?
A more robust approach would be to setup the servers in High Availability and have the failover at the database level rather than relying on the clients to switch over in the event of an outage
Client is maintaining that for high availability. So we are assured by customer that data is same on both servers.
+2- Participant
ebygomm wrote:
If using a FeatureReader you can just initiate a second FeatureReader from the rejected port in the event of database connection failure
Thanks for a simple and clear answer.
+2- Participant
hkingsbury wrote:
A question on this approach is what constitutes a failure on the first reader?
- if you get no features returned, is that because the DB failed internally, or an SQL statement returns no features?
- What if it times out? is that because the database is down/running slow, or there is just a lot of data
- Obviously a failed to connect/rejected output is valid failure
Thanks for detailing on many possible cases.
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.