# Logging bad REST API POSTs for later retry **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective, scripting\ **Created:** [August 25, 2023, 7:20pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409 "2023-08-25T19:20:00Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 25, 2023, 7:20pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/1 "2023-08-25T19:20:00Z")
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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 25, 2023, 7:21pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/2 "2023-08-25T19:21:01Z")
> [@r123](#): > > Is there a way to test the connection prior to attempting to POST? What connection? ---
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 25, 2023, 8:41pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/3 "2023-08-25T20:41:13Z")
> [@Kevin.Herron](#): > > 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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 25, 2023, 8:43pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/4 "2023-08-25T20:43:37Z")
Can’t see why that’s preferable to just attempting the post. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 25, 2023, 8:47pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/5 "2023-08-25T20:47:32Z")
> [@r123](#): > > 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? `system.util.getGlobals()`, perhaps? What actionable information do you expect to take from the list of failed attempts? ---
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 25, 2023, 8:47pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/6 "2023-08-25T20:47:33Z")
> [@Kevin.Herron](#): > > Can’t see why that’s preferable to just attempting the post. 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. ---
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 25, 2023, 8:55pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/7 "2023-08-25T20:55:28Z")
> [@paul-griffith](#): > > What actionable information do you expect to take from the list of failed attempts? The hope is to retry them later once the database is again accessible. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 25, 2023, 8:58pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/8 "2023-08-25T20:58:00Z")
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. ---
**Author:** ![Tim\_Carlton](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tim_carlton/32/52835_2.png) [@Tim\_Carlton](https://forum.inductiveautomation.com/u/Tim_Carlton)\ **Post date:** [August 28, 2023, 1:54pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/9 "2023-08-28T13:54:13Z")
> [@Kevin.Herron](#): > > Can’t see why that’s preferable to just attempting the post. 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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 28, 2023, 1:58pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/10 "2023-08-28T13:58:23Z")
In general, fine. But this isn't that. ---
**Author:** ![MMaynard](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mmaynard/32/3366_2.png) [@MMaynard](https://forum.inductiveautomation.com/u/MMaynard)\ **Post date:** [August 28, 2023, 2:24pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/11 "2023-08-28T14:24:46Z")
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. ---
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 28, 2023, 7:07pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/12 "2023-08-28T19:07:22Z")
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. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/5/95946f974de053c6ef80090f00ad0ba97b41c8b2.png) I'd like the Boolean to show true/false or something else and the timestamp to look like one people can read. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/d/cde9546c978ebdeff2f3262701c9788e40e52e2b.png) I tried setting them in the columns settings but they don't seem to effect them. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/9/5912d6756387a43642094231036e57aa1e55b03c.png) ---
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 28, 2023, 7:11pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/13 "2023-08-28T19:11:27Z")
Needed the field set. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 28, 2023, 7:35pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/14 "2023-08-28T19:35:40Z")
It also looked like you were mixing epoch milliseconds with epoch seconds in the data. ---
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 28, 2023, 8:30pm UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/15 "2023-08-28T20:30:18Z")
It's always something. 🙂 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. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/1/a1c52b464e88c84813d2d959075200dcd0fc77a1.png) ---
**Author:** ![r123](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@r123](https://forum.inductiveautomation.com/u/r123)\ **Post date:** [August 29, 2023, 1:46am UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/16 "2023-08-29T01:46:32Z")
> [@r123](#): > > 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. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/5/d51b4c75248b1b293b456aff700b3613cd7405bb.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/8/18a6e30e376c49689f112d5d3f29a7043b184dff.png) 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 | ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 29, 2023, 11:45am UTC](https://forum.inductiveautomation.com/t/logging-bad-rest-api-posts-for-later-retry/78409/17 "2023-08-29T11:45:25Z")
"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.