The CreatorCon Call for Content is officially open! Get started here.

ServiceNow Cache will not update

Marc_007
Tera Contributor

Hello all,

     I made a change in my script for a word misspelled eligable and corrected the spelling to eligible. We already had clone down which I thought would have fix this with out using cache.do Will I need to invoke the cache.do in all instances? Please see attachments below.

1 ACCEPTED SOLUTION

Robbie
Kilo Patron
Kilo Patron

Hi @Marc_007,

 

This has me thinking - "alert()" is a method of the window object in the underlying JavaScript. Typically an alert message defined in a client script would not require a cache.do to reflect a change. Is this the only place this message and string is defined?

I have not seen this require clearing the cache.

For a little further understanding of cache.do and it's affects, I recall a good article written on the community from @Shahed Shah1 - check it out. (See below).

 

To confirm my though process, can you change the alert message to something completly different to see if the change is immediately reflected. This will tell you straight away if it is cache related (which I don't think it is) vs being defined and called somewhere else.

 

https://www.servicenow.com/community/now-platform-blog/you-don-t-always-need-to-clear-the-cache/ba-p...

 

To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Kudos.



Thanks, Robbie

View solution in original post

6 REPLIES 6

Thanks Kieran,

     I will make this change (As an FYI - If this is a client/catalog client script, you should be using getMessage("message_key") and storing your message in sys_ui_message table) FYI, This is in record producer.

Shahed Shah1
Tera Guru

Hi there.

Thanks for the shoutout Robbie!

 

While Client Scripts do get cached (in the platform as well as your browser), Robbie and Kieran are correct at getting you to look at a thorough comparison of the script between Prod and sub-prod.

 

Plus, I'd side with Kieran in that you should leverage the combination of getMessage() and sys_ui_message as the approach for presenting messages to the user. There's a lot of async code that runs in the background, and usage of alert() and confirm() will create interruptions.

 

See Translate a client script message for more info on the implementation. This will also resolve your issue as this will force lookups for messages.