0

Use the Workflow Validation tool in vCO!

– January 13, 2012

One of the first things I got teached during my studies was: Always deliver code that compiles with

“0 Warnings, 0 Errors“!

We had to follow that principle while trying to let LEDs blink (I miss a vCO-Plugin for MPC555 :-D ) , but I still remember my Prof.’s words when I develop workflows.

The vCenter Orchestrator provides a Workflow validation mechanism, which checks the workflow for

  • open ends
  • unreachable workflow elements
  • unused workflow Attributes
  • unbound IN- and OUT parameters of workflow elements
  • formal errors in scriptable tasks (JavaScript)
  • unbound Exceptions (if you use an Exception connector)
  • Unset parameters in Configuration Elements
  • …

You can run the validation by pressing the “Validate”-Button in the Workflow editor, or in the context menu of a workflow in the workflowlList.

The results of the validation is shown in a popup window. There are two kinds of validation issues:
Errors are hard formal violations which prevent the workflow from running sucessful.
Warnings are “soft” violations: Your workflow can be started, but it likely has some bugs.

For some of the validation results “Quick Fix actions” are recommended. They might fix the issue, but do not trust them blindly!

When you ran the validation at least once, errors and warnings are also shown as small red or yellow symbols directly at the related workflow element in the schema. This is very helpful for larger workflows!

By default a workflow is also validated before you start it (only when you try to start the workflow in the vCO Client, not via weboperator nor the SOAP API!). If your workflow has an error (warnings don’t matter), you cannot start the workflow, and you’ll get this error message:

You can change this behavior in the menue “Tools / User Preferences… ” of the vCO client, there in the “Workflows”-section (the checkbox is labeled with “Validate workflow before running it”). I recommend to only do this in your development environment, when you want to start workflows with errors (e.g. while they’re not developed completely yet)!

Also be aware:
The Workflow Validation only can check for formal errors. Semantic errors in your workflow and its JavaScript parts can not be detected by the validation.
A valid workflow is not necessarily error-free!

In very rare caes you also might get some false positives in the validation results. The only situation I remember is, when you need a workflow attribute only for input presentation processing, but not in the workflow: You’ll get a “Attribute XYZ is never used!” warning (, and the quick-fix would delete it and break the processing of input presentation!).

In sum: Always end up with a workflow that shows “0 Warnings, 0 Errors“! :mrgreen:

Share|
0

vCenter Orchestrator Usage survey

– January 12, 2012

The vCO Team @ VMware needs your help:

“As part of ongoing improvement initiatives at VMware, we would like to collect your feedback through several questions in the following areas:

 1. Your usage of vCenter Orchestrator
2. Workflow development
3. Overall feedback and needed enhancements

 Please, proceed to the following link in order to fill-out the survey:

 https://www.surveymonkey.com/s/VCO-USAGE

 Thank you in advance, your input is highly appreciated.”
(Original post on http://communities.vmware.com/message/1893164#1893164 )

It takes 15-25 minutes, but it’s your chance to give your input for future versions of vCenter Orchestrator!
Go vCO-Team, go Wavemaker-Team! (I mentioned that before, didn’t I?  :mrgreen: )

Share|
1

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

– January 7, 2012

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…

Share|
0

Redirecting vCO logs to Syslog (…and other…)

– December 11, 2011

The vCO Log Mechanism

VMware vCenter Orchestrator uses log4j (Version 1.2) for technical logging. Log entries from following sources are routed through this library:

  • vCO Server log messages
  • Workflow errors
  • Workflow log messages created via System.log|debug|error|warn(“logtext”) in a scriptable task
  • Action log messages created via System.log|debug|error|warn(“another logtest”)
  • Plugin log messages

In the default settings the log messages are written to the logfiles server.log and scripts-log.log in the folder %INSTALLDIR%\app-server\server\vmo\logs.

However, you can configure the settings and the targets of the in the configuration file log4j.xml in %INSTALLDIR%\app-server\server\vmo\conf.

log4jxml

This configuration-file is watched automatically by the vCO server, you there is no need to restart the service after you changed the log4j.xml file, just wait a couple of seconds until you see this message in the server.log:


...[Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml

(and yes, if you misconfigured it, this might be the last message you see :twisted: )

Redirecting to Syslog

Because log4j supports a lot of different targets out of the box, you can easily re-route the log messages to an external syslog server:

1. Configure a new Log Appender in the log4j.xml, and configure the target SyslogHost, the syslog facility and the message layout:

...
<appender name="SYSLOG">
   <param name="SyslogHost" value="192.168.219.213"/>
   <param name="Facility" value="USER"/>
   <param name="FacilityPrinting" value="true"/>
   <layout>
      <param name="ConversionPattern" value="%t %5r %-5p %-21d{yyyyMMdd HH:mm:ss,SSS} %c{2} [%x] %m %n"/>
   </layout>
</appender>
...

2. Route the log messages to this new appender, e.g. for all messages add the new appender-ref in the <root>-section at the end of the file:

...
<!-- ======================= -->
<!-- Setup the Root category -->
<!-- ======================= -->

<root>
   <priority value="INFO"/>

   <appender-ref ref="CONSOLE"/>
   <appender-ref ref="FILE"/>
   <appender-ref ref="SYSLOG" />
</root>
...

3. (Don’t forget to adjust the firewall settings of your vCO-Server and/or your Syslog Host if necessary, the built-in syslog appender uses UDP/514.)

4. See the log messages arriving on your Syslog Host….

For further details about the configuration, see the References section below…

Sending SNMP-Traps

Besides syslog it’s also possible to send log messages as SNMP-Traps to a monitoring system. For that, vCO already includes an additional log4j-library (NOT related to the SNMP-Plugin for vCO), and you can use it out of the box with following appender-config:


<appender name="TRAP_LOG">
<param name="ImplementationClassName" value="org.apache.log4j.ext.JoeSNMPTrapSender" />
<param name="ManagementHost" value="192.168.219.213" />
<param name="ManagementHostTrapListenPort" value="162" />
<param name="EnterpriseOID" value="1.3.6.1.4.1.24.0" />
<param name="LocalIPAddress" value="vco01-219.vcolab.local" />
<param name="LocalTrapSendPort" value="161" />
<param name="GenericTrapType" value="6" />
<param name="SpecificTrapType" value="12345678" />
<param name="CommunityString" value="public" />
<param name="ForwardStackTraceWithTrap" value="true" />
<param name="Threshold" value="DEBUG" />
<param name="ApplicationTrapOID" value="1.3.6.1.4.1.24.12.10.22.64" />
<layout>
<param name="ConversionPattern" value="%d,%p,[%t],[%c],%m%n" />
</layout>
 </appender>

And of course you have to add this appender to the <root>-section:


<appender-ref ref="TRAP_LOG" />

Again, don’t forget to open the Firewall (usually UDP/162).

If you only want to send SNMP-Traps in rare specific cases (and not for all the log messages), consider rather to use the SNMP-Plugin for vCO, it contains a pre-build workflow to send SNMP-Traps…

References

Besides these small examples of additional appenders log4j offers a lot more configuration parameters. For further reading, start here:

Happy logging! :-D

Share|
0

4 (in words: FOUR) new Plugins for vCenter Orchestrator released

– December 11, 2011

Last Friday VMware released FOUR new Plugins for vCO (read from the source here: http://blogs.vmware.com/orchestrator/2011/12/vmware-releases-four-new-vmware-vcenter-orchestrator-plug-ins.html )

  • The SQL Plugin makes it possible to access external Databases within workflows (in a much more comfortable and reusable way than the already existing plain JDBC-calls)
  • The Auto Deploy Plugin automates the new vSphere 5 Auto Deploy mechanism, which absolutely makes sence to orchestrator the deployment of ESXi hosts.
  • The vCO Multi Site Plugin allows you synchronize, execute and monitor Workflows on other vCO-hosts (this also was possible in the past via the “Nested Workflows”-Element, but now its murch more powerful and flexible). There are several use-cases for this, expect a more detailed blogentry here soon :-D
  • The PowerShell Plugin allows you to call external PowerShell Scripts on other systems, via OpenSSH or WinRM. The plugin also implements a “piping” methodology in your workflows, so if you’re familiar with PowerShell, you can build workflows in a comparable way. Calling external PowerShell scripts is very powerful, and was also available in the past (see http://www.vcoportal.de/powersshell-plugin/ and http://www.vcoportal.de/2011/03/vco-powershell/ ).
    You may ask, what’s the difference and overlapping points between VMware’s PowerShell Plugin and my PowerSSHell-Plugin for vCO… expect more details about this soon as well :mrgreen:

So, the list of available plugins for vCO gets longer and longer, it seems VMware is on the right way to establish a good ecosystem around vCO…

Share|
Page 1 of 1112345...10...Last »