gs.executeNow returns null sys_id

[Chrisdev]

I have a scoped application which has a Scheduled Script Execution (sysauto_script) and an Import Set (scheduled_import_set). The Scheduled Script Execution's script performs some logic then calls gs.executeNow() on the application's Import Set record. The Scheduled Script Execution and Import Set are both part of the same scoped application (and have their sys_scope value set to the value of the scoped application).

The Run As user for my Scheduled Script Execution is a non-admin user, which has the appropriate roles to read/write to necessary tables.

However, gs.executeNow() always returns null (unless I run the Scheduled Script Execution as an admin), indicating to me that somehow the script/import_set are in different scopes?

The Scheduled Script Execution is being executed by clicking on the 'Execute Now' button in the UI. Interestingly when I Iog gs.getCurrentApplicationId() the current application is "global", even when the sys_scope is set to my custom application? 

Any idea why gs.executeNow() works (returns a non-null sys_id) with admin but not a non-admin with appropriate read write roles to the tables I require access to?

[Allen Andreas]

Hi,

Using gs.executeNow() and it returning a null value means that the job is global (in that occurrence), per documentation anyway. We're unsure what all your script may be doing, but I know you've mentioned you've checked this over, but double check that the scheduled job script and anything else related are in the same application scope.

Documentation just to offer it: https://developer.servicenow.com/dev.do#!/reference/api/paris/server/no-namespace/c_GlideSystemScope...

Does the user you're trying to run it as have appropriate rights to that application scope?

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

[Chrisdev]

By "Does the user you're trying to run it as have appropriate rights to that application scope?" do you mean restricted caller access settings?

In the below example I have set Abel Tuter's roles to everything other than "admin". This is something that I think just may not work. Performing a really simple test, the scheduled script just executes the data import. When executing the script via 'Execute Now' UI button as any non admin user it always gives a null sys_id, when running as an admin it works.

Scheduled Script Execution:

• Name: test Scheduled Script - needit
• Active: true
• Application: NeedIt
• Run as: Abel Tuter
• Script:

var import_job = new GlideRecordSecure('scheduled_import_set');
import_job.addQuery("name", "test Data Import - needit");
import_job.query();

if (!import_job.hasNext()) {
	gs.error("Failed to find scheduled import set");
} 
else {
	import_job.next();
    var import_sys_id = gs.executeNow(import_job);
    gs.info("Started import with sys_id: " + import_sys_id);
}

Scheduled Data Import:

• Name: test Data Import - needit
• Run:Periodically
• Datasource: (empty)
• Active:false
• Run as: System Administrator
• Application: NeedIt

[Chrisdev]

One further update, switching to GlideRecord over GlideRecordSecure (see my original reply) works, which may indicate an issue with an ACL.

[Allen Andreas]

Hi,

Yes. That's what I meant by my reply above, sorry if that wasn't clear.

"Does the user you're trying to run it as have appropriate rights to that application scope?"

I was inquiring as to their specific ACL access.

GlideRecordSecure will process using ACLs.

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