Scheduled Jobs

[John Lombardo]

Hi

I set up a Scheduled Job in the sys_trigger table and I have it calling a business rule that checks on inactivity in the sc_task table. The BR auto closes the task. This seems to work just fine. I was told by a co-worker that I am supposed to create the scheduled job from the System Definition>Scheduled Jobs process. This will then create a record in the sys_trigger table. I can make that work also.

If I start in sys_trigger I can reference a calendar so it only runs during business hours. I cannot do this if I set it up from the sysauto_script table.

Any thoughts on why I should not do it my way, which is create the trigger and call the BR from there?

I've read articles in the community about this and they say to start with System Definition>Scheduled Jobs and a few reasons are so that you can control it better with more detail. I find it to be just the opposite. 

Thanks,

John

[Erik Stolberg · Accepted solution]

Well for one, the documentation specifically calls this out and says not to create on the sys_trigger table:

Create a scheduled job on the Schedule Job [sysauto] table (System Definition > Scheduled Jobs).
Create all new scheduled jobs using this method. Some existing scheduled jobs are found on the Schedule Item [sys_trigger] table (System Scheduler > Scheduled Jobs). Do not create new scheduled jobs on the Schedule Item table.

https://docs.servicenow.com/bundle/london-platform-administration/page/administer/time/task/t_CreateAScheduledJob.html

With a scheduled job, you can leverage the conditional (T/F) and condition (script) to control when to run. Typically things I create don't necessarily depend on a specific schedule, so I can just use a check to see if it's a weekend or weekday. If you want to use schedules still, you could do something like this in your condition script field:

(function (){
	var sched = new GlideSchedule('123123123123123123'); //sys_id of cmn_schedule record
	var gdt = new GlideDateTime();
	if (sched.isInSchedule(gdt)) {
		return true;
	} else {
		return false;
	}
})();

[Alikutty A]

Hello John,

The Scheduled Item (sys_trigger) is like a background worker table where all types of back end jobs are created, queued up and executed. It can execute a scheduled job (sysauto), business rules (Auto close ones), Inactivity monitors, SLA calculations, metric events, SN upgrades and many more. It can list you the next execution time of a job, number of times it has executed, the source script etc. The calendar is an additional field on sys_trigger but it a legacy feature since Service Now had moved to Schedules.

Scheduled jobs (sysauto) are automated pieces of work that can be performed at either a particular time, or on a recurring schedule. It is like a sub set worker of sys_trigger where you could execute the following types of scripts only:

• Automate the generation and distribution of a report
• Automatically generate something (a change, an incident, a ci, etc) from a template
• Automatically run a script of your choosing
• Automatically run a script to create a report summary table
• Automate the generation and distribution of a custom chart

Even though it does not have schedule/calendar field, you could execute your script either at predefined times or using a conditional script on your required schedules.

Thanks!

[John Lombardo]

Hi Erik and Alikutty,

Thank you very much for your responses. 

I had spoken to a knowledgeable ServiceNow person and he suggested I create a Scheduled Job to accomplish what I needed to. The only place I knew where Scheduled Jobs existed was in the sys_trigger table or System Scheduler > Scheduled Jobs > Scheduled Jobs. 

It was afterward that I saw the documentation stating to do this starting in the sysauto table or System Definition > Scheduled Jobs.

I understand what the documentation says but I don't understand why as my process works just fine. 

I also don't understand why the Calendar has been relegated to legacy status. It is a very simple tool that works and that anyone can use. Now we have to write javascript to accomplish the same thing. It seems like this is going in the opposite direction that it should be. (Okay, maybe performance and overhead in general may be a factor but if it is that would be a good thing to know also.)

HOWEVER, I will set this up as you and the documentation say to do it. I am a team player and I do want to do things correctly.

Thanks again for your help and suggestions.

John

[John Lombardo]

I tried to mark both replies as the correct answer but it only lets me do one of them. After reading your comments and then the documentation again and a bit of trial and error I see now where the 'Schedules' take the place of the Calendars, although to be fair the Schedules are just a different version of Calendars.

Also, the record I had in sys_trigger did not get written to the Team Development process nor to my update set. This makes sense as the sysauto_script is what creates and controls the associated trigger record. 

I deleted my old trigger and created the new scheduled job and it all appears to be working as designed. 

Thanks again for your help.

John