Server and Application relation not getting created.

HrishabhKumar
Giga Contributor

Thursday

Issue:

VM "HPG0000009499" is related to service, in svc_ci_assoc table, but corresponding server "hpg0000009499" is not.

vm1.png

 

 
 

Analysis:

1) VM "HPG0000009499" is discovered correctly, and it has all the tags required for tag-based mapping. i.e. applicationID, applicationName.

2) VM to Service, relation is created automatically in svc_ci_assoc table.

3) VM is part of the Service Map as well.

4) Most of the VMs and servers are tagged correctly, there is issue with few only.

 

Requirement:

server to service relation should also get created, and server should be a part of the service map as well. 

 

 

 

0 Helpfuls
  • 196 Views
3 REPLIES 3

Naveen20
ServiceNow Employee

Thursday

Try 

Business Rule on svc_ci_assoc — auto-propagates to the server whenever a VM gets associated.

Table: svc_ci_assoc | When: After Insert | Filter Condition: ci_id.sys_class_nameLIKEvm_instance

(function executeRule(current, previous) {
    // Find server related to this VM
    var rel = new GlideRecord('cmdb_rel_ci');
    rel.addQuery('parent', current.ci_id);
    rel.addQuery('type.name', 'Hosted on::Hosts'); // verify this in your instance
    rel.query();

    while (rel.next()) {
        var childClass = rel.child.sys_class_name.toString();
        if (childClass.indexOf('server') == -1) continue;

        // Skip if association already exists
        var dup = new GlideRecord('svc_ci_assoc');
        dup.addQuery('ci_id', rel.child);
        dup.addQuery('service_id', current.service_id);
        dup.query();
        if (dup.hasNext()) continue;

        // Create server-to-service association
        var assoc = new GlideRecord('svc_ci_assoc');
        assoc.setValue('ci_id', rel.getValue('child'));
        assoc.setValue('service_id', current.getValue('service_id'));
        assoc.setValue('ignore_errors', false);
        assoc.insert();
    }
})(current, previous);

For existing gaps, run this once as a background script (same logic but wrapped in a query on all VM-type svc_ci_assoc records).

One thing to confirm first — run this to get your exact relationship type name:

var r = new GlideRecord('cmdb_rel_ci');
r.addQuery('parent.name', 'HPG0000009499');
r.setLimit(5);
r.query();
while (r.next()) gs.info(r.type.getDisplayValue() + ' -> ' + r.child.name + ' [' + r.child.sys_class_name + ']');

Then update the type.name filter in the BR accordingly.

0 Helpfuls

HrishabhKumar
Giga Contributor
In response to Naveen20

Thursday

Hi @Naveen20  I don't want to build something new, just want to know why it not working of the mentioned server. For most of the server everything is working fine. 

I'm sure there is a mechanism which is working correctly for most of them. I'm just not sure what is that mechanism i.e. a BR, scheduled job, flow of anything else.

0 Helpfuls

Naveen20
ServiceNow Employee
In response to HrishabhKumar

Thursday

check these in order:

  • Business Rules on svc_ci_assoc — go to sys_script_list.do?sysparm_query=collectionSTARTSWITHsvc_ci_assoc^active=true and look for any insert/after BRs
  • Scheduled Jobs — search sysauto_script_list.do for keywords like svc_ci_assoc, service_map, or service_ci
  • Flow Designer — check for flows triggered by svc_ci_assoc or cmdb_rel_ci
  • Service Mapping patterns — if you're using Service Mapping/Discovery, the mapping engine itself may be creating these

2. Once you find it, check why this server is excluded:

For the working server (hpg0000009904 from your screenshot), look at the svc_ci_assoc record's Created by field — it says system. That tells you it was created by a system process (BR, scheduled job, or discovery), not manually.

Check the sys_audit or sys_history_line for that working record to see exactly what script or process inserted it.

3. Quick diagnostic for the failing server:

Compare the two servers side by side — the one that works vs hpg0000009499:

  • Is the VM-to-server relationship (cmdb_rel_ci) present for both?
  • Are the CI attributes identical (class, operational status, install status, etc.)?
  • Is the failing server marked as a duplicate or has a different install status?
  • Are the tags (applicationID, applicationName) on the server record itself, or only on the VM
0 Helpfuls