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

How can I see the results of a scheduled job execution?

Risa4
Tera Contributor

Hi,

Where can I see the results of a scheduled job execution?
This is because we want to check the operation of the ServiceNow script each time we code.
It would be nice if we could see the execution results after pressing the Execute Now button.


In case you are wondering, the ServiceNow modules we are using for coding are as follows


System scheduler>Scheduled Job

find_real_file.png

 

 

 

 

 

 

Best Regard

1 ACCEPTED SOLUTION

Allen Andreas
Administrator
Administrator

Hi,

You'd want to use appropriate logging such as:

gs.info("helloworld");

And you can check your syslog (example: type syslog.list and press enter in left-hand navigation) after the script has ran to see your log entries.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

View solution in original post

4 REPLIES 4

Allen Andreas
Administrator
Administrator

Hi,

You'd want to use appropriate logging such as:

gs.info("helloworld");

And you can check your syslog (example: type syslog.list and press enter in left-hand navigation) after the script has ran to see your log entries.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Aman Singh_
Kilo Sage

Hi,

 

Schedule job allow server side scripting in its script field.

 

Server side debugging include

gs.info

gs.log

gs.error

gs.warm

gs.debug

 

js.log is Client side debug method.

 

In order to check you log navigate to System Log.

 Mark ✅ Correct/helpful, if applicable, Thanks!!

Aman

irene_mascari
Tera Expert

I have a similar/related issue. I am trying to address a problem caused by a Scheduled Job which is a remote file import to the sys_user table. This process runs daily to update the User population based on an export from our HR system.

 

For some reason this import is not updating the sys_user manager field correctly. This seems to occur when a manager terminates and is replaced by a new person. The job keeps restoring the prior (terminated) manager to the user record when it runs. If I fix correct the managers manually they get reverted back to the terminated manager the next time the job runs. I need to find this at the source as it is causing a lot of problems since  workflow items are being assigned to these terminated managers. The remote file source table, which is an export from our PeopleSoft system, has the correct information. This scheduled job is causing the problem.

 

My problem is I have no idea how to find the actual script (if that is what is called) that this Scheduled Job is running. I need to see the details of what it is actually doing when it updates the manager field. I looked under Business Rules, Script Includes, Remote File Import. I found a transform map but it has no mapping for the manager field so there has to be another piece someplace. 

 

I will very grateful if someone could point me in the right direction. 

 

Irene

 

Any help will be very appreciated.

Irene

 

How do I find the actual script that is running for this job? This script / scheduled job was built by our SN consultants. I have no documentation and no idea what the underlying items associated with it are called or where they are stored. 

Hi,

I'd recommend creating your own post to increase visibility as this thread is from several years ago and already has a correct solution marked. To give you some assist, please check your script include for a record named: CSRemoteFileImport as shown in the screenshot you provided and the 'Run this script' field.

 

I would also recommend checking the CSV at the file patch mentioned as there could be an issue where that specific file is not being overwritten and so it's just reusing the same CSV over and over. I find it hard to believe it's not a data issue because otherwise, per your assumption, the script is somehow memorizing old managers and populating them back again...which I find doubtful. Just my 2 cents 🙂

 

Additionally, it would be hopeful that the SN consultant(s) you all had hired provided documentation about this specific setup. I'd recommend looking into that as well.

 

If my reply here doesn't help you resolve your issue, please create your own post and feel free to mention me in it and I'll join you over there.


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!