Mark Roethof
Tera Patron
Tera Patron

Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

 

Hi there,

 

It's hard to have missed it, the greater part of Xanadu related content by people is ECMAScript 2021 (ES12) mode in individual script and with that also for the Global scope. There is an undocumented catch no one is sharing though... the toggle for "Turn on ECMAScript 2021 (ES12) mode" is not stored within the record concerned. That is interesting knowledge, though also a good need to know!

 

Let's have a closer look.

 

Tokyo: ECMAScript 2021 (ES12) for Scoped Applications 

With the Tokyo release, ServiceNow brought a major update to the JavaScript language available. Not by default, though for Scoped Applications developers have the option to choose the JavaScript mode. JavaScript mode option ES5 (Helsinki) and ES21 (Tokyo).

 

es12_01.png

 

Xanadu: ECMAScript 2021 (ES12) mode in individual script

With the Xanadu release, ServiceNow has made ECMAScript 2021 (ES12) mode available for individual scripts and with that also for the Global scope! Basically on every individual script field  for applications that use ES5 mode (or Compatibility mode), above the script field a toggle "Turn on ECMAScript 2021 (ES12) mode" will be visible. When the toggle is green, ECMAScript 2021 is turned on.

 

es12_02.png

 

ES Latest Scripts (sys_es_latest_script)

When you use the toggle to turn ECMAScript 2021 on or off, where is it stored though? Looking at records with a script field, there's no field indicating storing the toggle value. See here an example of the Fix Script table and its fields. Nothing to see about the toggle value for ECMAScript 2021.

 

es12_03.png

 

Looking into the XML of a Fix Script though (in an instance, not an exported XML!), we do notice something with "es_latest_script".

 

es12_04.png

 

The more experienced ServiceNow people know enough with the previous image. "sys_es_latest_script" is a table name and it's own sys_id is mentioned. So ServiceNow choose to store the toggle value for ECMAScript 2021 in a new table. A bit similar like what you might have seen on different places in any instance, like with price fields. 

 

Here an example of a record in the new "ES Latest Scripts" table [sys_es_latest_script]. The table basically contains the sys_id of the target record, the table of the target record, and a true/false field that represents if the ECMAScript 2021 toggle is on or off.

 

es12_05.png

 

Food for thought

So why is it interesting to share this small piece of undocumented knowledge on ECMAScript 2021 (ES12) mode in individual script? This article is not just for fun and to document the undocumented 😀. In most cases, you won't need to know of the new ES Latest Scripts table, though there are a few situations you do want to know of this!

 

I'll share two situations. Maybe you can come up with more, do share in the comments!

 

1) When working on records with a script field, and wanting to do something with the value of the ECMA2021 toggle (updating it, reporting on it)... you would need to do so against the ES Latests Scripts table.

 

2) The value of the ECMA2021 toggle on a record is not exported via XML export. When importing the XML file on a different instance for example, the value of the ECMA2021 toggle will always be false as it is not part of the XML export. This might brake scripting where the value of the ECMA2021 toggle was set to true!

 

The XML export feature is designed to work for exporting records from a table as is (raw data), without dependents such as the value of the ECMA2021 toggle.

 

This behavior is as intended.

 

Also read this ServiceNow Support article that is on Currency type fields, which have a similar structure.

---

 

That's it. Hope you like it. If any questions or remarks, let me know!

 

C

If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.

 

Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in?
- Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

 

Kind regards,


Mark Roethof

Independent ServiceNow Consultant
9x ServiceNow MVP

---

LinkedIn

Comments
NToo
Tera Contributor

Thank you Mark, really useful post.

ashwini J4
Tera Explorer

@Mark Roethof  If we get an error while moving update sets from one instance to another, what should we do?

For example, if the Dev instance is upgraded to the Xanadu version while the Stage instance is still on the Vancouver version, and an error message appears, such as "Table sys_es_latest_script doesn't exist" during the commit of the update sets, should we ignore the error? Please suggest what actions we need to take.

ashwini J4
Tera Explorer

If we get an error while moving update sets from one instance to another, what should we do?

For example, if the Dev instance is upgraded to the Xanadu version while the Stage instance is still on the Vancouver version, and an error message appears, such as "Table sys_es_latest_script doesn't exist" during the commit of the update sets, should we ignore the error? Please suggest what actions we need to take.

NToo
Tera Contributor

@ashwini J4 I've not come across any issues so far in ignoring that error

traceymcknight
Tera Contributor

We are experiencing same issue - If we get an error while moving update sets from one instance to another, what should we do?

For example, if the Dev instance is upgraded to the Xanadu version while the Stage instance is still on the Washington version, and an error message appears, such as "Table sys_es_latest_script doesn't exist" during the commit of the update sets, should we ignore the error? Please suggest what actions we need to take.

arijtis
Tera Expert

I am experiencing the same issue - If we get an error while moving update sets from one instance to another, what should we do?

For example, if the Dev instance is upgraded to the Xanadu version while the Stage instance is still on the Washington version, and an error message appears, such as "Table sys_es_latest_script doesn't exist" during the commit of the update sets, should we ignore the error? Please suggest what actions we need to take.

nebula
Tera Guru

We ran into this table on our skipped records review for Xanadu. Thanks for a great explanation!

James Fricker
Tera Guru

As of Xanadu patch 5 this switch does not work for global scope fix scripts

James Bustard
Tera Contributor

We're getting an odd error seemingly related to this when we push code from one instance to another using Team Dashboard.

 

We cloned an instance on Xanadu, did some dev work on the cloned instance, and while pushing the code using Team Dashboard we're finding it randomly will skip the a record in the push. The log file gives us the following error: 

"Warning: Version loading was stopped by ESLatestScriptLoader for sys_es_latest_script_[SYSID]"

 

The files which are having the error did not have the ECMAScript toggle checked. 
The environments we're using to are on the same version/patch as they're a clone. 

 

I found a problem record where the same error occurs when updating plugins. That problem is fixed in Patch 7 of Xanadu, but we're not up to it yet. PRB1812035. 

Anyone have any suggestions?

FilipVacula
Tera Contributor

@James Bustard After running a larger release recently using Update Sources, I also found 10 of these Warnings.

 

I compared the records in the table sys_es_latest_script between the 2 instances and confirmed they are the same. Therefore I dismissed this warning, as I have no reason to believe that something actually went wrong.

 

I only found reference to this error in your message and in the docs All fixes from Yokohama Patch 3 Hot Fix 2 to Yokohama Patch 6, referencing PRB1883239:

Server-side scripts

PRB1883239

Yokohama Patch 5ESLatestScriptLoader returns a warning messageThe message reads, 'Version loading was stopped by ESLatestScriptLoader for sys_es_latest_script...'. 

 

We are on Yokohama Patch4a, which would explain the warning message.

Version history
Last update:
‎08-24-2024 08:49 AM
Updated by:
Contributors