CMDB-Export (aka Atrium Adapter)

by Simon Woodward | 05 Apr 2007 | Permalink | Everything Else

We’re in the closing stages now of releasing the first Integrations Group project, snappily named the BMC Atrium CMDB 2.0 Adapter version 1.0.  There’s been plenty of activity around telling people what this piece of software is (ie. an adapter to Atrium whose mappings are fully configurable), but not much time has been spent on what I think is the most significant thing about this release: the mapping engine.

Eighty percent of the development of the Atrium adapter was spent not actually dealing with Atrium at all.  This time was spent in building an exporter framework that had a properly configurable transformation engine built into it - a transformation engine that was agnostic to the destination system.  If you look at the mapping files that ship with the adapter you’ll see that they actually describe a source Foundation nodeset and the transormation to do to turn that nodeset into the destination schema.  The destination schema is described as a set of CI types that have attributes and the relationships between them; it’s a completely generic expression of the remote schema.

The internal implementation of the exporter uses a generic interface (called the “sink") to write data to the destination, and we could implement a sink for any destination system that is modelled around the idea of types, attributes and relationships.  This includes other CMDBs, SQL databases, CSV, XML and probably others too.  The work to implement the sinks obviously varies from sink to sink, but won’t be too horrendously difficult - and the huge advantage is that the same mapping file format will work for all of them.

Just to highlight some of the features of the mapping engine:

• It properly supports the capabilities of our Foundation data store:
  
  
  
  • You specify the source nodeset with a Foundation query.
  
  
  • You can map one-to-many relationships (for example, one Host to many NetworkInterface nodes) by returning sequences from your query.
  
  
  • You can use the mapping engine to write the remote identifier back to Foundation’s data store into a an attribute of your choice.  For example, after doing an export to Atrium, all the Host nodes that were exported have an attribute called “AtriumID” that contains the Atrium ID of the host.
  
  


• Subsequent exports to the same remote database are handled correctly - new items are inserted while changed items are updated.  If you’ve used the above mentioned feature to return the remote ID to the Foundation datastore then the engine can update the existing item even if it’s changed out of all recognition.


• Identification of item on the remote system is configurable - you specify the fields to use to do the identification.


• You can use an item’s relationship to another item as an aid to identifying it, even if it’s otherwise identical to a different item.  For example, if you have an item representing a computer’s operating system license with a name of “Windows XP Professional”, all of its attributes will be identical to the other OS items called “Windows XP Professional” - and you’ll have as many of them as you do computers running that OS.  How do you, at export time, differentiate?  The mapping engine permits you to say that your OS item is identified both by its Name field and by its relationship to a “ComputerSystem” item.


• There is a variable that you can use in the Foundation query to only export items that are new or have changed.  The string “${lastExportedTime}” in the query will be replaced with the date that the export was last run, and this can be used to compare to a node’s “modified(#)” date.  The following query will return only those hosts that have changed or been added since the last export:
  search Host
where parseTime("${lastExportFinished}") < modified(#)
show hostname, name