Establishing CI relationships through integration & automation without using Discovery

[GoBucks]

My organization has begun populating our ServiceNow CMDB with servers and some infrastructure devices.  We are very new to this particular journey even though our instance is very old.  We are currently doing this by custom scripted REST APIs in ServiceNow-- We do not currently have the Discovery product.

My questions are around CI relationships.

1. Without Discovery, what are suggested methods or best practices to do this in an automated way?
2. We've thought about establishing an API that could insert records into the cmdb_rel_ci table itself.  What are thoughts on this method?
3. Regarding servers & racks, specifically, we also thought about extending Hardware or Computer with a reference column that references Racks.  Then when a server CI gets this field populated, a BR or Flow could actually update the cmdb_rel_ci table accordingly in the background.  Thoughts?
4. We've seen how a hardware model contains a Height field, and I'm not sure when this data is leveraged in any way, but is there a way to show that a particular CI is not only in a certain rack, but also a way to show which rack units that CI occupies? (ie, this CI is in rack units 1-3 of rack #4. This other CI is in rack units 5 & 6 of rack #4).

Thanks in advance.

[SwarnadeepNandy]

Hello @GoBucks,

1. Without Discovery, one suggested method to populate CI relationships in an automated way is to use the ServiceNow IntegrationHub, which allows you to connect to external systems and data sources via REST APIs, SOAP web services, JDBC connections, and more. You can create custom flows and actions to retrieve and update data from these sources and map them to your CMDB CIs and relationships. For example, you can use the IntegrationHub to get data from AWS, Azure, VMware, or other cloud providers and create CIs and relationships for your cloud resources
2. Another possible method is to use a custom scripted REST API to insert records into the cmdb_rel_ci table, as you mentioned. This method requires more coding and testing, but it gives you more flexibility and control over the data and logic. You can use the GlideRecord API to access and manipulate the cmdb_rel_ci table in your script. However, you should be careful with this method and follow the best practices for scripting in ServiceNow, such as avoiding hard-coded values, using proper error handling, and testing your script in a sub-production instance before deploying it to production.
3. Regarding servers and racks, extending the Hardware or Computer class with a reference field to Racks is a reasonable approach. You can then use a business rule or a flow to update the cmdb_rel_ci table based on the value of this field. However, you should also consider the impact of this change on other processes and applications that use the Hardware or Computer class, such as Discovery, Asset Management, or Service Mapping. You may need to update or customize these processes and applications to accommodate the new field and relationship.
4. As for showing the rack units that a CI occupies, I don’t think there is a built-in way to do this in ServiceNow CMDB. The Height field in the Hardware Model table is used for calculating the total height of a rack, but it doesn’t specify the exact position of a CI within a rack. You may need to create a custom field or table to store this information and link it to the cmdb_rel_ci table. Alternatively, you may want to look for third-party solutions or integrations that can provide this functionality.

Hope this helps.

Kind Regards,

Swarnadeep Nandy

[SwarnadeepNandy]

Hello @GoBucks,

If you find my answer solves your question, please mark my response correct, so that it may help other community users as well.

Best Regards,

Swarnadeep Nandy