"Discover Now" UI action resulting in the error - “Could not redirect to the Discovery Status”

[srikanthnelapud]

Overview

This article describes one of the use cases resulting in the error - "Could not redirect to the Discovery Status" when the "Discover now" UI action is clicked under the "Related Links" section in the Discovery Schedule page.

Before Paris, If a user has master + member account(s) in the instance and if any new member account is added via the cloud console then the user has to edit the Cloud Schedule in the instance and refresh the member accounts manually every time by clicking the "Refresh" button available below the slush bucket present in the Account Validation screen of Cloud Wizard, a custom UI to create the Cloud Discovery schedule.

In Paris, a feature (enhancement) is introduced to refresh the member account(s) of the master account and the respective datacenter(s) as well for each account automatically, tracked via their own discovery statuses, before the start of the Cloud Discovery run. Please note, only the discovery schedule(s) of type - "Cloud Resources" are affected due to this feature.

This feature is controlled via the system property - "glide.discovery.cdu.auto_refresh_sub_accounts_and_ldcs" and value is a boolean. Out of the box, the property value is FALSE and it indicates that the auto-refresh of sub-account(s) and LDC(s) (Datacenter(s)) is disabled. To enable it, the value can be changed to TRUE.

Problem

If the system property is set to TRUE and on clicking the “Discover Now” UI action in the Cloud Discovery Schedule then the refresh of member(s) and the datacenter(s) is triggered and then the actual cloud discovery schedule starts.

Due to the above behavior, it takes some time to complete the whole refresh thing and actual discovery run to start so there will be a time delay for redirecting to the Discovery Status (newly created one when clicking Discover Now UI Action) thus resulting in the error – “Could not redirect to the Discovery Status” because the API calls for refreshing Members and Datacenters may be in progress or near completion.

Workaround

Set the property value to FALSE.

Other issues that result in the error - “Could not redirect to the Discovery Status”

1. The current schedule is a new record
2. The current schedule has the "disable_execute_now" field value as "False"
3. The "Run as" user mapped to the current schedule doesn't have the role - "discovery_admin"
4. If the "Run as" user reference is empty for the current schedule then the logged in user doesn't have the role - "discovery_admin"
5. The current schedule isn't a valid schedule
6. LDCs and Sub Accounts Discovery Patterns are triggered via the Script Include - "CloudWizardDiscovery". In order to access the APIs of the Cloud Wizard Script Include, the current logged-in (or) schedule's run_as user should have either 'mid_server' or 'discovery_admin' role. If none of those roles exists then the user is not allowed to access the APIs and throws an error thus not creating the Discovery status thereby and resulting in the error - "Could not redirect to the Discovery Status"

Solution

The above 5 checks can be done by running the below script via Background Scripts i.e.,

https://<<INSTANCE NAME>>.service-now.com/sys.scripts.do
//////////////////////////////////////////////////////////////////////
+ var current = new GlideRecord('discovery_schedule');

+ current.get("<<SYS ID OF THE CLOUD DISCOVERY SCHEDULE>>");

+ gs.info("NEW RECORD CHECK : " + !current.isNewRecord() );  // Expected: TRUE

+ gs.info("DISABLE EXECUTE NOW CHECK : " + current.getED().getBooleanAttribute("disable_execute_now") );  // Expected: TRUE

+ gs.info("RUN AS USER CONTAINS DISCOVERY ADMIN : " + gs.getUser().getUserByID("<<USER ID TIED TO SCHEDULE VIA 'RUN AS' REFERENCE>>").hasRole("discovery_admin"));  // Expected: TRUE

+ gs.info("LOGGED IN USER CONTAINS DISCOVERY ADMIN : " + gs.hasRole("discovery_admin"));  // Expected: TRUE

+ gs.info("IS VALID DISCOVERY SCHEDULE : " + new Discovery().isValidDiscoverySchedule(current)); // Expected: TRUE
////////////////////////////////////////////////////////////////////// 

Once the above script is executed then if it's due to

#1 then try creating a new schedule => save/update it => ensure the necessary configuration in place => Try again

#2 then check the "disable_execute_now" value for the current schedule

#3 then add the "discovery_admin" role to the associated "Run as" user of the current schedule

#4 then add the "discovery_admin" role to the currently logged-in user. PLEASE NOTE FOR A SCHEDULE, 'RUN AS' USER, IF AVAILABLE, ALWAYS TAKES THE PRECEDENCE THAN CURRENT LOGGED IN USER

#5 then check the "isValidDiscoverySchedule" API from "Discovery" Script Include

#6 PRB1458562

RELATED PROBLEM(S): PRB1458562

JFYI:

Discover now	https://<<INSTANCE NAME>>.service-now.com/sys_ui_action.do?sys_id=ae72a08b0a0a0b6b0094b90e47818333
discover now	https://<<INSTANCE NAME>>.service-now.com/sys_ui_page?sys_id=06732c87c76433005b31824d5ec2602d
DiscoveryAjax	https://<<INSTANCE NAME>>.service-now.com/sys_script_include.do?sys_id=08afbbf60a0a0bb40013aec7661ec767
Discovery	https://<<INSTANCE NAME>>.service-now.com/sys_script_include.do?sys_id=a6cdaf5bc0a802550004f460b6c04967
Disable execute now	https://<<INSTANCE NAME>>.service-now.com/sys_schema_attribute.do?sys_id=74078bc3eb321100d4360c505206fe37