gr.update not working, though logs show that update had occurred successfully after discovery?

[RyanM890]

I have a BR that is running during discovery, where I have added a field to discovery schedules for environment, which should be able to map the created CI environment based on following this post. https://community.servicenow.com/community?id=community_question&sys_id=e0525761db101fc01dcaf3231f96192a

through logging, I can confirm that my code SAYS that the gliderecord I am using has the environment field correctly mapped/set after the gr.update(), but when looking at the created CI, I see that environment is still null. Does anyone know why this would be happening? I have all the right data based on my code, but it does not seem to save to the cmdb_ci record, even though my logging says it was updated correctly.

My Code below:
(function executeRule(current, previous /*null when async*/) {


// Add your code here
var grCi = new GlideRecord(current.classified_as); //base ci table

if(grCi.get(current.cmdb_ci)){

//gr.setValue("environment", current.status.dscheduler.u_environment.getValue());
grCi.environment = current.status.dscheduler.u_environment;
gs.info(grCi.name + " environment value: " + grCi.environment);
}
grCi.update();
gs.info(grCi.name + " environment value: " + grCi.environment);

})(current, previous);

[Tony Chatfield1]

Hi, grCi.update(); is outside of your if(grCi.get(current.cmdb_ci)) condition check

So you will always 'update' regardless of whether your glidequery 'get' is actually mapping\returning a valid record - It may be that current.cmdb_ci is not a 'string' sys_id and so there is no matched record?

I would suggest you move your update() method into your if statement, so it is called only when the if condition is entered IE when you have a record to update.
Would also recommend that you add some logging\debugging to validate the 'typeof' and content of current.cmdb_ci and to confirm that the 'if' statement is entered\the condition match is true.

[RyanM890]

sorry, I should have clarified, I followed the exact KB I linked above and I had the code below as the original code: 

(function executeRule(current, previous /*null when async*/) {

// Add your code here
var grCi = new GlideRecord(current.classified_as); //base ci table

if(grCi.get(current.cmdb_ci)){

//grCi.setValue("environment", current.status.dscheduler.u_environment.toString());
grCi.environment = current.status.dscheduler.u_environment;
grCi.update();

gs.info(grCi.name + " environment value: " + grCi.environment);
}

})(current, previous);

It was nested in my if statement originally and as I mentioned I can confirm though gs.info (I have done several iterations of gs.info throughout this script to test) that all the variables work and that before we set grCI.environment to the u_environment, I can confirm that grCI.environment is equal to null prior. After that it gets the correct value from u_environment but the record does not reflect that change after the update.

[Tony Chatfield1]

If your script logging shows that the value is set correctly, then it is possible that
the update is being overwritten by another BR, workflow etc
or that the update is not applied because ACL or mandatory field requirements are not met.

Have you checked your logs to see if they have any additional information?

[RyanM890]

yes, I looked at the logs but there is nothing standing out as to why this would be prevented. Looking at the history, it appears that it was never set on any of these. so it seems like grCi.environment is being stored in the variable and printed out in the gs.info statement, while gr.update is not working, unless another BR is running afterwards to wipe this. I have looked through the table of Business Rules and nothing has stood out as this culprit