Let's play a little Game - what will this code do?

[Daniel Oderbolz]

As an ex-DB guy, I am always interested to see how ServiceNow works under the hood.

Therefore, I did a little experiment on my PDI.

First I created a table called u_device with a single mandatory field u_imei:

And then I opened "Scripts - Background" and entered this simple script:

try {
    var nRecords = 100;
    var grDevice = new GlideRecord('u_device');
   grDevice.setUseEngines(false);

    for (var i = 0; i < nRecords; i++) {
        grDevice.newRecord();
        grDevice.insert();
    }

} catch (error) {
    gs.logError("Error in script:", error);
}

What will this script do?

As expected, it inserts 100 records even tough I did not tell it a value for u_imei - since I switched off Data Policies using .setUseEngines(false) - or so I thought.

Then I went back to the script an executed:

try {
    var nRecords = 100;
    var grDevice = new GlideRecord('u_device');

    for (var i = 0; i < nRecords; i++) {
        grDevice.newRecord();
        grDevice.insert();
    }

} catch (error) {
    gs.logError("Error in script:", error);
}

What will this script do?

In contrast to what I and probably also you thought, it did not raise an exception, but it inserted the empty values just fine!

Honestly, that this is the case (note that the build tag of the instance is "glide-yokohama-12-18-2024__patch5-06-11-2025") astonished me quite a bit.

(If you ask Database Administrators, they will tell you that NOT NULL CONSTRAINT is one of the more important aspects of any decent database).

It seems that a mandatory field (set at data dictionary level is)

• Not Implemented as a NOT NULL CONSTRAINT (that I already knew)
• Not Implemented as a Data Policy (that was completely new for me)
• Only enforced in the UI

This means that it is a good idea to perform a check of all the fields that are set to mandatory (in my PDI, we are talking about 11k records):

https://instance.service-now.com/sys_dictionary_list.do?sysparm_query=mandatory%3Dtrue&sysparm_first...

I bet that you will find many records that are in fact null (use the ISEMPTY operator).

I can see why ServiceNow does not use a NOT NULL CONSTRAINT (these cannot be disabled on a per-transaction level) but why is this not a Data Policy?

What are your toughts on this?

[Chinmay Tawade1]

Hi Daniel,

I tried this on my PDI as well on Incident form.

Yes it does not raise any exceptions for mandatory fields, which is strange to me, usually it should have invoked Not Null Constraint.

I created a Data Policy on Caller and then it throwed "Data Policy Exception".

Definitely this working feels strange for one who has worked on DB before.

Regards,

Chinmay Tawade

LinkedIn 

[Daniel Madsen]

Hi Daniel

It is an interesting experiment, and thank you for sharing it. I have also been surprised in my years with ServiceNow to see records exist that, to my knowledge, should not exist, as they didn't seem to respect the configurations set up in the platform. It is however possible to disable some of these rules, and from my personal experience, I've seen it happen most often when it comes to integration data. I have, however, also seen solutions outside of the ServiceNow space where referential integrety was disabled during bulkloads, which is similar to what we are seeing here.

Best Regards

Daniel Madsen

[Daniel Oderbolz]

Hi @Daniel Madsen & @Chinmay Tawade1 
Thanks for your swift reactions!
I think that for any database professional, it is quite important to realize that ServiceNow uses the database as a "dumb" backend and does not use many features that they may take for granted.

Just a comment on turning off referential integrity during load - yes this is being done, but it is then turned on again. If this fails due to inconsistencies, the imported data is rolled back.
In ServiceNow we have no way of turning it on again (unless you disable/enable a data policy) and no mechanism to create transactions (let alone for rollback).