Best practice to follow for CMDB integration with tools which does not pass via IRE?

[Suggy]

Hello Experts,

There are some tools in ServiceNow STORE app which are API based integrations/other normal type integrations.

Basically they are not SG connectors, so they dont pass via IRE.

In such scenario, are there any guidelines/best practices to be followed as we are missing the IRE 🙂

TIA!!!

[Pratiksha]

You need to use IH ETL for this. It will call IRE by default.

[CMDB Whisperer]

My understanding is that CMDB integrations must use the IRE in order for them to be certified as an official store app.  This was a policy introduced shortly after the launch of the ServiceNow Store if I recall correctly.  I would contact ServiceNow Support or the Vendor for an explanation.

Worth noting, some CI classes like Business Applications do not have Identifiers and therefore if your application is focused exclusively on those classes, it would be a valid exception to the IRE policy for CMDB integrations.

[Suggy]

Hi @CMDB Whisperer  there are few CMDB apps in Store which does not use IRE. One such example is this - https://store.servicenow.com/sn_appstore_store.do#!/store/application/90ba7ce0dbd1e700727673278c9619...

Still, back to my question, in such scenarios where vendor built apps does not use IRE, are there any best practices to follow in such cases. If you have any insights on this, pelase do share.

Thank you...

[CMDB Whisperer · Accepted solution]

I mean I'm not trying to be sarcastic when I say that the best practice is to contact the vendor and ask why they aren't using IRE, and consider maybe not using their app if they are not, and building your own integration with that source.

But assuming that you're still not convinced and you're willing to go forward with this integration, I think I should start by pointing out what the accepted "best practice" was considered once upon a time (and you'll still find it cited from time to time).  That you should use the correlation_id field to store the unique identifier of the foreign record (e.g. LogicMonitor) that was imported.  The main problem with this is that it's only half of the equation.  It tells you the record identifier but not the source system that contains that record, and therefore assumes that there is one and only one external source you can use.  As long as it's the only external source not using IRE, this may be fine, but if you have multiple sources not using IRE, then they cannot all use the same correlation_id field so you'll probably need to create multiple custom fields to store the various foreign keys.  But even after you do this, the problem is that it's not going to play nicely with those sources that are using IRE.  As a result this can lead to data collision and/or duplication, i.e. your CMDB is likely to suffer from more and more data integrity issues over time.

Beyond that I don't really know how to answer what are the best practices, because I would need more context.  Best practices in what scenario?  Bottom line is that the best practice is to use IRE for all data sources in the CMDB, because that is the only way you will get a view of the conflicting sources.  For IRE to work properly for any one source, all sources need to be using it.  Otherwise the source just isn't playing nice with others.