I currently have a script that POSTs historical data to a Microsoft Azure database using the system.net.httpClient() function.
Is there a way to test the connection prior to attempting to POST? I don't think it hurts anything letting it attempt to POST but was wondering if I should check each time before trying to POST.
I would like to log failed post attempts.
When connectivity to the databases comes back, I would like to retry the failed attempts.
I was thinking I could log the failed attempts to a memory dataset tag. Just logging the POST response code and the timestamp. Maybe deleting it latter if able to POST or using a third column to mark it as POSTed. Memory dataset tags seem to be difficult to work with as they're not meant to be modified. Is it really better to set up a database for this?
I guess not an ongoing connection but that the Azure database can be contacted. Someone had suggested checking before running the rest of the script to get values and attempt to POST. Not sure there would be a lot of benefit over just attempting to POST and getting the response code and if it's bad logging it. I guess you could do a simple GET first to make sure that connectivity to the database is good.
Paul's suggestion to use system.util.getGlobals() will be much easier to work with than a dataset tag, the only downside being its contents won't survive an Ignition Gateway restart.
Not Ignition related, but I have run across a couple of use cases:
The failure takes a long time to return (e.g., network timeout) but there is a fast-fail test (e.g., ping). I've done systems where a fast-fail test was useful before every off-system call. In other cases, the fast-fail test was put in the retry loop so it was only called after a failure and the actual call wasn't attempted again until the test succeeded.
The failure consumes a lot of shared resources (e.g., database timeout) but there is a low-resource-consumption test (generally custom). After a failure, call the low-resource test on retry or restart to try to prevent flapping or a system wide cascade failure.
I would create a local log table with the relevant information needed for the POST with an Uploaded Bool column and a string column for results, datetime, etc.
Where you used to go to do the POST, insert to the table with Uploaded FALSE.
Then have an Upload routine just check that table for any records that Uploaded are FALSE and initialize the POST. (We use a simple SFC for doing this)
On fail of a POST you write the returned error code to the string column and it will just retry it again later.
On successful return of the POST you set Uploaded to TRUE and whatever other information to the string column.
"binary" column types can be confusing, as they are often mistaken for "boolean", which is a different thing entirely. (Boolean => "bit" in some DB brands.)
Binary is expected to hold a string of bits, and there really is not any way to automatically render it.
I'm trying now to get it to convert from the REST POST response timestamp.
