A known issue exists in the base product that may affect users with the Service Portfolio Management module. During the upgrade to Fuji, the upgrade script may unexpectedly alter the class name for records in the new sys_metadata table that are not part of the Service Portfolio Management module if the class name was originally set to Null. This can lead to unexpected results as the records that are incorrectly updated during the upgrade appear in the list, but navigate to the wrong entry causing a "Record not found" error.

While installing the Service Portfolio Management plugin [com.snc.service_portfolio] in a Fuji instance, the fix job fix_contract_sla_sys_class_name performs an update to the sys_class_name field in the sys_metadata table. This update sets the sys_class_name fields that are null to "contract_sla" by mistake. There are records in that table that are null, but are not part of the newly installed Service Portfolio Management plugin.

The defect is triggered in one of two ways:

* by upgrading to an affected version of Fuji from a Eureka or earlier version
* by activating the plugin while on an affected version of Fuji

Because of this, and the unavailability of a workaround, please be sure to upgrade to a fixed version when planning to move to Fuji or when considering activating this plugin. The defect has been resolved and fixed in the versions listed in the Fixed In section below.

Steps to Reproduce

ServiceNow has determined that customers meeting the following conditions may be at risk before they upgrade to Fuji.

  • The instance is running Eureka or a prior family release
  • The Service Portfolio Management plugin is active
  • The instance is using Application Files [sys_app_file] other than SLA Definitions [contract_sla] and these may be migrating to the new Application File record [sys_metadata] in Fuji

There is a possibility, for some of these migrated records, that the sys_class_name will be null.

 ServiceNow has been able to reproduce this issue using the following steps:

  1. Upgrade to a Fuji release prior to patch 7.
  2. Notice that the sys_class_name may be populated to SLA Definition [contract_sla] after the upgrade for the above Application file records in the new Application File table [sys_metadata] if the value was null before the upgrade.
  3. After the upgrade has completed, accessing records that were incorrectly updated from the Application Files, or any list view hierarchy, actually navigates to the SLA Definition and causes a "Record Not Found" error.


Use Fuji Patch 7 or later if upgrading to Fuji from a prior release family. If an upgrade has been completed using an earlier Fuji release, the data may be corrupted for the non-SLA definitions mentioned in the steps to reproduce above. To recover the corrupted data, we recommend leveraging this workflow:

  1. Find each record where the sys_class_name is set to contract_sla.
  2. Identify those that do not exist in the SLA Definition [contract_sla] table.
  3. Update the sys_class_name to null for these records to revert the unwanted updates.


To quickly affect the desired change, our development team has provided the following background script.  Simply execute this in the Background Scripts module to correct any records that were mistakenly altered during the upgrade.

	var tablesDictionary = [];
	var objGr, objSubGr;
	// First, populate the array with the tables extending from sys_metadata that have existing
	// records there and without children
	var sysMetaGrp = new GlideAggregate('sys_metadata');
		if(sysMetaGrp.getValue('sys_class_name') != 'contract_sla') {
			// Populate the array only with table's without children
			objGr = new GlideRecord('sys_db_object');
			objGr.addQuery('name', sysMetaGrp.getValue('sys_class_name'));
				objSubGr = new GlideRecord('sys_db_object');
				objSubGr.addQuery('super_class', objGr.sys_id);

	gs.print("Total of " + tablesDictionary.length + " tables to check in sys_metadata");

	// Then, for the records with value='contract_sla' which is the corrupted one, review if there's an
	// existing valid sys_id, if there is it means it was corrupted by the upgrade fix
	var subGr;
	var gmu;
	var sysMeta = new GlideRecord('sys_metadata');
	sysMeta.addQuery('sys_class_name', 'contract_sla');
		for(var i=0; i < tablesDictionary.length; i++){
			subGr = new GlideRecord(tablesDictionary[i]);
			subGr.addQuery('sys_id', sysMeta.sys_id);

				// The sys_id belongs to a different table, use GUM to update the value directly
				gs.print("Updating sys_id " + sysMeta.sys_id + " with sys_class_name: " + tablesDictionary[i]);

				gmu = new GlideMultipleUpdate('sys_metadata');
				gmu.addQuery('sys_class_name', 'contract_sla');
				gmu.addQuery('sys_id', sysMeta.sys_id);
				gmu.changeValue('sys_class_name', 'contract_sla', tablesDictionary[i]);

	// After doing the update, revise for records still having the issue, based on the
	// read audit script.

	// NOTE: The below code uses an inverse logic from the code above, instead of getting the possible
	// affected tables and checking for existence in contract_sla table, it first gets all the
	// sys_id's from contract_sla and then verifies there are no unmatched records in sys_metadata

	// Get all the ids in the contract_sla table
	var contractSlaIds = [];
	var readAudit = new GlideRecord('contract_sla');
	while (readAudit.next()) contractSlaIds.push(readAudit.getUniqueValue());

	// Get all the metadata records classed as contract_sla
	// that are NOT IN the contract_sla table
	readAudit = new GlideRecord('sys_metadata');
	readAudit.addQuery('sys_class_name', 'contract_sla');
	readAudit.addQuery('sys_id', 'NOT IN', contractSlaIds);

	var rowCount = readAudit.getRowCount();
	if (rowCount === 0) gs.print('DONE: No more affected records exist');
	else gs.print('WARNING: ' + rowCount + ' sys_metadata records still detected');



Related Problem: PRB633674

Seen In

Fuji Patch 12 Hot Fix 1
Fuji Patch 3
Fuji Patch 7 Hot Fix 5
Fuji Patch 7 Hot Fix 9
Helsinki Patch 0 Hot Fix 1

Fixed In

Fuji Patch 6

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2016-07-25 12:38:49