Posts Tagged CMDB

Update ServiceNow CMDB As Part Of IaaS Machine Life Cycle

In a previous post I explained how to update a CMDB as part of IaaS machine lifecycle. The example I used was a generic MSSQL Server table. In this blog post I want to give a more concrete example, namely ServiceNow.

The use case, as I have built it, is using vCO and the REST API’s of ServiceNow and is doing the following: When the machine is requested and provisioned from vCAC portal by the user: A Configuration Item (CI) record is automatically and immediately created in ServiceNow CMDB with the machine attributes coming from vRealize Automation (VM name, IP, CPU Count etc…) The Configuration Item “State” property in ServiceNow CMDB is shown as “On” since the machine exist and is of course running. When the machine is destroyed from the vRealize Automation portal by the user: The same previously created CMDB CI record is not deleted but instead its “State” property is now updated to say “Retired” instead of the previously “On” state. This way, we still have a record of the deleted machine in the CMDB while the “State” property is telling us if the machine exist or not.

Steps needed:

1. In vCO add your ServiceNow host as a REST HTTP Host, for example:


2. Add 2 REST operations:

-A POST one for CreateVM in CMDB: /api/now/table/cmdb_ci_vm_instance?JSON=&sysparm_action=insert

-A PUT one for UpdateCIBysysid in CMDB: /api/now/v1/table/cmdb_ci_vm_instance/{sys_id}

The result in vCO inventory should look as follows:


3. Decide which properties you want to send from vRealize Automation to ServiceNow CMDB as CI attributes. In my workflow I am sending a combination of both OOTB properties like “VirtualMachine.Memory.Size” and custom ones I have attached to the IaaS bluepring like “cost” for example or “location”.

The first scriptable task in the vCO workflow needs to reflect what you want to send to ServiceNow for example:

var hostName = vmentity.getProperty(“VirtualMachineName”);

var vmProps = vmentity.getLink(vcacHost,”VirtualMachineProperties”);

for each (var prop in vmProps) {
var propertyName = prop.getProperty(“PropertyName”);
var propertyValue = prop.getProperty(“PropertyValue”);
if (propertyName == “VirtualMachine.CPU.Count”) {
var cpuTotalCount = propertyValue;
if (propertyName == “VirtualMachine.Memory.Size”) {
var memoryTotalSize = propertyValue;
if (propertyName == “VirtualMachine.Disk0.Size”) {
var diskTotalSize = propertyValue;
if (propertyName == “VirtualMachine.Admin.UUID”) {
var uuid = propertyValue;
if (propertyName == “VirtualMachine.Network0.Address”) {
var ip = propertyValue;
if (propertyName == “__Legacy.Workflow.User”) {
var owner = propertyValue;
if (propertyName == “VirtualMachine.Network0.DnsSuffix”) {
var dns = propertyValue;
if (propertyName == “cost”) {
var daily_cost = propertyValue;
if (propertyName == “VirtualMachine.Network0.MacAddress”) {
var mac = propertyValue;
if (propertyName == “location”) {
var location = propertyValue;

Note: “vmentity” is input parameter of type “vCAC:Entity” coming dynamically from vRealize Automation during provisioning. “vcacHost” on the other hand we set in advance to point to our vRealize Automation server (previously known as vCAC).


1. Create VMware VM Instance CI – Uses this POST Rest call:


2. Update VMwareVM Instance CI by sys_id- Uses this PUT Rest call:


You will notice the POST and the PUT REST operations use different cmdb tables in SNOW (cmdb_ci_vm_instance and cmdb_ci_vmware_instance) but for me that didn’t create any issue, it worked well this way. In the POST/insert workflow I grab the sys_id from the CI to be stored in vRealize Automation as a custom property on the blueprint so that when I destroy the VM in vRealize Automation it knows which CI to update in SNOW with the status “Retired”. So make sure you have attached/defined a custom property called “sys_id” to the relevant vRealize Automation IaaS blueprint.

Now we need to associate these 2 workflows with a vCAC external Stub. More information about vCAC external stubs and how they can be associated with vCO workflows and triggered at runtime can be found here in Chris Alleaume’s excellentt blog: Chris’s Blog

Make sure you associate your “Create_VMware_VM_Instance_CI” workflow with MachineProvisioned stub and  “Update_VMwareVM_Instance_CI_by_sys_id_(1)” workflow with MachineDisposing stub as described in Chris’s blog.

So now in ServiceNow when a machine is requested and provisioned from the vRealize Automation Portal, a new CI is created with the “On” state:


And when the same machine is deleted from the vRealize Automation portal, the State is now set to “Retired”:


Job Done.

Here are the workflows attached:


, , , , , , ,


Update A CMDB As Part Of IaaS Machine Life Cycle

A good way of demonstrating VMware vCloud Automation Center 3rd party integrations is around a CMDB use case. The most obvious example will be to write to a DB table once the machine has been provisioned and then once again when it has been disposed of.

I am using vCAC 6.01 with the embedded vCO so I have the vCO SQL plugin already installed but if you are using an external vCO most probably you will need to installed the SQL plugin. It can be downloaded from here: Download

Next steps:

1. Make sure you have a DB to connect to and a DB table to write to. I have create a demo DB called ‘CMDB’ in an instance of SQL Server 2008 Express. Inside that DB I have a table called ‘machines’ with the following fields:


2. In vCO run the workflow ‘JDBC Workflow Generator’. This will help you form the JDBC URL you will need for the next step. As I am using SQL Express my URL looks like this:


3. In vCO run the workflow ‘Add a Database’. Use the JDBC URL generated in the previous step. If you still encounter difficulties then check that TCP/IP is enable: Launch the SQL Server Configuration Manager Click on the “Protocols for SQLEXPRESS” node, Right click on “TCP/IP” in the list of Protocols and choose, “Enable” Check that Static Port 1433 and NOT the Dynamic port is configured: Click on the “TCP/IP” child node, You will notice an entry on the right panel for “IPAll”, right click on this and select, “Properties” Clear out the value for “TCP Dynamic Ports” and Give a TcpPort number to use when making remote connections, i.e., “1433”.

4. In vCO run the workflow ‘Add a table to a Database’. Point to the table you have created before.

5. In vCO run the workflow ‘Generate CRUD workflows for a table’ and point to the table you have added to the DB in the previous step. You will need to specify in which vCO folder you want this workflow to be created. The workflow name will be something like “Create Active Record for ‘machines’ ” where ‘machines’ is the name of the DB table we have been working with all along.

6. Create a net new vCO workflow called ‘CMDB add machine Record’ for example. In it have a scriptable task to unwrap vCAC object properties and then call the “Create Active Record for ‘machines'” workflow to update the CMDB table:


I will add the workflow as an example at the end as a reference. In the workflow ‘General’ tab make sure you set the vCACHost parameter to point to your vCAC server as explained in my previous blog post 

7. Create a net new vCO workflow called ‘CMDB update machine Record’ for example. In it have a scriptable task to unwrap vCAC object properties as previously mentioned and then call the ‘Execute a Custom query’ workflow to update the CMDB table. The scriptable task in this workflow will look like this:

var timestamp = new Date();
System.log(“The timestamp is: ” + timestamp);
time = timestamp;
machine_state = state;
hostname = machine_name;
query = “UPDATE machines SET state= ” + “‘” + machine_state + “‘” + “,” + “timestamp= ” + “‘” + time + “‘” + “WHERE machine_name= ” + “‘” + hostname + “‘” + “;” ;
System.log(“Executing query ” + query + ” on database ” + );
rowsAffected = database.executeCustomQuery(query);
System.log(“Rows affected: “+ rowsAffected);

As you can see all we want to update is the machine state and timestamp columns with the state of the machine (now destroyed) and the time it has been destroyed.


In the workflow ‘General’ tab make sure you set the vCACHost parameter to point to your vCAC server as explained in my previous blog post  and also make sure the ‘database’ parameter is pointing to CMDB DB you are working with.

8. Now we need to associate these 2 workflows with a vCAC external Stubs. More information about vCAC external stubs and how they can be associated with vCO workflows and triggered at runtime can be found here in my previous blog post 

Make sure you associate your ‘CMDB add machine Record’ workflow with MachineProvisioned stub and  ‘CMDB update machine Record’ workflow with MachineDisposing stub as described in my previous blog post 

Job Done.

For your convenience the two vCO workflows mentioned above can be downloaded from here:


Yuval T

, , , ,