Article

How to Integrate ServiceNow with vRealize Orchestrator

Far and away the most common challenges in ITIL are simple adoption and compliance; it seems that the more hoops an organization adds to its change management process, the more unauthorized changes it sees executed. But what if ITIL compliance became the default, and every build generated CRQ’s, CMDB entries and relationships, and even incident tickets for build failure, all without human intervention?

In part 1, we covered the basic structure and use cases of REST. In part 2, we’ll dive into the waters of integrating ServiceNow with your VMware infrastructure using vRealize Orchestrator.

The low hanging fruit in most organizations is “informational” or standard changes. Many changes take place without being recorded because the time spent on paperwork can exceed the time spent on the task by a factor of 10X or even 100X. Automating the creation and approval of informational changes for activities such as VM builds can transform this process from a painful or ignored roadblock into a valuable “stack trace” for your entire environment.

Here’s a sample change request created automatically in ServiceNow by a VM build request in our lab:

Equally useful, here’s a CMDB CI entry for that same VM—note that currently blank fields could be populated via custom properties to tie the VM to a business application as well as a user, team, and infrastructure:

Now, your company’s CMDB probably has dozens more fields than I’ve shown here, but I’ll share a secret with you: Any custom property from your build process can be scraped by vRealize Orchestrator and inserted into this record.

The Glue: Binding your Provisioning to ServiceNow with REST

By feeding this workflow, the inputs from a standard ExternalWFStubs State Change workflow, we can guarantee that our CMDB gets updated with any VM details we need, at any point in the provisioning process.

These processes can obviously be reversed. We can create changes in ServiceNow to retire a VM as easily as to build one and can update any record once we’ve created it, enabling us to update, retire, and delete CI records from our CMDB.

But one point in lifecycle management is clearly missing: What about incident and problem management?

Incident and Problem Management

Incident creation works the same as any other record in ServiceNow, we pass in a JSON with the fields we wish to populate:

incidentJson = {
 “impact”: “3”,
 “urgency”: “3”,
 “category”:”software”,
 “subcategory”:”application”,
 “description”: “Workflow”+strFailedWorkflow+” failed with ERROR CODE: “+errorCode,
 “active”: “true”,
 “short_description”: “Workflow Failure”,
 “comments”: “ERROR CODE: “+errorCode,
 “cmdb_ci”:{
  “link”:snowURL+”/api/now/v1/table/cmdb_ci/”+vrealizeSysId,
  “value”:vrealizeSysId
 },
}

Here we can see the corresponding incident created in ServiceNow:

At this point, we’ve demonstrated that we can integrate with ServiceNow, but the more technically inclined readers in our audience are likely to be asking, “How?”

On the surface, the solution is simple. We simply create the following three “Helper” workflows in vRealize Orchestrator, parameterized to manipulate records in different tables in ServiceNow:

  • Create Record
  • Get Record
  • Update Record

These flows can then be consumed in “Wrapper” workflows to pull data from a variety of sources before creating or updating our ServiceNow records.

As an example, our CMDB CI workflow above retrieves the properties of a VM built with vRealize Automation and uses them to create the payload for a new CMDB entry. It then takes the new record’s sys_id from ServiceNow and updates the VM entity with a new custom property for later use.

As always, the devil is in the details. Want to see what this might look like in your own environment, including integrating specific other technologies? Come into the AHEAD Lab and Briefing Center, and we’ll work with you to demo these capabilities.


Deep dive into your automation and orchestration strategy with this briefing.