Currently, as most people are doing, we would write EAI code that would immediately attempt to insert/update data on a DB table and if there are any connectivity errors, the errors would go to myWebmethods whereas after the DB connectivity is fixed, the failures could be resubmitted.
We are attempting to change our approach on that. It is really getting out of hand over here, because a lot of our customers don’t tell us when they intentionally bring their servers/db down and it badly affects us in terms of hundreds (and potentially thousands) of failures. I feel that we need to start writing our EAI code so that we test the db connectivity first , then if successful, move on with trying to do inserts and / or updates. I believe that I have something in place that will be able to do that, as I understand that in order to test DB connectivity, I would need to first run something like this “SELECT sysdate FROM dual” which returns a date/timestamp. If I get back a date, then DB connectivity is good. Otherwise, it’s bad.
Can you guys give me some ideas on what should be attempted on testing things outside of DB connectivity, such as best approach when calling and testing http url link before trying to send data to that link, calling a ftp server (although I think testing if I can login is good enough), and writing any file (text/xml/csv…) to an (non-ftp) external server’s fileshare directory? Do a ping type service on the server first?
Is anyone else doing the above approach regularly? Working out better?