Virtual server response processor example
Summarize
Summary of Virtual server response processor example
TheCreateVirtualServerResponseProcessorscript is a default response processor in the Cloud Provisioning and Governance application for ServiceNow. It automates the creation of virtual machine configuration items (CIs) in the CMDB when AWS virtual servers are provisioned. This script processes the cloud provider’s response and translates it into a new record in thecmdbcivminstancetable.
Show less
Key Features
- Standardized Input Parameters: The script uses required parameters such as the cloud provider response, service account ID, datacenter ID, and request context to ensure accurate CI creation.
- JSON Parsing: It parses the cloud response JSON to extract essential virtual machine details including hardware ID, node name, state, CPU, memory, disks, network interfaces, IP address, and assignment information.
- Identification Logic: The processor includes robust identification criteria to prevent duplicate CIs by matching on service account, datacenter, and virtual machine IDs.
- Attributes Population: Attributes for the virtual server record are populated directly from the response to fields in the CMDB instance record, ensuring accurate and comprehensive data capture.
- Reference Relationships: It establishes references to related CIs such as the OS template and compute template by identifying their object IDs, linking these dependencies in the CMDB.
- Network and Storage Associations: The script handles relationships with network interfaces and attached storage, enriching the virtual server CI with relevant infrastructure context.
- Final CMDB Update: After assembling all relevant data and relationships, the script pushes the compiled model to the CMDB and returns a JSON string representing the newly created or updated virtual server CI.
Practical Implications for ServiceNow Customers
By using this response processor, ServiceNow customers can:
- Automate the accurate creation and updating of AWS virtual server CIs in their CMDB during cloud provisioning, reducing manual effort and errors.
- Ensure consistent and complete data capture for virtual machines, including hardware, networking, storage, and OS details.
- Maintain CI uniqueness and integrity by leveraging identification criteria to avoid duplicates.
- Establish clear relationships between virtual servers and their underlying infrastructure components, improving CMDB reliability and usability for downstream IT operations.
This example script demonstrates best practices for customizing or creating similar response processors to support other cloud providers or CI types within ServiceNow’s Cloud Management framework.
The Create_Virtual_Server_Response_Processor script, which is available by default in Cloud Provisioning and Governance, is the response processor that handles the creation of AWS virtual machine CIs.
Create Virtual Server
The Create_Virtual_Server_Response_Processor resource processor script is available by default on the Virtual Server resource block. Its job is to create a virtual server record in the Virtual Machine Instance [cmdb_ci_vm_instance] table when a new virtual server is provisioned.
function processResponse(response, cloudServiceAccountId, ldc, correlationId,step, requestorContext) {
This brings in the response from the cloud provider and the important information, such as the account ID, that is required for the new CI that the system can create. All of these parameters are required for all response processors.
Line 10 parses the response into JSON so that the system can process it. The information is held in the vmResponse variable:
var vmResponse = global.JSON.parse(response);
Whenever you create or edit a response processor, you must know which inputs are required for the CI type. Line 11 handles one of the necessary inputs, the hardware ID, that the CMDB record requires:
var hardwareId = vmResponse.hardwareId;
Line 39 shows the information that is required for the system to identify the new virtual server and related CIs, so the information can be put into the CMDB. In this case, the service account object ID identifies the account associated with the virtual server, the datacenter object ID identifies the datacenter in which the virtual server lives, and the virtual machine instance object ID identifies the virtual server itself. This identification code block prevents the creation of duplicate CIs.
var vmInfo = {
"cmdb_ci_vm_instance": {
"validator": "virtual_machine_create_update_validator",
"validator_overrides": {},
"identification": {
"cmdb_ci_cloud_service_account": {
"criterion": {
"object_id": cloudServiceAccountId
}
},
"cmdb_ci_aws_datacenter": {
"criterion": {
"object_id": ldc
}
},
"cmdb_ci_vm_instance": {
"criterion": {
"object_id": vmResponse.nodeId
}
}
},Attributes are populated into the fields on in the cmdb_ci_vm_instance table. These attributes are defined in line 61:
"attributes": {
"name": vmResponse.nodeName,
"object_id": vmResponse.nodeId,
"state": status_map[vmResponse.state],
"dns_suffix": vmResponse.dnsSuffix,
"cpus": vmCPUs,
"memory": vmMemory,
"disks": vmResponse.volumes.length,
"disks_size": "",
"nics": vmResponse.networkInterfaces.length,
"terminated_on": "",
"termination_protection": "",
"ip_address": vmPubIPAddr,
"assigned_to": reqContext.userId,
"assignment_group": reqContext.groupId
},
References to other CIs can also be included in the response processor. In this case, the OS template that the virtual server is based on is identified by first identifying the object ID of the service account and the datacenter along with the actual OS template.
"references": {
"cmdb_ci_os_template": {
"identification": {
"cmdb_ci_cloud_service_account": {
"criterion": {
"object_id": cloudServiceAccountId
}
},
"cmdb_ci_aws_datacenter": {
"criterion": {
"object_id": ldc
}
},
"cmdb_ci_os_template": {
"criterion": {
"object_id": imageIdTrim
}
}
},The following code block adds the object ID of the OS image to the attributes list so that this information can be populated into the virtual server CMDB record.
"attributes": {
"object_id": imageIdTrim
}
This code block performs additional identification on the Compute template (the hardware type) and then add it to the attributes:
"cmdb_ci_compute_template": {
"identification": {
"cmdb_ci_cloud_service_account": {
"criterion": {
"object_id": cloudServiceAccountId
}
},
"cmdb_ci_aws_datacenter": {
"criterion": {
"object_id": ldc
}
},
"cmdb_ci_compute_template": {
"criterion": {
"object_id": vmResponse.hardwareId
}
}
},
"attributes": {
"object_id": vmResponse.hardwareId,
"name": vmResponse.hardwareId
}
}Additional code sections make the relationship with network interfaces and identify any storage attached to the virtual server.
This mandatory code block pushes the data to the CMDB and returns the JSON string:
cloudModelString.push(vmInfo);
return global.JSON.stringify(cloudModelString);