Home > Blogs > VMware vCenter Orchestrator Blog > Tag Archives: HTTP-REST

Tag Archives: HTTP-REST

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. 


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.



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.








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.






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.


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:






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:


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



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:


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.



Master of the integration – conquer VMware vCloud Director blocking tasks with the powerful vCenter Orchestrator plug-ins

One of the upcoming features of VMware vCloud Director is Blocking Tasks (call-outs). This enables a system administrator to configure many operations to block. They can be ublocked later by another application or can expire after a timeout. These blocking tasks generate AMQP messages that can be used to automate actions over them. This blog post shows vCO flexing muscles over blocking tasks. Doing this requires several plug-ins: AMQP, HTTP-REST, ActiveDirectory and Mail.

Whenever a vApp is created by an user in the vCloud Director the task is suspended and the user's manager receives a notification mail providing link for approval of the operation. When he approves, the vApp creation task continues in the vCloud Director. This is achieved by using a different plug-in on every step. AMQP plug-in is used to handle the blocking tasks notification messages. The HTTP-REST plug-in is used to communicate with the VMware vCloud Director over its RESTful interface. Active Directory is needed to find the user’s manager in the company's active directory database. Finally, the approval email is sent using the Mail plug-in. Webviews are used to build a simple web-based interface that the manager uses to approve or reject the vApp creation.

At the end of this article you can find links to a vCO package containing theexample and a video demonstrating the scenario. Jump right to the video at the end or read the details below describing  some technical aspects.

The message sent by the vCloud Director for the pending vApp creation is handled first by the AMQP plug-in. The next few lines of JavaScript show how to configure the subscription for the message. Note how the routing key is constructed. The detailed strucutre of the routing key is described in the vCloud Director documention.


After its execution this script will create a new Subscription element in the AMQP plug-in inventory:


This subscription is ready to be used for a policy that will listen for vApp creation messages:


The workflow is started by the policy on every message and does the rest of the work:


The user must define the vCloud Director as a REST host in the inventory:


And then use it in the scripts to build the request URL:


The VMware vCloud Director REST API responses are XML documents but handling them is easy with E4X (ECMAscript for XML):


When the manager follows the web link in the notification mail he is brought to a web page showing again the request details enabling him to take an action on it:


Behind the scene the approve and reject buttons are handled by a script that answers the user interaction of the blocked workflow. When decision is taken the workflow continues and notifies the VMware vCloud Director to resume or cancel the pending task.

To get your hands dirty with this demo follow the link to the package that contains the example. It won’t work out of the box because the AMQP broker and the VMware vCloud Director configuration must be updated to match yours. Also the message handling policy must be manually created since policies cannot be distributed in a package.

Here is a video demonstrating the whole scenario: