Calls to QueryBuilder for population of Service CIs and Global Search return no CMDB results when executing in new V2 mode - Known Error

Calls to QueryBuilder for population of Service CIs and Global Search return no CMDB results when executing in new V2 mode Description From Zurich onwards, processes that call into Query Builder can have no results returned. Two scenarios where this occurs:

A service CI populated via CMDB Group containing a Saved Query (as constructed in Query Builder) may have no "svc_ci_assoc" records, even when rerunning the service population. However, the expected CIs will appear when viewing the CMDB Group or Saved Query directly.

Instances configured to use "Zing" for Global Search will not return any CI records in the findings. These different methods both rely on the "CMDBGroup" API, which may not return results of query execution when using the "v2" execution mode introduced in Zurich.

Steps to Reproduce

From Zurich onwards, processes that call into Query Builder can have no results returned. Two scenarios where this occurs:

A service CI populated via CMDB Group containing a Saved Query (as constructed in Query Builder) may have no "svc_ci_assoc" records, even when rerunning the service population. However, the expected CIs will appear when viewing the CMDB Group or Saved Query directly.

Instances configured to use "Zing" for Global Search will not return any CI records in the findings. These different methods both rely on the "CMDBGroup" API, which may not return results of query execution when using the "v2" execution mode introduced in Zurich.

To reproduce the issue directly (with privileged account):

1) Open the "sys_properties" record for "glide.cmdb.query.execution_mode" and set to "v1". 2) Find or create a Saved Query that returns a handful of records 3) Run the query and observe the results 4) Create a new CMDB Group and associate with the newly created Saved Query 5) Click "Show All" and observe the same results as step 3 6) Run the background script below, replacing the sysid with the CMDB Group's SysID (this function is also used by SM for populating services)

--- var groupId = '956432853778f210d12ae15174924b38'; // Replace with SysID of the associated CMDB Group var domain = 'global'; var recLimit = 100;

var cmdbGroup = new Packages.com.snc.cmdb.group.CMDBGroup(groupId); var result = cmdbGroup.getAllCIByDomainId(domain, recLimit); gs.log(JSON.stringify(result.getIdList())); ---

7) Note the same results from step 3 and 5 in the JSON.

8) Open the "sys_properties" record for "glide.cmdb.query.execution_mode" and set to "v2". 9) Repeat 3 and 5 and observe the results are still the same 10) Run the script from step 6 and observe there are no results

Note that this function is invoked both by service logic to populate the "svc_ci_assoc" table when routed through a CMDB Group, and by Global Search when searching for CI by name.

Workaround In Zurich, a new Query Builder execution mode was introduced to improve execution time of saved queries. However, one of the external interfaces for this API is not returning results as expected, instead showing no results. This manifests in two different ways:

When service logic populates a service (svc_ci_assoc records) from a CMDB Group that uses a Query Builder / Saved Query, the CIs in that saved query are not added to the service - and may even be removed from existing groups When performing a global search in environments that does not use AI search (such as Zing), no CI results are shown (despite other records, such as Incidents, being displayed The affected API is defined as part of family code, and cannot be corrected via update set. However, the instance can be configured to run in the pre-Zurich mode, which will return the expected CI results to the different calling components.

To do this, open System Properties and navigate to the property named "glide.cmdb.query.execution_mode". Out of box, this will have a value of "v2". Updating this to "v1" will change execution behaviour to pre-Zurich.

Note that this will have some impact on the time it takes to execute saved queries (effectively losing the gains in Zurich). There will be no impact to results themselves, aside from returning the CIs in the two above API calls.

If services need to be recalculated, the below script can be used:

var gr = new GlideRecord('cmdb_ci_query_based_service'); gr.addQuery("name", name of the service); gr.query();

while (gr.next()) { gs.print("syncing sys_id=" + gr.sys_id);

try { var qbsManager = new SNC.QueryBasedServiceManager(); qbsManager.syncUpdateSvcAssoc(gr.sys_id); gs.print("sync"); } catch (e) { gs.print("here we are ..." + e); } } A fix for this issue is in active development and will be targeted to be pushed to a Zurich patch. Likely Zurich Patch 5 or 6. It is highly recommended for customers to revert this workaround once this defect has been successfully back-ported to re-gain the performance optimizations.