WaveMaker - handling SSL certificates

In the past some people ask for the SSL certificate handling of WaveMaker. This is mostly caused by WebService integration. With my new vCO 5.1 appliance I had the problem again. After generating a new certificate for the vCenter Orchestrator here I connected the WaveMaker and had to learn a hard lesson: no more HTTP API connection with SOAP! Checking the cause in the browser I could see that there is always a HTTPS redirection :)

So I had to import the certificate of the vCenter Orchestrator like this:

sudo keytool -import -alias vco51.vcloud.lab -file /Users/cjohannsen/Desktop/vco51.vcloud.lab -storepass changeit -keystore /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security/cacerts 

As you can see the WaveMaker uses the JDK certificate store. So I had to export the vCO certificate (i used Firefox) and import it in the certificate store. The store password is originally "changeit". After a WaveMaker restart I tried to connect the https path:

https://vco51.vcloud.lab:8281/vmware-vmo-webcontrol/webservice?wsdl

and everything was fine.

With this its really easy to access the SOAP API. Next post will show how to connect the REST API with WaveMaker :)

vCloud Director - get chain length and consolidate a vCloud:VM

As you may know it isn´t possible to consolidate a VM as an organization administrator. In most environments the customer gets an Org (Cola for example) and can deploy vApps etc. but isn´t able to consolidate a vCloud:VM (i use the vCO syntax for explicit wording).

If you want to provide this function in a customer portal, with WaveMaker for example, you need to check the chain length and when the user decides the consolidate method has to be called.

I build a workflow:

The workflow has three steps: determination of the chain length, user decision to consolidate or not and the consolidate call itself. The first part (getChain script) looks like this:



myVm.updateInternalState();

System.log("VM name: "+myVm.name);

var doc = new XML(myVm.toXml());
default xml namespace = doc.namespace();
var n8 = new Namespace("http://www.vmware.com/vcloud/extension/v1.5");

System.log("ChainLength: "+doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength);

var chainLength = doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength;

if(myVm.vmStatus.value != 8){
throw("VM is not powered off!");
} 

As you can see I update the state of "myVM" (vCloud:VM) and setting the variable "chainLength" (number). The chain length is used as external input for the user interaction, so it´s possible to decide based on the count.

After the submission the myVm.consolidate() method is called and the workflows waits for it.

With my host.login() workflow you can combine the Org based login with the consolidation of vCloud:VM´s :)

vCO 5.1 appliance - how-to fix the localhost.localdom certificate

Yesterday I updated my local lab to the brand new vCloud Suite 5.1. The most interesting thing for me was the vCenter Orchestrator appliance and it´s REST API. So after the deployment the appliance came up (I had to disconnect/connect the cd-rom while the certificate was generated) and the typical configuration interface was available.

After some normal tests I had some smaller problems:

1. the logs windows doesn´t show the logs
2. the browser tells me that the ceritifcate isn´t okay

My colleague Christophe Decannini points me in the right direction with the logs problem: the time between appliance and client was different. After changing the time and timezone everything was fine.

The second problem wasn´t this easy to solve. First I created a new certificate with the standard configuration service method:

After that I checked the certificate in my browser and was surprised that the certificate name was localhost.localdom.

A short console test also shows that the common name wasn´t right.

After a few more tests Burke Azbill mentioned his blog article and what should I say... even the linux appliance has the problem (article). So i started the following steps:

1. check for the certificate store

2. delete the old "dunes" ceritficate

3. generate new certificate

4. restart the vCenter Orchestrator appliance

After the restart I checked for the certificate again and everything was okay. Now I can test the new REST API :)