When configuring new classes in Service Manager, you always need to specify a key property. This property must have a unique value for all instantiated objects of that specific class. Often a key property is created by using an id value that increments automatically. This makes sense in many situations, however when constantly importing objects from other management systems it can make more sense to change tactics and use other properties as key properties – if needed also more than one
I created some post in the past that talk about using id-bases key properties. Check out this post to get an understanding how auto incrementing key properties can be used:
Sometimes it can make more sense to use non-incrementing properties as key properties. This can be easily configured in the Authoring Tool or directly in XML. If needed you can also define multiple key properties. Think about this scenario:
- You want to create your very own application class
- You want to synchronize applications with your own method (SCORCH runbook) to the CMDB
- You don’t want to build any logic into the synchronization process
This could be one way to go. Create a new class and define the needed properties. In this example I added only 3 properties (name, vendor and version) and I marked name and version both as a key property. None of them are auto incrementing properties). Than means that objects with exactly the same name and version can only exist once in the CMDB.
After the MP is sealed and imported, you can start synchronizing objects to the CMDB. This could be done using a SCORCH runbook. In this example I will use simple CSV import procedures to demonstrate the scenario. I will not go into any detail here because this has been discussed earlier:
So this is my xml format file:
This is my sample data file:
After the import is complete, the objects can be displayed using a simple view.
As you can see, the instances has been created using the values from the data file. The display name property has been automatically populated with values from the two key properties. The key properties are automatically marked as read only on the generic form.
Now what happens when our “connector” runs again? I changed the data file a little bit: I added a new row and changed the version value of 2 existing rows.
Now I import again. Guess what happens? The new row will create a new object. Because I changed the key property value on 2 rows this will also add new objects. So 3 new objects in total. That makes sense.
Now, what happens if I change a value that is not a key property and import the CSV again? You know it: it will not create new objects but update the existing ones.
This example showed how to import data using CSV files. In a real world it would be more comfortable to use a SCORCH runbook. The runbook could connect to SCCM and read out all Applications, then write it to the CMDB. With a clever key property configuration the runbook needs no logic that makes sure every application is only written once to the CMDB because the data model takes care of that and data consistency will be better with that approach. This is of course only a simple example, but it demonstrates how valuable and important key properties are or can be.