Logging bad REST API POSTs for later retry

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?

What connection?

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.

Can’t see why that’s preferable to just attempting the post.

1 Like

system.util.getGlobals(), perhaps?
What actionable information do you expect to take from the list of failed attempts?

I was thinking the same.

What about keeping an up to date log or list of failed POSTs? Just try and make a memory dataset work or is there a better way?

That was another reason for wanting a simple test but again I guess once I get a good POST code I can then try to run through a list of bad POSTs.

The hope is to retry them later once the database is again accessible.

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.
1 Like

In general, fine. But this isn't that.


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.


I'm sure this something simple by why can I not get the Perspective table to show the column format selected?

At least it looks like a timestamp in development.

I'd like the Boolean to show true/false or something else and the timestamp to look like one people can read.


I tried setting them in the columns settings but they don't seem to effect them.

Needed the field set.

It also looked like you were mixing epoch milliseconds with epoch seconds in the data.

It's always something. :slight_smile: I'm trying now to get it to convert from the REST POST response timestamp.

It also don't seem to like the Boolean, as true or false it shows a check.

Still can't see why it always shows checked. If I change the columns render to number then I get to see the correct values.


In SSMS they look like this and are set as binary data type.

POST_Code rePOSTed POST_timestamp
401 0x00 2023-08-28 20:22:45.537
408 0x00 2033-07-10 03:24:37.000
409 0x00 2033-07-10 03:24:37.000
10000 0x00 2033-07-10 03:24:37.000
111111 0x01 2033-07-10 03:24:37.000

"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.