IRE Identifier Entry via Dot-walking

[Willie]

I was told by ServiceNow Support that identifiers should be OOTB as much as possible. So I am scoping out utilizing the Hardware Rule instead of the Server Rule I created.   Has anyone been successful identifying CIs via dot-walking, table extension? My goal is to target identifier host_name from hardware table. 

If a CI exist in a subclass (example cmdb_ci_server is a child to cmdb_ci_hardware), how do I target?

Input:

Output:

The host_name identifier entry only works if I explicitly call out the CI via ‘Primary Configuration Item’. This is not a good way to identify CIs.

Input:

[Vikram Reddy]

Hey @Willie,

You don't actually need to dot-walk a reference field for this, it's already built into the identifier entry. Look at your fifth screenshot: under the cmdb_ci_hardware identification rule there's an OOB entry at priority 10 with Identifier = cmdb_ci_hardware, Search on table = Server, and Criterion attributes = Host name. That field is the exact mechanism you're after: it lets one entry sitting on the parent Hardware identifier search a subclass table (cmdb_ci_server) directly, using a real column on that table (host_name), no dot-walk needed. Your custom entry using ref_cmdb_ci_server.host_name as the criterion attribute fails because the IRE payload's values map only resolves actual columns that exist on the item's own className, not a dot-walked path through a reference field, which is exactly why the simulator threw MISSING_MATCHING_ATTRIBUTES followed by ABANDONED.

Your later simulation proves it out. When you sent className cmdb_ci_server with a lookup entry of className cmdb_ci_server and host_name: bob1, it resolved cleanly to identifierEntrySysId 13713ac7... (that same OOB Host name entry) and came back as a clean UPDATE against the correct sysId, no Primary Configuration Item hand-holding required. So the fix is:

• Deactivate your custom hardware-level dot-walked entry, it's redundant and non-functional
• Send payloads under the correct subclass className (e.g. cmdb_ci_server) rather than cmdb_ci_hardware whenever the source data is server-specific
• Use the lookup array to resolve or relate to an existing CI by a criterion attribute, not a flat dot-walked key in values

Thank you,
Vikram Karety
Octigo Solutions INC

[Willie]

I was able to target the CI if I manually reference the CI to itself, which is not a sustainable way to manage IRE and CMDB:

Output:

input:

 var payload =  {
  "items": [
    {
      "className": "cmdb_ci_server",
      "values": {
        "short_description": "test-target-IRE-UPDATE"
      },
      "settings": {},
      "sys_object_source_info": {},
      "lookup": [
        {
          "className": "cmdb_ci_server",
          "values": {
            "host_name": "bob1"
          },
          "settings": {},
          "sys_object_source_info": {},
          "lookup": [],
          "related": []
        }
      ],
      "related": []
    }
  ]
}
 


var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI('ServiceNow', input);
gs.print(JSON.strinify(output));

[Willie]

Thank you for your response. After I deactivated the hardware rule and just run the server rule, priority 10. IRE attempts to insert a new record, instead of updating the target:

Input:

Output:

Target: