Discovery is ignoring reconciliation rule

[David A2]

I have a reconciliation rule configured for Linux servers where the "description" and "used for" field are not supposed to be able to be updated by Discovery. Manual entry was given description and used for, those two fields were taken away from Discovery. Yet Discovery keeps overwriting this field. Does anyone have any ideas what I'm doing wrong?

I've tried this fix but it hasn't helped - https://hi.service-now.com/kb_view.do?sysparm_article=KB0622373

[nR9]

Hi, 

I have a similar use case where I am trying to update IP Address but have given the highest precedence to ServiceWatch.

On executing the Payload for ServiceWatch, I can see IP is getting updated with the valid value. But if I am executing discovery for the device, then Discovery is also updating the value.  Would like to know why discovery is updating the value as ServiceWatch has more precedence than ServiceNow data source.

[David A2]

It looks like it's being updated either right at the end of classification or beginning on exploration. 

[James Hammond]

@David A

I would focus on the Identity probe to see where it updates the value of description, but I would also suggest you look at how your rules are set up.

Both rules have the values you want to control set as attributes; you should consider updating the Discovery Reconciliation rule to move the Description and other fields you don't want touched by Discovery to the Update with null field.

This means that Discovery can only update the field if no other information is present.

@nR

From what I can see on your screenshot, you have a similar situation as well.

[David A2]

I haven't figured out yet why discovery is ignoring my rules, but this is the probe that is updating the description field. If anyone more code-savvy than myself can interpret where it is populating that field that would help!

new ProbePostProcessor({

	/**
	 * Runs the probe instance
	 */
	process : function() {  
		related_data.tDataObj = {};

		// key (property name) is currentBlock + ':' + field name...
		var matchMap = {
			'1:Manufacturer'  : 'manufacturer',
			'1:Product Name'  : 'model_id',
			'1:Version'       : 'model_number',
			'1:Serial Number' : 'system_serial_number',
			'1:UUID'          : 'uuid_serial',
			'2:Serial Number' : 'baseboard_serial',
			'3:Serial Number' : 'chassis_serial'
		};
		var handleRegex = /.*DMI type ([0-9]+).*/;
		var valueRegex = /^\s*([^:]*)\s*:\s*(.*?)\s*$/;
		var currentBlock = -1;
		
		/**
		 *  Output for dmidecode will be in this format:
		 *    Handle 0x0107, DMI type 3, 6 bytes
		 *    Serial Number: VMware-42 08 4b d3 41 9e eb e3-5e fd 7e 7b 42 42 c0 66;
		 *    UUID: 42084BD3-419E-EBE3-5EFD-7E7B4242C066
		 *
		 *    Handle 0x0105, DMI type 23, 13 bytes
		 *    ...
		 *
		 *  The following code splits the output into blocks (around "Handle 0x").
		 *  A bit of optimization is done based on the fact that we only care about
		 *  DMI types between 1~3.
		 *  Skip processing on blocks with types that are not in this range.
		 *  If the type is between 1~3, we grab the field names that we care about and
		 *  save those in tDataObj.
		 */
		var blocks = output.split(/Handle\s0x/);
		for(var i = 0; i < blocks.length; i++) {
			var block = blocks[i];
			var mat = handleRegex.exec(block);
			if (mat) {
				currentBlock = parseInt(mat[1]);
				// we're only interested in blocks 1 through 3...
				if (currentBlock < 1 || currentBlock > 3)
					continue;
			}

			var values = block.split(/\n/);
			for (var j = 0; j < values.length; j++) {
				var value = values[j].trim();
				mat = value.match(valueRegex);
				if (!mat)
					continue;

				var fieldName = mat[1];
				var fieldValue = mat[2];
				var curName = matchMap['' + currentBlock + ':' + fieldName];
				if (curName == null)
					continue;

				// don't overwrite data we already have, as sometimes there are duplicate blocks with no data...
				if (related_data.tDataObj[curName] == null)
					related_data.tDataObj[curName] = fieldValue;
			}
		}
	}
});

[David A2 · Accepted solution]

In case anyone else runs into this, the UNIX classifier probe is writing an output to the description field (likely for use by subsequent probes). The reconciliation engine does not come into play during the classification phase of discovery. The 'fix' is to use patterns.

"Discovery via patterns will completely go through the IRE. With probes, only the

identification phase will go through the IRE. Probes executed in the identification phases

do go through IRE and probes executed in the exploration phase do not go through IRE

layer. The end result is that only a partial attribute of the main CI goes through IRE and

the rest (the entire main CI and all related CIs) do not."