Call Workflows from outside

0

How to find Inventory Objects when calling vCO Workflows via the SOAP API

When calling an Orchestrator workflow from outside via the SOAP-API, things get dirty if your workflow have input parameters (see details here: http://www.vcoportal.de/2011/06/updated-calling-vco-workflows-from-powershell/ ). And things get really dirty, if the input parameter is an Inventory Object (like a Virtual Machine, provided by the vCenter Plugin).

The reason for that:
Before you can finally call the actual workflow, you have to get the vCO-internal ID of the object, usually by calling other API-methods before. In the vCO WebService documentation you can find following flow-chart, I marked the step we’re talking about:

Depending on what information the workflow caller has, you can call the findForId, or the find method with an xpath-expression. (expecially when working with the vCenter-plugin, always remember: The managed object Id in vCenter or the name of the Virtual Machine is not necessarily unique in vCO, because you always can have connections to multiple vCenter-Hosts!)

Thanks to David (@creativeview) and Igor a full example in Powershell:

$vcoWS = New-WebServiceProxy -Class VCO -Namespace VCO -Uri http://mycoolvcoappliance:8280/vmware-vmo-webcontrol/webservice?WSDL
#find the workflow
$workflows = $vcoWS.getWorkflowsWithName("Start virtual machine and wait", "vcoadmin" , "vcoadmin")
#find the virtual machine
$result = $vcoWS.find("VC:VirtualMachine", "xpath:name='TheVM-Name'", "vcoadmin" , "vcoadmin")
if ($result.TotalCount -gt 0)
{
#$result
$finderResult = $result.Elements[0]
$stringObjectRepresentation = $finderResult.DunesUri
#Write-Host $stringObjectRepresentation
}
$workflow = $workflows[0]
# print out input Parameters
$workflow.inParameters
# generate Array with Input PArameters (WorkflowTokenAttribute - Objects)
$inparams = @()
# fill the array, one entry for each input parameter
$inparams += New-Object -TypeName VCO.WorkflowTokenAttribute
$inparams[0].name = "VM"
$inparams[0].type = "VC:VirtualMachine"
$inparams[0].value = $stringObjectRepresentation
# Exectue workflow
$workflowToken = $vcoWS.executeWorkflow($workflow.id, "vcoadmin" , "vcoadmin", $inparams)
(be careful with the ‘ and ” surrounding the xpath-expression, depending on which programming language you use)

See the full discussion in the forums (some Java lines included as well 🙂 ):
http://communities.vmware.com/message/1889504#1889504

My original example how to call vCO Workflows via Powershell (with plain data types for input only :oops:):
http://www.vcoportal.de/2011/03/powershell-vco/

You can also find some examples about this in the vco-examples-package, more information how to get started with this:
http://www.vcoportal.de/2011/08/sample-webservice-client-for-vco/

And an unofficial tip at the end: Rumors are that the next major release of vCO contains a new REST-based API, so don’t spend too much time learing this legacy stuff, if you don’t need to…

0

Using Wavemaker as Web-Frontend for vCO

UPDATE 23. Nov. 2011: Additional Reference: Christian Johannsen posted a great step-by-step example for Wavemaker & vCO on http://mighty-virtualization.blogspot.com/2011/11/vco-wavemaker-your-cloud-webservice.html

There are different ways to create a web-based frontend for Orchestrator:

  • Webviews (included, provide integrated finder for inventory objects BUT old, hard to learn, deprecated, don’t bother to start with…)
  • Perspectives (based on webviews, very easy to use, way to go for quick-wins)
  • build your own (call Workflows via the SOAP-based API of Orchestrator)

(for more details, see this post)

Now, rumors are out there for a long time, it seems that Wavemaker is a hot candidate as main technology for the web-based stuff in future (it was mentioned at VMworld and in the forums… Yohooo!).

The Video

To get started, see following screencast…
Disclaimer: Starting at 6:30 it gets very dirty! Do not let your children nor your VMware Support Guy watch this unattended, and only try this at home! :mrgreen:

Wavemaker as Web-Frontend for VMware vCenter Orchestrator – Sneak Preview from Joerg Lew on Vimeo.

(I used the current 6.4.2 BETA of Wavemaker against vCO 4.1, but should work as well with slightly different versions of both components…)

So, why is Wavemaker a perfect fit (The GOOD…)?

It allows to to create nice-looking websites with a real bunch of logic without the need for tooooo much knowledge about web-development. (Orchestrator allows to create complex automation for your complete IT-Infrastructure without the need for tooooo much knowledge about software development)

It defines the information flow between different elements via a parameter binding semantic. (How do you pass information through a workflow in Orchestrator??)

You can drag&drop content elements from the palette to your actual website, and program additional logic in JavaScript (in the vCO you can drag&drop…. Well, you get the point…)

It uses the same platform. (see the dirty end of the video 😯 ), so a good integration is possible.

It’s the same company. (<EVILMODEON>So if VMware learned something from the  **yourAdjectiveHere** acquisition of Dunes some time ago, this time they get synergy earlier!!!<EVILMODEOFF>)

Drawbacks (The BAD…)

As external system, your wavemaker frontend has to call workflows via the API. So it is some effort to pass input parameters to the workflow, and it is a real bunch of effort (you don’t use “pain-in-the-ass” in a public blog :-?) if your workflow needs inventory objects as input.

So, in the current version you are bound to the features, the “usability”, and the limits of vCO’s current SOAP-API.

The Future (NOT ugly, quite the opposite!)

Two things on the horizon might make the Wavemaker<=>vCO-Integration perfect in future:
First, a new API in a future version of vCO could make the usage of inventory-objects as inputs easier;
Second, a bunch of pre-built vCO-related elements in the Wavemaker Palette could make the development of the web-frontend easier (compare it to the idea, not the complexity and not-documentation, of the vCO-related Tapestry objects in Webviews)….
=> Go vCO-Team! Go Wavemaker!

References

To get started with Wavemaker and the vCO-SOAP-API, see following links:

…and:

The way shown in the video using the SOAP-interface directly with a WebService-Variable in Wavemaker is not the only way (and maybe not the best one for every use-case). You can also create your own Java stubs (see the examples-zip in the Orchestrator Documentation), and use a “plain old” JavaService Variable against them in Wavemaker.

Summary

So in general, despite some hurdles due to the limits of the current SOAP-API, Wavemaker allows you to create good looking webinterfaces for Orchestrator Workflows. And it’s absolutely worth to dig into it, because this seems to be THE technology for webbased vCO-Access in the future.

0

A WebService-Client for vCO: Running the samples

VMware vCenter Orchestrator provides a SOAP-based Web-Service API, which you can use to start and monitor workflows from an external System. (This can also be used to create a webbased Client for vCO with something else than Webviews, see a detailed discussion here)

For a quick-start VMware provides a fully-functional Java-based Example-Client in the vco-samples.zip. In this post You will see how to build and run these examples.

You need:

  • A working Orchestrator Server
  • The Java Development Kit installed on Your Desktop
  • Ant
  • The vco-samples.zip, downloadable from the vCO-Documentation-Homepage

Prepare:

1. Download and install Ant (Don’t forget to set the environment variables JAVA_HOME, ANT_HOME and add the \bin-directories to your PATH!)

2. Download and unzip the vco-samples package.

3. Open a console, change to the webservice-example directory and run ant.

Use ant to build the examples

4. Edit the samples.properties-File and insert the connection details to Your vCO-Server:

5. Now you can run the Inventory.bat to check if the Sample-client can access the vCO-Server as expected (You sould see an “Ascii-Art – Representation of Your vCO’s Inventory):

(If something goes wrong here, it might be hard to read the error-messages. Double-check your connection-settings (including correct username/password) in the sample.properties!)

6. Most of the other samples in this Client access (hard-coded) Workflows. So you have to import the bundled Package to your vCO-Server: Open the vCO-Client, click on the small drop-down-Menu of the Packages-section, select “Import package…“, and import the com.vmware.samples.webservice.package from the WebServiceSample-Directory:

You should see a couple of new Workflows beeing added to your Workflow-Library:

7. Now you can run the other .bat-Files to Run a Workflow for instance (watch the vCO-client: You should see the new WorkflowToken appear!):

8. In the Example-client (built to samples.jar in step 3.) there are more calls, not all of them are a directly runable via a .bat-File. So for Your convenience you can copy the Inventory.bat to e.g. Samples.bat, and edit & replace the com.vmware.client.Inventory to com.vmware.client.%1 at the end of the (single) line. This allows you to call the other examples via the .bat instead of a long call with all the classpath-String.

To test, run Samples.bat FindAllByType (which should give you a list with all the VC:VirtualMachines in your Inventory):

A complete List with all examples:

  • FindAllByType
  • GetWorkflowEcho (broken, because of an hardcoded VC4:VirtualMachineGuestOsIdentifier … (you see: the examples-package contains some outdated stuff 😛  )
  • GetWorkflowOutput
  • Inventory
  • LaunchWorkflow
  • LaunchWorkflowWithInput

10. Now You can start examine, how the things work (or why not :mrgreen:  ) by digging into the sourcecode of the examples, which can be found in src/com/vmware/client:

Have fun! 😎

0

updated: Calling vCO-Workflows from Powershell

It was long on the TODO-list, now I got an reason (http://communities.vmware.com/thread/316038?tstart=0):
Extending the Powershell-script that calls vCO-workflows with input and output-parameters.

When executing the workflow, you have to specify an array of WorkflowtokenAttribute-Objects, which can be created in the namespace of the Webservice-Proxy:


# Connect to vCO and generate Proxy $vcoWS (-Class and -Namespace for easy stub-object generation later
 $vcoWS = New-WebServiceProxy -Class VCO -Namespace VCO -Uri http://192.168.215.176:8280/vmware-vmo-webcontrol/webservice?WSDL
 ...

# generate Array with Input PArameters (WorkflowTokenAttribute - Objects)
 $inparams = @()

# fill the array, one entry for each input parameter
 $inparams += New-Object -TypeName VCO.WorkflowTokenAttribute
 $inparams[0].name = "inputString"
 $inparams[0].type = "String"
 $inparams[0].value = "Hello World"

# ... and exectue (use $null instead on $inparams if Workflow has no input parameters
 $workflowToken = $vcoWS.executeWorkflow($workflow.id, "vcoadmin1" , "VMware2010", $inparams)

...

A comparable array of WorkflowTokenAttribute-Objects which contains the Output-Parameters of the workflow can be returned by


# get Output-Parameter, when workflow has finished #($wftResults is again an array of WorkflowTokenAttribute
$wftResults = $vcoWS.getWorkflowTokenResult($workflowToken.id, "vcoadmin1", "VMware2010")
$wftResults

the missing link: How to create Stub-Objects from scratch…
the hint: http://stackoverflow.com/questions/4196523/render-ssrs-report-with-parameters-using-soap-in-powershell

See the full updated example here:
http://www.vcoportal.de/examples/powershell-vco/

0

PowerShell & vCO – Call Orchestrator Workflows from PowerShell

UPDATE 6. January 2012:
For an example how to provide inventory objects as input parameters, see this post:
http://www.vcoportal.de/2012/01/how-to-find-inventory-objects-when-calling-vco-workflows-via-the-soap-api/

Execute vCO-Workflow with Powershell:
Via the WebService-API you can execute vCO-workflows automatically. And Powershell 2.0 has a built-in Client for WebServices. So it’s straight forward to start an workflow within a Powershell-Skript:


# Connect to vCO and generate Proxy $vcoWS (-Class and -Namespace for easy stub-object generation later
 # Verbindung zum vCO herstellen und Proxy $vcoWS generieren
 $vcoWS = New-WebServiceProxy -Class VCO -Namespace VCO -Uri http://192.168.215.176:8280/vmware-vmo-webcontrol/webservice?WSDL

# print out result (in every ...)
 # Ergebnis ausgeben (in jedem Schritt...)
 $vcoWS

# Get all Methods of the webserviceProxy
 $vcoWS|get-member|where { $_.MemberType -eq "Method" }

# Find Workflows with name "demoWorkflowWithStringInput" (returns an array!)
 # Workflows mit dem Namen "demoWorkflowWithStringInput" finden (gibt ein Array zurück)
 $workflows = $vcoWS.getWorkflowsWithName("demoWorkflowWithStringInput", "vcoadmin1" , "VMware2010")
 $workflows

# pop first Workflow from resulting array
 # ersten Workflow aus dem Ergebnisarray holen...
 $workflow = $workflows[0]
 $workflow

# print out input Parameters
 $workflow.inParameters

# generate Array with Input PArameters (WorkflowTokenAttribute - Objects)
 $inparams = @()

# fill the array, one entry for each input parameter
 $inparams += New-Object -TypeName VCO.WorkflowTokenAttribute
 $inparams[0].name = "inputString"
 $inparams[0].type = "String"
 $inparams[0].value = "Hello World"

$inparams

# ... and exectue (use $null instead on $inparams if Workflow has no input parameters
 # ... und ausführen
 $workflowToken = $vcoWS.executeWorkflow($workflow.id, "vcoadmin1" , "VMware2010", $inparams)
 $workflowToken

# monitor execution state of Workflow-Token
 # Status der Ausführung überwachen
 do { Start-Sleep -Seconds 2 }
 while ( $vcoWS.getWorkflowTokenStatus(@($workflowToken.id), "vcoadmin1" , "VMware2010") -eq"running")

# get Output-Parameter, when workflow has finished
 #($wftResults is again an array of WorkflowTokenAttribute
 $wftResults = $vcoWS.getWorkflowTokenResult($workflowToken.id, "vcoadmin1", "VMware2010")
 $wftResults

To define input parameters for the workflow, you have to create an array of WorkflowTokenAttribute-Object, each of them with a name, type and value-parameter. (Therefore the -Class and -Namespace parameters when creating the WebService-Proxy)

The output returned from getWorkflowTokenResult are also an array of WorkflowTokenAttrinbute-Objects.

This examples calls a small workflow which just copy an input-string to an output-parameter:

More information about creating a WebService-Client for vCO is in the developer guide:
http://www.vmware.com/pdf/vco_410_developers_guide.pdf#page=245
More information about the New-WebServiceProxy-CmdLet:
http://technet.microsoft.com/en-us/library/dd315258.aspx

# Connect to vCO and generate Proxy $vcoWS (-Class and -Namespace for easy stub-object generation later
# Verbindung zum vCO herstellen und Proxy $vcoWS generieren
$vcoWS = New-WebServiceProxy -Class VCO -Namespace VCO -Uri http://192.168.215.176:8280/vmware-vmo-webcontrol/webservice?WSDL# print out result (in every …)
# Ergebnis ausgeben (in jedem Schritt…)
$vcoWS# Get all Methods of the webserviceProxy
$vcoWS|get-member|where { $_.MemberType -eq “Method” }

# Find Workflows with name “demoWorkflowWithStringInput” (returns an array!)
# Workflows mit dem Namen “demoWorkflowWithStringInput” finden (gibt ein Array zurück)
$workflows = $vcoWS.getWorkflowsWithName(“demoWorkflowWithStringInput”, “vcoadmin1” , “VMware2010”)
$workflows

# pop first Workflow from resulting array
# ersten Workflow aus dem Ergebnisarray holen…
$workflow = $workflows[0]
$workflow

# print out input Parameters
$workflow.inParameters

# generate Array with Input PArameters (WorkflowTokenAttribute – Objects)
$inparams = @()

# fill the array, one entry for each input parameter
$inparams += New-Object -TypeName VCO.WorkflowTokenAttribute
$inparams[0].name = “inputString”
$inparams[0].type = “String”
$inparams[0].value = “Hello World”

$inparams

# … and exectue (use $null instead on $inparams if Workflow has no input parameters
# … und ausführen
$workflowToken = $vcoWS.executeWorkflow($workflow.id, “vcoadmin1” , “VMware2010”, $inparams)
$workflowToken

# monitor execution state of Workflow-Token
# Status der Ausführung überwachen
do { Start-Sleep -Seconds 2 }
while ( $vcoWS.getWorkflowTokenStatus(@($workflowToken.id), “vcoadmin1” , “VMware2010″) -eq”running”)

# get Output-Parameter, when workflow has finished
#($wftResults is again an array of WorkflowTokenAttribute
$wftResults = $vcoWS.getWorkflowTokenResult($workflowToken.id, “vcoadmin1”, “VMware2010”)
$wftResults