đđ...TRICK_AD_105...
Often we need to validate a reconciliation rule in ServiceNow CMDB after its activation before we ask the source system to send the data involving source system team.
A quick way to do that using our good old friend 'background script' itself calling SN's identificationEngine api. Its cool, isn't it?
Here is how the steps we can follow to do so.
Step 1: Suppose we have a reconciliation rule for Windows Servers where 'Alteris' has the higher order to update all the attributes except RAM than 'ServiceNow Discovery' having lower order (We know that lower order means higher precedence). This means 'ServiceNow Discovery' can update all the attributes except RAM when the earlier source of information is 'Alteris' for a windows server.
Step 2: For example we have the below windows server created by Alteris. We try to update all the attributes using 'ServiceNow' source (meaning ServiceNow Discovery).
a) Before reconciliation run SS.
We can validate the rule now using simple background script if all the attributes except RAM are updated.
var payload =
{
"items": [
{
"className": "cmdb_ci_win_server",
"lookup": [],
"values": {
"name": "WinServer1",
"os": "Windows 2019 Datacenter",
"os_version": "10.0.17763",
"ram": "8,200",
"short_description": "Updated by ServiceNow",
"serial_number": "ec2bf90e-17b3-c4f6-2a8e-6f5a9a42407a"
}
}
],
"relations": []
}
var jsonUtil = new JSON();
var input = jsonUtil.encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI('ServiceNow', input);
gs.print(output);The console log shows that the RAM update was skipped.
Let's verify the windows server in the table as well that except the RAM value everything should be updated and the new discovery source is now 'ServiceNow'.
b) After reconciliation run SS.
đđ
Thanks,
Animesh Das
Happy learning and sharing!
You may mark this helpful as well if it helps you.
