Home > Blogs > VMware vCenter Orchestrator Blog


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

 

One thought on “Provision a vCloud Automation Center Service from ServiceNow’s Service Catalog

  1. Pingback: Managing Cloud Services with your Existing Service Catalog | VMware Cloud Management - VMware Blogs

Comments are closed.