Persisting Multi-Level CI Classes in CMP via Discovery
Recently for a customer, we had a need to populate Security Group Rules under a Compute Security Group CI. Out of the box, we discover and populate the Compute Security Group CI. But we do not populate the Security Group Rule under each of the compute security group. In addition we do not even have CI class defined for this.
This article describes how to do it.
| For CMP CMDB persistence to work, we need the identification column to be called as 'object_id'. This is very important. By extending from Virtual Machine Object, you get this by default. This is some which we recommend as well. If you create your own column and called it 'Object ID', the platform will create it as 'u_object_id' and this column name will now work. We understand that it is a limitation and will fix it in a future release. |
Create a new CI Class - We created a new CI Class 'Custom Security Group Rule(u_cmdb_ci_security_group_rule)'.
The table looks like this :
The CMDB dependency relationship looks like this:
The response from Azure looks like this
We need to map the the data in the red rectangle to the u_cmdb_ci_security_group_rule CI Class.
Luckily for us, this information was already there in the payload of the Network Security Group in Azure. So the only work we have to do is to wire the response mapping for this.
The steps for mapping are simple.
The steps that are needed are:
1. Map the data in the red rectangle to the u_cmdb_ci_security_group_rule class.
2. Map defaultSecurityRules to the Network Security Group response mapping.
Map the data to the u_cmdb_ci_security_group_rule class.
We did a direct mapping for the security group rule. something like this:
You would see that the object_id is the identifier. There are two additional identifiers, one for Security Rule being contained by security group. And one for Security Group hosted on Logical Datacenter. Also we created the Datasource name as 'Azure Sec Group Rule API'. In this we are saying how this CI class is being populated.
Map defaultSecurityRules to the Network Security Group response mapping.
You will see that we have added an entry for correlating the above mapping to the existing Compute Security Group mappings.
- The datasource is set to 'Azure API'.
- The CI class is set to 'cmdb_ci_compute_security_group.
- The source field is 'properties.defaultSecurityRules'. This is the node where the security rules are present as an array.
- The 'Datasource for mappings' is mapped to 'Azure Sec Group Rule API' and 'Relationship CI class' is mapped to our 'u_cmdb_ci_security_group_rule' class. By doing this, we are instructing that the datasource 'Azure Sec Group Rule API' mappings should be used for population.
- With that mapping persisted, we are done.
That is pretty much it and you will see that the new CI class is being populated properly.
|
For discovering a new resource type, normally we will add a step to Azure Datacenter resource block's Discover operation. But in this case the data for resource type was already part of the response which was coming in Compute Security Group discovery. So we just added additional response mappings. Otherwise we would have added a step in the Discover operation. |
This is how it looks like after the discovery:
The update set which does all the above work except the table definition is here : https://developer.servicenow.com/app.do#!/share/contents/4708895_cmp_discover_security_group_rule?t=PRODUCT_DETAILS
