CMDB Transforms: More than Meets the Eye

ServiceNow CMDB

If you want to have any hope of effectively managing and improving your systems, you’ll need to know exactly what your current IT environment looks like; what assets exist, accurate (current) configuration data, and a multitude of other metrics.

An accurate configuration management database (CMDB) empowers you to easily understand the IT environment at your business and have greater insight into asset management, compliance, and configuration management.

A couple versions ago, ServiceNow brought us the Identification and Reconciliation Framework with the express purpose of reducing duplicates within the CMDB. The framework also makes it possible to enforce which source of data was authoritative in updating our existing CMDB records.

I can tell you from experience that the modern CMDB is a mighty ocean with many tributaries and without good boundaries, any river will eventually become a swamp.

Which is why treating your ServiceNow CMDB as your single system of record for IT and pairing it with Service Mapping to become service-aware is vital to avoiding a swamp of data, versus a single, clear, insightful stream. And duplicates in your CMDB are not only bothersome in terms of presentation, they will actually cause issues when you begin to implement Service Mapping.

Despite the overall power of the CMDB, if you’re a big coding developer like me, chances are you were not impressed by this Identification and Reconciliation Framework when it rolled out.

We’d become accustomed to scripting complicated Transforms that could (try to) make these decisions. No help needed – Thanks, we got this. Plus, who wanted to rework all those Transforms from yesteryear? There were plenty of other fires burning to deal with the hassle.

Man, was I missing out!

Finding the Value in CMDB Transforms

There is some real value here. The Identification & Reconciliation Framework leverages all the juicy CI Identifiers that we have per class in the CMDB to help us separate the existing records from the new ones. It also allows us to decide that data coming in from Discovery or Service Mapping takes precedence over data coming in from some other data or monitoring tool. Your boss will be glad to know that using this completely OOB and the supported engine will reduce the time to value spent in writing the Transforms for client after client, data source after data source.

After you realize the benefits of the framework, there is no turning back.

I would like to offer an improvement though. The CMDBTransformUtil, while handy, lacks the flexibility required when dealing with larger data sets, (nobody likes tiny imports).

Consider a feed from the CA Spectrum where there are possibly new servers coming in the payload. Servers that live in various tables such as cmdb_ci_linux_server, cmdb_ci_osx_server, and others. The CMDBTransformUtil reads the Map object from the current Transform and aims all the records at the same table. We can write multiple Transform Maps, but you should know that each Map creates a copy of each row of data. 30k rows of data would soon become 100K or more with just a few maps.

Enter the CMDBTransformUtil2 class. Using Object.extendsObject, we can teach the CMDBTransformUtil how to handle a variable target class, just like any old Transform Map would:

The buildInputPayload function is where we need to overload another function with the same name which can pay attention to our target.sys_class_name value, which is set from a Transform Field Mapping Script like this one:

The Field Mapping Script targeting the sys_class_name field could look something like this:

Despite the simplicity, there is a point of caution that you should keep in mind. Use care when you design a CMDB Transform Map to point to the cmdb_ci_hardware table. If a device is already in the CMDB in a more specific class, when your transform matches it by hostname or serial number, you may inadvertently downgrade the device to the hardware class.

Remember if a device is downgraded, any data from fields specific to the previous class are lost. At baseline, all SN instances will allow this behavior. There’s a system property you should change to keep this from happening:

With this new class, which respects the value of the target.sys_class_name, we can script our onBefore Transform Scripts to handle our import using the Identification and Reconciliation engine:

ServiceNow cmdb transforms

With these improvements, it’s much easier to manage a large number of data sources aimed at your CMDB.

What Else?

You can also do it with smarter Transform Maps, while also avoiding dreaded duplicate Configuration Items. If you have old Transform Maps that are not using the CMDBTransformUtil – which means they aren’t using the Identification and Reconciliation Engine – then you’re not leveraging the full power of the ServiceNow platform to keep itself healthy.

It’s certainly worth the effort to do things the right way. If you’re just getting started with CMDB Transforms then you will be glad you’ve learned how to do them cleanly and avoid duplication and incorrect updates.

Now that you can trust your CMDB to be a single, complete, system of record for your business processes, it’s time to consider what other improvements ServiceNow could make at your business. Whether its further development of your CMDB, Service Mapping, Discover, or even IT Business Management, it’s time to start planning your continued ServiceNow roadmap. Download our complete template now, then reach out to one of our ServiceNow experts to get started.

ServiceNow Roadmap