The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sabell2012
Mega Sage
Mega Sage

 

NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.

 

DIFFICULTY LEVEL:    BEGINNER to INTERMEDIATE
Assumes having taken the class SSNF and has good beginner to intermediate level of knowledge and/or familiarity with Scripting in ServiceNow. Don't be fooled, even though the examples are simple the concepts require knowledge of ServiceNow scripting.


Do you ever develop code snippets to prove a concept? I know I do, but it always leads to the question: How can you test those snippets to see if they function correctly in ServiceNow? There are actually three methods: Scripts - Background, Scheduled Jobs, and Fix Scripts. When I originally wrote this article in May of 2016 there really was only one shining, outstanding way to do complex script testing, and that was with Fix Scripts. Since then ServiceNow has ruined the functionality of Fix Scripts by taking away the Active flag (it was there, but was busted and eventually it just went away), and, if you are in Scope, they now auto-run on deployment (with absolutely no way to turn that off other than to delete it from the scope). Also, since 2016, others have stepped in to help improve the functionality of Scripts - Background. In this article I will update my previous notes and observations and introduce you to a nifty browser-based tool that allows for some serious functionality to be present in Scripts - Background. I will also point you to a couple of articles where you can use an external editor to work with scripts. So let's get started!

 

Method 1: Scripts - Background

 

The Scripts - Background method includes three steps:

 

  1. Search for: Background or Scripts - Background and click on the link
  2. Choose your Scope: here we will be using Global
  3. Type your code snippet into the free-form script field that appears.


Pros:  

 

  • Quick and easy process that works great for quick-and-dirty tests
  • Allows you to run the script in scope (giving you possible access to ECMA 2021 features of JavaScript)
  • Echoes the code into the System Log as a form of audit (although you might consider this a con if your script is a pretty good size)
  • Instantly returns results when using gs.print, gs.info, gs.log, gs.error and gs.warn


Cons:

 

  • No versioning (this is the greatest negative I see)
  • Cannot save the scripts to ServiceNow or download them
  • Cannot export the script XML
  • Cannot export to Update Set
  • Out-of-the-Box it does not provide line numbers or editors (it can be best to develop the actual script in something like Notepad++ when using this method)
  • Auditing only occurs via the System Log entries; which along with the echo of the script can throw a lot of garbage into the log.
  • Long running scripts lock up the user interface (no run-in-background, but this is by design)
  • In Firefox, you will probably lose the just-executed script as the browser blanks it when you hit the back arrow (Internet Explorer and Google Chrome do not seem to have this problem, though you can avoid it in Firefox by copying the script out to an external text editor before clicking the Run Script button)
  • If your session times out you will have to start over as it will very likely wipe your script (you will need to make a habit of copying out your code to an external editor!)


Demonstration of Scripts - Background

 

  1. In the navigation filter, type: Background
  2. Go to System Definition > Scripts - Background
  3. Leave Scope, at the bottom of the form, Global.
  4. Add the following script into the "Run Script" field:

 

gs.info("---> Hello world!");

 

NOTE: This can be ANY valid server-side script. This can be multi-line, include functions, glide script, GlideRecords, eval, etc. Note the lack of line-numbers or any sort of editing features. The Scripts - Background application was created only to allow for the literal quick-and-dirty execution of simple scripts.

NOTE: I added the ---> at the start to make it easy to find this entry in the System Log.

 

sabell2012_3-1701004684802.png

 

5. Click the "Run Script" button to execute your script

6. Result:

 

sabell2012_2-1701004665243.png

 

7. Navigate to System Logs > All

8. Filter on Message *---> to view the "Audit" log (you have to include the Created by field to get the full affect).

 

sabell2012_4-1701004801414.png

 

Method 2: Fix Scripts

 

The Fix Scripts method includes seven steps:

 

  1. Search for: Fix or Fix Scripts and click on the link. BTW, make sure you are in Global, and not a scoped application.
  2. Click the "New" button to start a new script and fill in name and type in the script you want to test
  3. Bring up the header bar context menu and click "Save"
  4. Go to the bottom of the form and click the "Run Fix Script" link
  5. Click the "OK" button on the first pop-up that appears
  6. Click the "Proceed" button on the second pop-up that appears
  7. View your results and click the "OK" button once you're ready to close the results pop-up


Pros:

 

  • Provides the power of the full editor (note that you have line numbers, syntax checking, formatting, etc.)
  • Includes versioning
  • Instantly returns results when using gs.print, gs.info, gs.log, gs.error and gs.warn
  • Can be added to Update Sets
  • Includes auditing at the table/field level out of the box
  • Easy to make a minor change and retry the script
  • Easy to save scripts
  • Allows you to export the script to XML
  • Allows you to push long running scripts to the background and then monitor via Progress Workers
  • Still works great as a modeling tool in Global scope, but not in a Globally scoped application (see Cons for more on this).


Cons:

 

  • Active flag was removed; it didn't work anyway. So, no way to disable a Fix Script. This is especially important as:
  • Fix Scripts, unfortunately, auto-run when in a Scoped Application and are deployed to another instance!
    • This one thing just about killed their use as a modeling tool. It was very poorly thought out by ServiceNow. No excuse guys. You should have made the Active flag functional.
  • Requires more setup time than Scripts-Background to use.


Demonstration of Fix Scripts

 

1. Navigate to System Definition > Fix Scripts

2. Click the "New" button

3. Fill in the following:

  1. Name: Two Methods for Code Development
  2. Description: Fix Scripts method for testing a code snippet.
  3. Script
gs.info("Hello world!");

 

4. Bring up the context menu and click on Save

 

sabell2012_0-1701128045057.png

 

5. Click on Run Fix Script button. The Run Fix Script pop-up form appears.

6. Click on the Proceed button.

 

sabell2012_1-1701128193485.png

 

7. Your results will appear in the Run Fix Script pop-up form.

 

sabell2012_2-1701128245621.png

 

 

8. View your results and click the "Close" button to close out the results form and return to the Fix Scripts form.

9. Repeat steps five through eight, and instead of clicking the "Proceed" button, click the "Proceed in Background" button to bring up the Fix Script in the background form

10.  Click the "Close" button to return to the Fix Scripts form

11. Navigate to System Diagnostics > Progress Workers.

12. Order by Updated descending. You should see your most recent Fix Script execution at the top.

 

sabell2012_3-1701128465775.png

 

13. Note the result of your code execution in the Message field

 

Scheduled Jobs - Scheduled Script Execution

 

This is the Fix Script work-around.

 

Pros:

 

  • Provides the power of the full editor (note that you have line numbers, syntax checking, formatting, etc.)
  • Includes versioning
  • Can be added to Update Sets
  • Can be added to Scoped Applications without worry
  • Includes auditing at the table/field level out of the box
  • Easy to make a minor change and retry the script
  • Easy to save scripts
  • Allows you to export the script to XML
  • Works fine for modelling in both Global and Scoped.
  • Has an Active flag!

 

Cons:

  • By default runs scripts in the background and then monitor execution in the Today's Scheduled Jobs list
  • Requires more setup time than Scripts-Background to use
  • Always runs in background
  • Results are found in the System Log

 

Demonstration of Scheduled Jobs

 

1. Navigate to System Definition > Scheduled Jobs

2. Click on the New button

3. Choose Automatically run a script of your choosing

4. Fill out the form with the following:

  1. NameTwo Methods for Code Development
  2. Active: Checked
  3. Conditional: Un-checked
  4. Run: On demand
  5. Script:

 

gs.info("Hello world!");

 

5. Bring up the context menu and Save your work.

 

sabell2012_5-1701130458801.png

 

6. Click the Execute Now button.

7. Navigate to System Scheduler > Today's Scheduled Jobs and search for Two Methods for Code Development

- You may need to add the Updated field to the list view.

8. Navigate to System Logs > All and search for Hello World in the message field.

 

sabell2012_6-1701130694029.png

 

Which Method is Better?

 

I have used Scripts - Background for years, and it is still my first choice for smaller scripts. I used to rely heavily on Fix Scripts until ServiceNow broke them. Now I work mostly with Scheduled Jobs, but really, they are not for modelling. Just a work-around. All run server side, and both methods do have their uses. Anyway, all are super tools for the tool box.

 

  Scripts - Background

Fixed Scripts /

Scheduled Jobs

Easy to use Yes Yes
Allows for running in scope Yes Yes
Audit System Log only Yes
Instant Return Yes Yes, when run in foreground
Can run in background No Yes
Full editing and syntax checking No Yes
Versioning No Yes
Can be added to update sets No Yes
Easy to make changes Sort of, clunky Yes
Save scripts No Yes
Export to XML No Yes

 

Some Useful Tools

 

Okay, so that was all of the out-of-the-box stuff. Let me introduce you to a couple of things that improve the Scripts - Background usage significantly!

 

SN Utils by Arnoud Kooi

 

This is an awesome tool for working in Scripts - Background. It brings in some excellent functionality. It is a browser plug-in that installs on the most common browsers. Here I will show it in Microsoft Edge.

 

It provides:

  • line numbers
  • result panel
  • execution history

All on the same form!

 

Let us revisit our earlier Scripts - Background example.

 

sabell2012_4-1701129085006.png

 

Very nice! If you want this functionality you can install it from here: https://www.arnoudkooi.com/

(@Arnoud Kooi)

 

Check out Chuck Tomasi's (@Chuck Tomasi) interview of Arnoud here: https://developer.servicenow.com/blog.do?p=/post/dyk-snutils/ 

 

VS Code Extensions

 

ServiceNow has introduced a very nice extension for Microsoft Visual Studio Code. This provides the robustness of a true code editing and versioning environment melded with Scripts - Background. This comes really close to providing a true IDE (integrated development environment) for the ServiceNow platform. Check it out! It is a bit involved to set up at first, but well work the final results. https://docs.servicenow.com/bundle/vancouver-application-development/page/build/applications/concept... 

 

The key to the VS Code Extensions resides here: Being able to run Scripts - Background from the VS Code environment! Read more about it here: https://docs.servicenow.com/bundle/vancouver-application-development/page/build/applications/task/vs... 

 

Download VS Code from here: https://code.visualstudio.com/download 

 

So that shows some of the things I have explored concerning Scripts - Background and Fix Scripts/Scheduled Jobs. I hope that helps you in your development walk.

 

Enjoy!

Steven Bell.

 

If you find this article helps you, don't forget to log in and mark it as "Helpful"!

 

sabell2012_0-1700830586943.png


Originally published on: 5-7-2016 06:00 AM

I updated the code and brought the article into alignment with my new formatting standard.

3 Comments