Virtual server response processor example

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
  • Summarize
    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, automates the creation of AWS virtual machine configuration items (CIs) in the CMDB. This processor runs when a new virtual server is provisioned, ensuring that the virtual server record is accurately created and associated within the CMDB.

    Show full answer Show less

    Key Features

    • Unified Response Handling: The script receives cloud provider responses along with essential identifiers such as the cloud service account ID, datacenter ID, and correlation ID.
    • JSON Parsing: It parses the cloud response to extract vital virtual machine details required for the CMDB record.
    • CI Identification and Duplication Prevention: Uses unique identifiers (object IDs) for the cloud account, datacenter, and virtual machine instance to accurately identify CIs and prevent duplicate records.
    • Attribute Population: Populates the cmdbcivminstance table with key attributes like name, state, CPU count, memory, disk count, network interfaces, IP address, and assignment details based on the provisioned VM's data.
    • Reference Linking: Establishes relationships to related CIs such as OS templates and compute templates by identifying and linking their object IDs, ensuring comprehensive configuration data.
    • Extended Relationships: Includes network interfaces and attached storage details to provide a complete view of the virtual server environment.
    • CMDB Update and Response: After assembling all data and relationships, the script pushes the VM information into the CMDB and returns a JSON string confirming the processed data.

    What This Enables ServiceNow Customers to Do

    • Automatically create and maintain accurate AWS virtual machine records in the CMDB upon provisioning.
    • Ensure consistent and reliable identification of virtual server CIs without duplication.
    • Maintain detailed and linked configuration data, including hardware templates, OS images, network interfaces, and storage, supporting better asset and service management.
    • Integrate cloud provisioning responses seamlessly into the CMDB, enhancing visibility and governance of cloud resources.

    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.

    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 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);