IRM > Control > Control Indicator > Script

PeterP003464432
Tera Contributor

Hi Team,

 

with the help of a control indicator (ServiceNow IRM), I want to automate control testing.

 

I created a REST Message accessing an IAM Solution to get some data, this works perfectly in Scripts - Background and when executing the REST Message directly.

The script I'm using is the one from the HTTP-Method of the REST Message under Preview Script Usage. 

 

The problem I'm facing is, that this script will not be executed in a Control Indicator - it seems that it runs always in the catch-section of the script.

 

For your reference here is the script I'm using:

 

try {
var r = new sn_ws.GlideRESTMessageV2('GETAccessRoles', 'GET_Roles');

var response = r.execute();
var responseBody = response.getBody();
var httpStatus = response.getStatusCode();
result.passed = true;
result.value = 200; //just for troubleshooting
}
catch(ex) {
var message = ex.message;
result.passed = false;
result.value = 123; //just for troubleshooting 
}

 

Any ideas???? Thanks in advance !

3 REPLIES 3

Matthew_13
Mega Sage

Hi Buddy,

This is a pretty common IRM / Control Indicator gotcha, and nothing is “wrong” with your REST call itself.

The key thing is that Control Indicators run in a different execution context than Background Scripts or the REST Message test UI. When something isn’t allowed in that context, ServiceNow throws an exception immediately — which is why your script always ends up in the catch.

A few likely causes that I can recommend:

  • The Preview Script Usage example often works in global/background, but Control Indicators are stricter. In many cases you need to use sn_ws.RESTMessageV2 instead of sn_ws.GlideRESTMessageV2.

  • Cross-scope access: the Control Indicator may not have permission to read the REST Message definition or use the credential/connection alias, even though it works as admin in background Scripts.

  • Outbound REST restrictions: the indicator runs as a system/evaluation user with fewer privileges than you expect.

Right now your catch hides the real error, so you’re flying blind. Log the exception so you can see what’s actually failing:

catch (ex) {
  gs.error('Control Indicator REST failed: ' + ex);
  result.passed = false;
  result.value = ex + '';
}

Then run the indicator and check System Logs. The error message will usually tell you exactly whats blocked cross-scope, credentials, API access etc....

Once you see that message, the fix is usually straightforward:

  • add a cross-scope privilege,

  • move or duplicate the REST Message into the same scope,

  • or adjust which RESTMessage class you’re using.

@PeterP003464432  - Please mark Accepted Solution and Thumbs Up if you found helpful

MJG

lauri457
Tera Sage

Is it really working in bg scripts with that class name? Try sn_ws.RESTMessageV2 without the "glide" instead.

What is the error thrown? Is it something along the likes of "undefined is not a function"? Then see above

PeterP003464432
Tera Contributor

Hi - thanks for all the help - unfortunately no success. Here is what I did:

 

  1. add the "gs.error ...." in the script
  2.  create a new REST Message in the application scope of the indicator (GRC: Profiles)
  3. tested in the REST Message > HTTP Method the endpoint : Result 200 with some data
  4. tried the script in s - b : Error Message (
    EST Msg Outbound - RESTMessageClient : Error constructing REST Message/Method: GETAccessRoles2/Default GET: Unable to find REST Message Record with Name: GETAccessRoles2: no thrown error

     

  5. Executed the script in the indicator within the GRC:Profile - scope, received two error messages:
ErrorControl Indicator REST failed: com.glide.communications.ProcessingException: Error constructing REST Message/Method: GETAccessRoles2/Get Roles
ErrorREST Msg Outbound - RESTMessageClient : Error constructing REST Message/Method: GETAccessRoles2/Get Roles: REST message/method 'GETAccessRoles2/Get Roles' not found in table 'sys_rest_message_fn': no thrown error

 

Any ideas? I don't think it is an access problem ....