Create tasks with REST

[Paul Neubauer]

I need to create some tasks based on criteria that are available in our database. I have a "personal" developer instance (London, like our institutional instance) and I built a script in Perl to periodically query the relevant databases and make a REST call to my instance to create the tasks needed.

I created a user we can call "MyRestUser" and granted it rest_service and itil. Then created an ACL on sc_task allowing users with the rest_service role to create records. If I set the request_body to something like:
{\"short_description\":\"The job to do\",\"assignment_group\":\"The right group\",\"due_date\":\"2019-06-13\"}
then I can create records using a REST call that have the right description, group, and due_date.

This works great in my "personal" instance, but having written and tested the Perl script there, I have now attempted to move it to our working (developer test) instance for confirmation before moving it to our production instance. Again, I created "MyRestUser" and gave it the same roles and created an ACL to allow it to create task records. However, in our real instance, there is a routine that regularly checks ITIL users against our AD database and disables any users that do not appear in AD. Our human users log in to ServiceNow using SSO, but I am trying to set up a "user" that is used only for REST services and would therefore need to log in with a password/passphrase rather than using shibboleth. That "user" would not appear in AD and so is problematic.

During the brief periods when MyRestUser is in the ITIL group, it can create tasks and populate the additional fields. However even when MyRestUser has had its ITIL role automatically removed, it will still create the task, but the short_description, assignment_group, and due_date fields that I am trying to specify in the new task are not populated. They show up as blank (empty) in the resulting task. Our working hypothesis at the moment is that although MyRestUser can create the task based on the ACL, the relevant fields are really in other, linked tables that MyRestUser does not have privileges for.

Can anyone help to confirm or disconfirm that hypothesis? If so, would ACLs on those tables help? (Which tables?) If not, is there a less inclusive role than ITIL that might be used to create and specify a task?

Thanks,

Paul

[Brad Tilton]

You hypothesis sounds correct. Instead of changing your security model, however, I would take a look at the routine that checks the users against ad and see if you can exempt some user accounts.

Alternatively, does this have to be a Perl script? You should also be able to use a scheduled job to create tasks within the instance and run it as the system so you don't run into these security issues.

[Paul Neubauer]

Those are both interesting suggestions. I'll have to see if I can manage to exmpt the local, nonAD user from getting disabled. I also sort of like the idea of a scheduled job inside the ServiceNow instance, but I'm not at all clear on the programming possibilities within SN. The job requires some fancy footwork comparing the results of queries against multiple databases on multiple servers. Using Perl hashes to keep track of the returned records from the queries so that they can be looked up by key values, is super handy. At this point, I'm still pretty much a novice at ServiceNow, so I don't know if similar capabilities for parsing returned JSON or relating different records are even available inside ServiceNow. I'll see what I can learn. The Perl looks like my best bet at least for the time being though.

If I need to get an AD user or can tinker with the import routine, I'll go that route. So far, I'm still thinking that just granting sufficient privs to the local user looks like the simplest method, but I'm open to being convinced otherwise.

Thanks,

Paul

[Brad Tilton]

Ok, I didn't think of this before, but you do have another option if you're more comfortable doing most of the fancy footwork in your perl script, which is using a Scripted REST API. This lets you define a REST endpoint in ServiceNow and then run some ServiceNow code when the endpoint is consumed. You could create a create task scripted rest api, give it a custom role, and have it programmatically create a task server side in SN as system. This way you wouldn't have to add security rules to the sc_task table.

Scripted REST API

GlideRecord

[Paul Neubauer]

Now that is a pretty wild option. I'm not sure that I like it, but I'll have to think about it. Adding a whole additional layer in the process makes me uncomfortable and the "custom role" strikes me as dubious. If I can create a custom role that works for the scripted rest api, why not a custom role for the user? They would basically both need the same privileges, wouldn't they?

Food for thought...