Latest Headlines
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

Redirecting vCO logs to Syslog (…and other…)

Don’t use this in current vRO versions! Any changes made to the log4j.xml file will be overwritten by Control Center. Use the logging settings in Control Center instead!

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 ๐Ÿ˜ˆ )

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! ๐Ÿ˜€

0

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

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 ๐Ÿ˜€
  • 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…

0

December Sales on the “Eloquent JavaScript”-Book (and others…): 40% off!

No Starch Press offers a great deal for the next days: Until Dec 3rd you get 40% off all books using the code GEEKGIFT.
More details: http://nostarch.com/newsletters/2011_holiday.htm

So buy your copy of the “Eloquent JavaScript” book now ๐Ÿ™‚
Why? http://www.vcoportal.de/2011/11/recommended-reading-eloquent-javascript/

0

Recommended Reading: Eloquent JavaScript

or: How to learn JavaScript as Workflow Developer?

When you’re new to vCenter Orchestrator, chances are that you are new to JavaScript as well. Usually not that big problem, JavaScript (at least the level you need for Actions and Scripting Elements in vCO) is quite easy to learn.

There are a lot of books about JavaScript out there. Unfortunately, most of them focus on JavaScript as language for the web, so there is a lot of web-related stuff inside, which is not necessary and very distracting for vCO Workflow Developers.

The book

One rare exception is “Eloquent JavaScript” by Marjin Haverbeke. This book really focuses on JavaScript itself and teaches the language together with an introduction in Programming in general. So you do not need any prior knowledge, neither about JavaScript nor about Programming. This makes it a perfect fit for the most new Workflow developer!

In addition to the good content, the book is written and edited very well (in fact, it’s one of the best programming books I’ve ever read (and these are some :-D)). All topics, basics like datastructures and advanced topics like the introduction in object-oriented programming, are explained along small, good and funny source-code examples in JavaScript. So you really enjoy reading while you learn programming in general and JavaScript in special!

And, that’s by far not all:

The online “lab”

Besides the hard-copy there is a free digital version of the book, available online or as downloadable .zip-archive!

On http://eloquentjavascript.net/ you can find the download links, the (very rare) errata and an online JavaScript Programming Console, where you can run and modify the examples directly in your browser:

Eloquent JavaScript Online Environment

Get Started!

This combination, written book and the online “lab environment”, really allows to learn that level of JavaScript you need for Orchestrator Workflows in a very quick way!
(And you might even use the online environment to test/”dry-run” some of your vCO Scripting Element, like confirming the semantics of a loop or some String handling (only without vCO/vSphere related objects of course))

Find more details about the book on the publisher’s homepage and on Amazon:

There is only one drawback: The fluent style of the book makes it not that useful as a reference. So if your already can programming JavaScript and you look for a reference to quickly remember how to concatenate arrays, other books like The old Rhinocerus might fit better.