Return value from GlideRecord.update() with known bad data

[thomaskennedy]

I'm setting up a scripted REST API as part of a replacement for a system that ingests data from a file. The API will receive point updates; we will no longer be ingesting any file. In the file, dates are represented in "MM/dd/YYYY". Of course, we cannot insert a value formatted like that into a GlideRecord date column. So we will ask the sender to update that format so we can insert the value as-is.

But it occurred to me to wonder, "What if they don't?". So I tried my endpoint with a payload whose dates are in the old format.

{
"cancelDate":"07/29/2012",
...
}

In this case I'm updating an existing record. The body gets handled like so:

gr_po.setValue("u_cancel_date", data.cancelDate); // "07/29/2012", this will fail
var sys_id = gr_po.update(); // Should be: null if insert or update fails
var status = sys_id ? 200 : 400; // Should get 400

var responseBody = {};
responseBody.sys_id = sys_id;
response.setStatus(status); // 200
response.setBody(responseBody);

The documentation says GlideRecord.update() returns a null if the update fails. So I expected to get a 400. But I actually get a 200.

The log contains an exception complaining about the bad date format. That's fine, but how do I get the point where I can tell if my GlideRecord update went through or not, so I can report accurately to the caller? I tried adding a catch block; it does nothing as no exception is thrown.

[Tony Chatfield1]

Hi, unfortunately your post is not clear as to your configuration, have you added any debugging to your script to see why you get unexpected results?

If you are using scripted rest api, then why not just manipulate the data to set the correct date format when it is wrong? Also assuming you are loading into a temp data table and then using a transform map to load to your target table, then perhaps the OOB date\time formatting could also resolve your issue?

[thomaskennedy]

Well strictly speaking the result was not unexpected. I knew it would fail to do the insert, and I had a pretty good idea it would return a sys_id (not null as the documentation says) on my call to update(). And of course I can clean up or reject bad data, if I know every way the data can be bad. In this simple case, that would be easy. The question was if some fatal data does get through, how can I tell my insert failed?

[Harish KM]

Hi when you get the date from 3rd party use getByFormat method in servicenow before passing to the field.

Refer this doc below to learn how to convert the date format before setting to field

https://community.servicenow.com/community?id=community_blog&sys_id=bc0e6a2ddbd0dbc01dcaf3231f961931