Test Scheduled Jobs(and Fix Scripts) in the Script Debugger

[codycotulla]

Hi, 

I love the ServiceNow Script Debugger! It has made testing in ServiceNow much easier. 

One challenge I had though was that scheduled jobs run in the background, and so they cannot be run in the script debugger.

Fortunately, there is a way to run your scheduled jobs in the foreground so that you can step through them in the script debugger.

All you need to do is add a UI Action with the following code to the Scheduled Script Execution (sysauto_script) table. I've attached the UI Action I use. It's called Test Script, because ... well you can imagine why.

try{
		
	var evaluator = new GlideScopedEvaluator();  
	evaluator.evaluateScript(current, 'script');
	action.setRedirectURL(current);
	
}	
catch(e){
	gs.addInfoMessage(e);
}

That's it.

Once you have this UI Action in place, you'll be able to run test your Scheduled Job scripts in the script debugger. 

AND ... a couple notes.

• If you use this "functionality" to test a script, remember that you'll be running your script in the foreground, so limit the number of records you are processing and so that you don't end up sitting there waiting for your script to time out!
• You can also use this method to test Fix Scripts in the Script Debugger.
• Since you can call Script Includes from Scheduled Jobs, this gives you a way to easily test Script Includes.

I hope other people find this helpful. I know that being able to test Scheduled Jobs and Fix Scripts in the script debugger has saved me a lot of time.

Let me know if you have questions.

Thanks,

Cody 

[pf]

thank you Cody!!

[Kristoffer Mon1]

Awesome work! Was just thinking about this and voila, the community comes through.

[Phil Swann]

Great job. I love the GlideScopedEvaluator API. Very nuanced but when you find a use case such as this, it makes perfect sense - thank you! 

Next time I need to do this I will bear in mind.

Next... Async business rules... hmmm 😄 

[kshaw]

Am not able to get this working.

Imported your XML, logged out and back in.

Ran Background script. Nothing happened in dubugger.

[codycotulla]

Hi Kshaw,

After you install the file, you'll have an additional UI Action named Test Script when you are on a scheduled job page.

You need to do the following:

1. Put a break point in your script.
2. Launch the script debugger.
3. Run the script by clicking the Test Script UI action.
   When the script hits your break point, it will launch the debugger.
   
   I hope that the image below gives you an idea of what you should see.

Thanks,

Cody

[Juanjo]

Tested with Fix Scripts, it works like a charm

[Craig Jacobs]

I tried this with a Scheduled Job, however it did not allow me to hit breakpoints in the script. Not sure what I did wrong.

I'm going to try this approach next -

Script debugger not working for Scheduled Scripts? - Developer Community - Question - ServiceNow Com...

[LaraReddy]

Hi Cody,
Many thanks for the time saved work.

But we're getting the below errors, when we tried using the Test script UI action.

Currently we're trying on PDI level and the version is Vancouver

Advance thanks.

[James Fricker]

Prompting version. This example requires action name to be "test_fix_script", client ticked, and onclick set to "promptUser()".

function promptUser() {
    var dialog = new GlideModal('glide_modal_confirm', false, 400);
    dialog.setTitle('Test Script');
    dialog.setPreference('body', 'This will run the script in the current session to allow the script debugger to be used. Do you want to continue?');
    dialog.setPreference('buttonLabelCancel', 'No');
    dialog.setPreference('buttonLabelComplete', 'Yes');
    dialog.setPreference('onPromptComplete', function() {
        gsftSubmit(null, g_form.getFormElement(), 'test_fix_script');
    });
    dialog.render();
}

(function() {
    if (typeof window == 'undefined') {
        action.setRedirectURL(current);
        try {
            new GlideScopedEvaluator().evaluateScript(current, 'script');
        } catch (e) {
            gs.addInfoMessage(e);
        }
    }
})();

[James Fricker]

The main problem with this is that the script debugger will disconnect after about 60 seconds without any warning or notification and then the script will continue without pausing at the next breakpoint. So for example if you set your first breakpoint at a point in the code that will take more than 60 seconds to reach then it will likely fail and the code will just keep running. Also if you use this with a fix script that has the "Record for rollback" enabled then there will be no rollback record created. Also I found that 2 copies of the code were executed even though I had only clicked the button once.