--- sourceDocument: Australia IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # Virtual server response processor example # Virtual server response processor example {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Virtual Server Response Processor Example TheCreateVirtualServerResponseProcessorscript, included by default in ServiceNow's Cloud Provisioning and Governance for the Australia release, automates the creation of AWS virtual machine configuration items (CIs) in the CMDB. This response processor runs upon provisioning a new virtual server and ensures accurate and duplicate-free CMDB records in thecmdbcivminstancetable. Show full answer Show less ## How It Works * The processor receives the cloud provider's response along with critical context parameters such as the cloud service account ID, datacenter ID, and requestor context. * The response JSON is parsed to extract required inputs, including hardware ID, VM instance ID, and other VM attributes. * It builds an identification block to uniquely identify the virtual machine and related CIs (cloud account, datacenter) to prevent duplicates. * The script populates VM attributes like name, state, CPU, memory, disk count, network interfaces, IP address, and assignment details into the CMDB record. * References to related CIs such as the OS template and compute (hardware) template are identified and included, linking the virtual server to these entities in the CMDB. * Additional code handles relationships with network interfaces and attached storage, ensuring comprehensive representation. * Finally, the script pushes the assembled VM information to the CMDB and returns a JSON string confirming the update. ## Practical Benefits for ServiceNow Customers * **Automated CMDB Population:** Simplifies maintaining an accurate and up-to-date CMDB by automatically creating and updating virtual server CIs upon provisioning. * **Accurate CI Identification:** Uses multiple identifiers to prevent duplicate records, preserving CMDB integrity. * **Comprehensive CI Details:** Captures essential VM attributes and related CI references, enabling better visibility and management of virtual infrastructure. * **Extensibility:** The script structure allows customization to accommodate additional attributes or related CIs as needed. ## Key Takeaways ServiceNow customers leveraging Cloud Provisioning and Governance can rely on the **CreateVirtualServerResponseProcessor** to seamlessly integrate AWS virtual machine provisioning data into the CMDB. Understanding this script helps customers ensure that their virtual infrastructure is accurately reflected and linked within their CMDB, supporting effective IT operations and governance. 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 {#response-processor-example__section_q5y_xt3_v2b} 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. All response processors have this first line with these common parameters: 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. 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 the system requires to identify the new virtual server and related CIs for storage in 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 is identified by 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. This information is then 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);