question Re: If Statement in Transform Script in Developer forum

If Statement in Transform Script

martin_kohler — Fri, 09 Jun 2017 09:47:01 GMT

Hi,

I am struggeling with a transform script and I hope you can help me. The situation is that during an LDAP consolidation project two different LDAPs need to be imported into ServiceNow. The only possible coalesce attribute is email, however some accounts from the old LDAP should not be overwritten by the new LDAP import. All records that only exist in the new LDAP should, always be updated. I added a new attribute "LDAP_tempuser" to identify accounts that should be overwritten and I set up the following onBefore script to restrict the update process:

if (action == "update" && target.ldap_server != "newLDAP" && target.u_ldap_tempuser == false) {
   ignore = true;
}

My expectation is that:

If all conditions within the if clause are fulfilled, the record is ignored
If any of the conditions within the if clause is not fulfilled, the existing record is updated

However, the transform ignores all records, regardless of the if statement above and I cannot see why. Any ideas?

The attached screenshot shows the intended logical flow if that helps.

Thanks in advance for your help!

Re: If Statement in Transform Script

James_Neale — Fri, 09 Jun 2017 10:24:51 GMT

Hey Martin,

target.ldap_server is a reference field so "newLDAP" actually needs to be the sys_id of the newLDAP server you have created.

var ldap_server = "32424a11dbba22002686da94ce96194b"; // newLDAP

if (action == "update" && target.ldap_server != ldap_server && target.u_ldap_tempuser == false) {

   ignore = true;

}

Right now, nothing is being inserted because that field would never equal "newLDAP".

Cheers,

James

Re: If Statement in Transform Script

martin_kohler — Fri, 09 Jun 2017 11:05:09 GMT

Hi,

thank you for your reply. Sorry, I should have mentioned that "newLDAP" was just anonymized for the string value of the actual LDAP server name of the new LDAP server. Does it have to be the sys_id or can it also be the string value?

And even if i take the LDAP server condition out of the if statement and just have

if (action == "update" && target.u_ldap_tempuser == false) {

   ignore = true;

}

the records are still ignored instead of updated. So I was wondering if the && operators within if statements of transform scripts are generally possible.

I also tried to create the new variable "ldap_server" with the sys_id and include that instead of the string value in the script but still no change. All records are ignored by the onBefore Script.

Thanks and kind regards,

Martin

Re: If Statement in Transform Script

vinothkumar — Fri, 09 Jun 2017 11:15:18 GMT

Hello Martin,

Have you checked the transform logs, there you will find the reason why it is being ignored.

Re: If Statement in Transform Script

martin_kohler — Fri, 09 Jun 2017 11:27:48 GMT

Hello,

thank you for your reply. The transform history shows that one record was ignored. In the corresponding log entries in the related list, there is nothing about "ignore". Or am I looking at the wrong place for the log?

Kind regards

Re: If Statement in Transform Script

vinothkumar — Fri, 09 Jun 2017 11:35:52 GMT

Hello Martin,

Navigate to the import set and open the import set that you have recently opened and in the bottom of the form, you will get import set record, there you can check in the comments

Re: If Statement in Transform Script

martin_kohler — Fri, 09 Jun 2017 11:43:45 GMT

Thank you. It says "Row transform ignored by onBefore script". As the onBefore script I posted above is the only onBefore Script, something is wrong there. Any ideas?

Re: If Statement in Transform Script

vinothkumar — Fri, 09 Jun 2017 11:58:35 GMT

Hi Martin,

Sorry, I don't see any wrong in your before transform map.

May be both the condition are satisified , so why ignored. To ensure put gs.log for the both the values.

if (action == "update" && target.u_ldap_tempuser == false) {

ignore = true;

}

Re: If Statement in Transform Script

martin_kohler — Sun, 11 Jun 2017 06:51:39 GMT

Thanks James! I tried again by changing to the sys_id of the LDAP server and it worked now!