Home > Blogs > VMware vCenter Orchestrator Blog > Tag Archives: ServiceNow

Tag Archives: ServiceNow

Provision a vCloud Automation Center Service from ServiceNow’s Service Catalog

By Jennifer Galvin

One of our customer’s was recently exploring using ServiceNow’s Service Catalog to initiate a provisioning request to vCloud Automation Center.  There are several ways customers have requested vCloud Automation Center integrate with ServiceNow.  These integrations can be bidirectional – ie, vCloud Automation Center -> ServiceNow, by generating a service ticket and updating the CMDB and invoking vCAC Services from the ServiceNow Catalog, and ServiceNow -> vCloud Automation Center, using our orchestrator to receive the request and invoke our own pre-built integrations to our suite.  While it is still our best practice that vCAC serve as the main customer interface for self-service, this post looks at how we successfully integrated ServiceNow’s Service Catalog to provision services in vCloud Automation Center. And it also demonstrates how vCAC services could be invoked from any Service Catalog, using vCenter Orchestrator.

To see more examples of integrations, check out the great blogs at vCOTeam.info and vCACTeam.info.

Special thanks to Tom Bonnano, Chris Decanini, Eric Hardcastle, Michael Steward, and Derek Reinhard for helping me with this integration and the vCAC Plugin.

Create the Workflow in vCenter Orchestrator to receive the ServiceNow request

In order to initiate the request to a third party system, your customer has to create a form to collect inputs and create a workflow to pass those inputs to the third-party system.  Because every request takes a custom created form, the inputs (and how they are us

First, we created the master workflow that ServiceNow would invoke. I recommend you start very simply – for us, we only added a single variable, Hostname,  which would receive a value from ServiceNow, and show that it passed all the way through to the server that was provisioned by assigning that hostname. 

image001

To do this we dragged the “Provision a virtual machine from a blueprint (Deprecated)” workflow from /Library/vCloud Automation Center/Infrastructure into our workflow, and assigned all of its values to attributes. ed) will differ from service to service.  We opted to integrate ServiceNow directly to vCenter Orchestrator’s SOAP API, so we could leverage the 6.01 vCAC Plug0in and use that to invoke provisioning in vCloud Automation Center.  This would also make editing and maintaining these workflows much easier due to vCenter Orchestrator’s rich object model and allow us to get updated workflows directly from VMWare (instead of having to re-write our own).

 We assigned everything upfront to hard-coded values to complete the test (with the exception of the “custom” attribute, which is an array that contains each “customProperty=value” entry.  To change the hostname of the provisioned server, we would have to insert “hostname=<something>” into this array.

We then used a scriptable task in front of that workflow, to create the “custom” array that would eventually contain our one custom property.
We made a simple script that pushed the formatted value onto this array so it was ready to go.

image002

 

Make sure your workflow has one input that prompts the user, called “Hostname”.  Now, when you think you’re ready, run this workflow, input a hostname, and see if it provisions a server!  Make sure this works before moving on to the next step.

Create the Workflow in ServiceNow that calls vCenter Orchestrator’s SOAP API

Link the form in ServiceNow’s Service Catalog to the workflow operations that invoke vCenter Orchestrator.  NOTE:  we found some limitations in ServiceNow’s SOAP message operations for some WebServices, where SOAPActions cannot be blank.  Please see the Troubleshooting section for more information.  We chose to use a Powershell operation in the ServiceNow workflow to call the SOAP endpoint (as it passed the SOAPAction header properly), and instead opted to pass the variables into this script.  This allowed us greater control to override the SOAP client behavior (and to ignore self-signed certificates, as you’ll see below).

In ServiceNow, you should specify the workflow to be run from the form, and the workflow should invoke a Powershell operation.

We started with a completely hard-coded script, which would call the service and pass information.

image003

 

 

 

 

 

image004-1

This could then be modified to substitute the hard-coded values to the ServiceNow ${variable} syntax, which ServiceNow would replace with the form values on execution time.

Because this was a test environment and all of the certificates were self-signed, we ended up adding a line to the top of the script to allow Powershell to trust certificates that were not signed by their local CA chain:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

And that’s it!  Now, when the form is submitted, it provisions through to vCAC, setting the hostname to the one you hard-coded in the Powershell.

image005

 

 

 

Troubleshooting

Testing vCenter Orchestrator using SoapUI

To ensure we could communicate with vCenter Orchestrator successfully, I used a program called SoapUI to send requests and to view the headers and responses. It’s a very nice client and will automatically generate all the soap actions for you. I used this to simulate API calls with my vCenter Orchestrator first, to get the inputs right.

This is what was generated, and I simply filled in the blanks to test if it worked.

image006

Testing Powershell Outside of Servicenow

It was important to first test the commands being issued from the ServiceNow MID server to determine if we had connectivity to vCenter Orchestrator, and if it would accept our self-signed certificates. I recommend you invoke Powershell from your local ServiceNow MID server (which will receive the command from ServiceNow) to see if it works:

image008

 

 

 

image007-2

Displaying What ServiceNow is Sending vCenter Orchestrator

We found some limitations in ServiceNow’s SOAP message operations.  vCenter Orchestrator’s SOAP messages specify that a blank SOAPAction header should be passed, but the SOAPMessage operator in ServiceNow cannot have a blank “SOAPAction” field.  The request generated will omit the header “SOAPAction” if the action is blank (instead of passing a blank quoted string).  vCenter Orchestrator considers missing headers a malformed request, and will output a 500 error in the server request log.   You can see errors in the test scenarios of this SOAPMessage test:

image008

We discovered that the operation SOAPMessage in ServiceNow must contain a SOAPAction, or else it will omit this header entirely.

image009-2

 

We know from our previous testing with SoapUI we require that a blank header be sent, and SoapUI allows us to see what that header should be:

image010

So we really need to understand what’s being sent by ServiceNow, it’s obviously not being correctly generated.  You can examine any requesting service to see if the correct headers are being sent by starting a Mock Service on the server that has SoapUI installed, and sending the ServiceNow request there.  Below is a screenshot of a mock service running on port 8088, where I print out the headers and content of the request, using a groovy script within the OnRequest field, located here:  https://github.com/momecca/SoapUI

This will help you understand what is being sent, and compare it to other client’s and the requests they generate.

image011

 

Important vCenter Orchestrator Plug-in Updates

With the recent vCenter Orchestrator 5.1 and vSphere 5.1 availability, it’s obviously important to ensure that not just individual products but all of your integrations are up-to-date.

Besides the already released plug-ins for vCenter Server 5.1 (built-in) and vCloud Director 5.1, we are are glad to announce the availability of several plug-in updates to make your entire vCloud suite up-to-date:

1. The vCenter Update Manager plug-in has been updated to support version 5.1 and vCenter Single Sign On. This plug-in is essential for scanning and remediating vSphere inventory objects against baselines.

2. The vCO Multi-Node plug-in has been updated to support vCO 5.1, vCenter Single Sign On, and the new vCO REST API capabilities to leverage the remote invocation of new systems types such as actions and packages.  What’s more, this new version also provides better performance and corrects some previous defects.

3. The vCO Plug-in for vSphere Auto Deploy 5.1 supports… vSphere Auto Deploy 5.1!  Need we say more?

4. The vCO Plug-in for Microsoft Active Directory 1.0.2 provides support for vCenter Single Sign On and contains an import fix for concurrent workflow execution.

5. The vCO AMQP Plug-in 1.0.2 offers significant performance improvements and fixes a known issue with the vCO server restart.

6. The vCO Plug-in for vCenter Server 5.0.2 contains important performance improvements for customers who are running vCO with vCenter Server 5.0.

  • vCO Plug-in for vCenter Update Manager 5.1: download
  • vCO Multi-Node Plug-in for 5.1: download
  • vCO Plug-in for vSphere Auto Deploy 5.1: download
  • vCO Plug-in for Microsoft Active Directory 1.0.2: download
  • vCO AMQP Plug-in 1.0.2: download
  • vCO Plug-in for vCenter Server 5.0.2: download

As always, be sure to check VMware Solution Exchange for a complete list of plug-ins available from VMware and our partners.  That’s your best place to find the latest integration solutions such as the ServiceNow plug-in recently published by InterraIT.

Cheers!

The vCO Team