Automate and scale using vCenter Orchestrator

Tag Archives: SOAP

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.

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.

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:

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.

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.

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.

The vCenter Orchestrator gifts season started a few months ago with the general availability of vCO 5.5. The compelling release was announced just in time to share the vCO momentum at VMworld. Along with the amazing new features introduced, VMware continues with a lot more presents.

This year the holiday magic brings to vCenter Orchestrator users several updates, product integrations and learning gadgets that make automation with vCO more powerful than ever.

1. VMware has just announced the GA of VMware vCloud Automation Center 6.0(vCAC 6.0). The extension and creation of XaaS is done using the vCAC Advanced Service Designer which allows you to seamlessly leverage any vCO workflow and convert it to a catalog item or day 2 operation, available as a service in the vCAC Self-service portal.

2.vCO CLI is the code name of the new debugging extension which will not only facilitate all experienced vCenter Orchestrator users and also helps the newcomers to programmatically explore the rich vCO ecosystem through interactive command shell. Access to the vCO plug-in’s inventory is integrated into the tool UI for easy navigation to the integrated solution objects.

3. Our super powerful and generic HTTT- REST and SOAP plug-ins are now able to support proxy configurations and assure security compliance of your automated solutions.

4. The long awaited vCO Powershell plug-in 1.0.3 is updated to support Powershell 3.0 inventory and is fully backward compatible with your existing scripts.