Updated vRTVS Management Pack for ServiceNow

VMware introduced the ServiceNow Notification Plugin in vROps 7.5, giving customers the ability to send vROps Alerts to ServiceNow. We covered this and the subsequently released vRTVS Management Pack for ServiceNow (3.0) in a previous blog. The latest vRTVS Management Pack for ServiceNow (4.1) adds several key new features, we'll discuss two of them here:

1. Alert synchronization supporting Alerts, Events, and Incidents

2. CMDB population and synchronization

Formal Release Notes for this latest version can be found here. First, let's take a look at the higher level architecture.

The original ServiceNow Notification Plugin that comes with vROps converts vROps Alerts to ServiceNow Incidents. The latest vRTVS Management Pack for ServiceNow has the ability to convert vROps Alerts to ServiceNow Alerts, Events, or Incidents in ServiceNow. Once they are updated in either vROps or ServiceNow, those updates will be synchronized across both locations.

What does this look like in practice? Once you've installed the management pack, you'll configure the adapter.

There are several different fields available, all formally documented here. A few highlights:

1. ServiceNow Host - ServiceNow instance the adapter connects to.

2. Configuration File - Configuration File used by the adapter itself, this is the most important piece of the adapter. This is where you'll tell the adapter to what type of Alerts to sync and what type of CMDB sync you want to perform.

3. ServiceNow Proxy Host | ServiceNow Proxy Port - Giving the adapter proxy capabilities if necessary. The built-in ServiceNow Notification Plugin doesn't support proxys.

The configuration file is required by the adapter, it exists here:

 $VCOPS_BASE/user/plugins/inbound/servicenow_adapter3/work 

It's JSON and will look like something like this.

Several sample configuration files are provided out of the box in the following location:

$VCOPS_BASE/user/plugins/inbound/servicenow_adapter3/conf/config_samples

You can create your own configuration file based on these or point your adapter configuration to them by specifying the following in the adapter Configuration File field, like this.

Let's first explore the Alert Synchronization section of the configuration file. Taken directly from the documentation:

Alerting configurations for the alert-sync feature define what alerts will be synced between vROps and ServiceNow, and how they will be represented in ServiceNow. The three supported representations are INCIDENT (default), ALERT, and EVENT. Once the vROps alert is present in ServiceNow, the ServiceNow Management Pack performs the following additional features:

• If an alert is cancelled in vROps, the corresponding incident or alert in ServiceNow is closed.

• If an incident or alert is closed in ServiceNow, the corresponding alert in vROps is suspended. Alerts in vROps are generally triggered automatically by breaching thresholds. Because we cannot control this, if an incident or alert is closed in ServiceNow it should be due to the underlying issue being resolved. Thus, we suspend the Alert in vROps (for a configurable length of time) to allow the alert to resolve. If the threshold(s) is still breached when the alert suspend time has ended, the alert will re-trigger and reopen the ServiceNow incident or alert.

• If a synced vROps alert is on a vROps ResourceKind that is present in one of the resourceTypes sections above, the ServiceNow Management Pack will create a reference from the incident/alert/event cmdb_ci column to the CI representing the resource in ServiceNow. Note: A resourceType section can be created with empty groupTypes and hierarchies arrays for matching to a resource type, without creating any groupings and hierarchies.

• The ServiceNow Management Pack can be configured to watch a predefined set of incident/alert/event columns and display the current values in the corresponding vROps alert as a series of notes.

If alert sync is not desired, alertingConfigs can be omitted entirely, or an empty list can be used:

"alertingConfigs": []

If you wish to create ServiceNow Incidents (which is the default), your alertingConfigs stanza might look like this:

{
  "alertingConfigs": [
    {
      "callerId": "vROps Service User",
      "propagateAlertUpdates": true,
      "retrieveIncidentUpdates": true,
      "incidentElementsToRetrieve": [
        "assigned_to.name",
        "state",
        "cmdb_ci.sys_id"
      ],
      "incidentReopenState": "In Progress",
      "incidentCloseState": "Closed",
      "vropsSuspendMinutes": 30
    }
  ]
}

To explicitly call out the three ServiceNow types, adjust the serviceNowDestination field here to INCIDENT, ALERT, or EVENT.

{
  "alertingConfigs": [
    {
      "callerId": "vROps Service User",
      "propagateAlertUpdates": true,
      "retrieveIncidentUpdates": true,
      "incidentElementsToRetrieve": [
        "assigned_to.name",
        "state",
        "cmdb_ci.sys_id"
      ],
      "incidentReopenState": "In Progress",
      "incidentCloseState": "Closed",
      "vropsSuspendMinutes": 30,
      "serviceNowDestination": "INCIDENT"
    }
  ]
}

I've created a config file in my environment to do some testing, it looks like this.

{
 "alertingConfigs": [
  {
    "callerId": "vRealize Operations",
    "serviceNowDestination" : "INCIDENT",
    "category": "",
    "subcategory": "",
    "businessService": "",
    "contactType": "",
    "state": "",
    "resolutionCode": "",
    "resolutionNotes": "",
    "onHoldReason": "",
    "impact": "",
    "urgency": "",
    "retrieveUpdates": true,
    "serviceNowElementsToRetrieve":  ["state","work_notes"],
    "filters": {
      "scope": {
        "type": "objectTypes",
        "objectTypes": ["VirtualMachine"]
      },
       "trigger": {
         "type": "alertDefinitions",
         "alertDefinitions": []
       },
       "criticality": [],
       "alertStates": [],
       "alertStatus": [],
       "collectorOrCollectorGroup": ""
     }
   }
 ]
}

This is designed to send vROps Alerts to ServiceNow as Incidents. I'm sending as callerId "vRealize Operations" and I've filtered it down to VMs only via the objectTypes filter. Documentation for these fields can be found here.

vROps Alerts are on the left and their corresponding ServiceNow Incidents are on the right.

If you want to be a bit more descriptive with your callerId, adjust the config file and be sure there is a ServiceNow user with the same name. Mine looks like this.

As mentioned previously:

• If an Alert is cancelled in vROps, the corresponding incident or alert in ServiceNow is closed. Here I've canceled a vROps Alert and the corresponding ServiceNow Incident was closed.
  

• If a ServiceNow Incident/Alert is closed, the corresponding vROps Alert is suspended.
  

• If any of the default ServiceNow Incident fields (State, Assigned to, Priority, Urgency) get updated, those updates get sent back to the corresponding vROps Alert as Notes.
  

You can pull additional ServiceNow field updates back into vROps by adding them to the serviceNowElementsToRetrieve array in your configuration file. Here, you can see my updated config file, the ServiceNow Incident, and the associated vROps Alerts with Notes.

Now that we have vROps Alerts synced, let's do a CMDB sync by adding the following to your configuration file. Documentation can be found here.

"cmdbSync": {    
    "cmdbSyncMethod": "IRE_API",    
    "syncMode": "POPULATE_AND_DELETE_WHEN_NOT_EXISTING",  
    "objectIdentifierSource": "MOID",    
    "builtInTreeEnabled": true,    
    "customTreesEnabled": false,    
    "additionalColumns": {},    
    "nameFilter": {} 
 }

Currently, the only supported sync method is via the IRE_API. There are three sync modes available:

1. POPULATE_ONLY: Populates (and updates) the CMDB, but does not remove CIs.

2. POPULATE_AND_DELETE_WHEN_NOT_EXISTING: Populates (and updates) the CMDB and removes CIs that have been marked as Not Existing in vROps. If a vROps resource is Not Existing, it sets the operational status of its corresponding CI to 6 (retire).

3. POPULATE_AND_DELETE_WHEN_REMOVED: Populates (and updates) the CMDB and removes CIs that have been removed from vROps. If a vROps resource is Not Existing, it sets the operational status of its corresponding CI to 6 (retire).

There are several example configuration files available here:

$VCOPS_BASE/user/plugins/inbound/servicenow_adapter3/conf/config_samples

We'll use the moid_incidents_and_populate_only.json config file to get what we need. I've adjusted it to include our previous alertingConfigs array. As indicated in the documentation:

This configuration filters vROps alerts to the following ResourceKinds: VirtualMachine, ClusterComputeResource, Datacenter, Datastore, HostSystem. It creates ServiceNow Incidents for these vROps alerts and associates them with their CI if it is present in the CMDB. The mapping uses a combination of MOID and vCenter UUID as identifiers for all ResourceKinds.

Also, it syncs vROps resources to the CMDB. The MOID is used as the object_id for all CI Classes. This configuration populates the CMDB, and deletes resources from the CMDB when they are deleted from vROps.

You'll notice now, each ServiceNow Incident (generated by a source vROps Alert) has an associated CI.

Beyond this, we can perform custom mappings from vROps to ServiceNow via custom trees. They can be used to map objects from other vRTVS Management Packs to the ServiceNow CMDB, to map vSphere objects to custom ServiceNow CMDB objects, and more.

The vRTVS Management Pack for ServiceNow 4.1 is very powerful! What we've discussed here are just two of the main use cases. For more information on this management pack and others in vRTVS you can find us here.

Thanks to VMware Software Engineers Katherine Klinefelter and Kyle Rokos for consulting on this blog!