Wavemaker, Spring and VMware Infrastructure

Mitte/Ende letzten Jahres sind wir auf ein Produkt namens Wavemaker aufmerksam geworden, dass dieses zu diesem Zeitpunkt von VMware erworben wurde. Es handelt sich bei diesem Produkt um ein  „Rapid Application Development“ (RAD) Tool inkl. WYSIWYG-Editor auf Basis von Spring (De-Facto Standard Framework im Enterprise Segment) und des Dojo Toolkits.

Es eignet sich aus unserer Sicht besonders für Applikationen kleiner bis mittlerer Größe. Für Enterprise Anwendungen würden wir eine Entwicklung auf Basis von Spring und einer der verfügbaren Frameworks wie beispielsweise: jQuery, Dojo Toolkit, Google Web Toolkit (GWT), Vaadin, Apache Tiles oder eine Kombination empfehlen. In diesem Zusammenhang möchten wir auch auf ein anderes Projekt des Spring Frameworks  namens SpringRoo hinweisen, das ebenfalls sehr interessant ist und euch das Prototyping sehr vereinfachen kann. (Sollten Sie mehr Informationen zu Roo haben wollen, geben Sie einfach Feedback über die Kommentarfunktion und wir werden bei Gelegenheit  auch zu diesem Projekt ein kleines Tutorial veröffentlichen.)

Nun jedoch zurück zum eigentlich Thema dieses Artikels….

Nachdem wir uns ende des letzten Jahres mit Wavemaker beschäftigt hatten und auch immer wieder Anfragen dazu haben, möchten wir an dieser Stelle demonstrieren wie man mit Hilfe dieser Software sehr schnell Webapplikationen erstellen kann die beispielsweise auf den WebService des vCenter’s oder des Orchestrator’s zugreifen. Sie können sich auf Grundlage dieser Informationen zum Beispiel eine Applikation zur Verwaltung Ihrer (Virtuellen-) Infrastruktur entwerfen (Quasi ein eigenes kleines vCenter inkl. Orchestrierungs-Workflows) um somit einen maßgeschneiderte Ansichten auf diese zu bekommen. Jedoch weisen wir vorab darauf hin, dass wir an dieser Stelle nur einen groben Leitfaden inkl. eines voll funktionsfähigen Beispiels (Springsource Tool Suite (Eclipse) Projekt + Wavemaker Projekt) an die Hand geben können. Sollten Sie jedoch spezifische Fragen haben oder euch etwas unklar sein, können Sie dies gerne in den Kommentaren zu diesem Artikel vermerken und wir werden dann im Einzelfall darauf eingehen.

Voraussetzungen für die Beispielapplikation

Um mit der Applikation zu starten wird Wavemaker selbst benötigt. Bitte herunterladen und installieren. Den entsprechenden Link finden Sie hier. Desweiteren sollten Sie entweder die SpringSource Tool Suite (STS) oder Eclipse als Java Entwicklungsframework nutzen. Bei STS handelt es sich um eine vom Spring Team angepasste Eclipse Version für das Entwickeln von Enterprise Applikationen, die bereits viele nützliche Plugins etc. mit sich bringt, daher können wir diese nur empfehlen.

Nachdem Wavemaker als auch STS/Eclipse installiert sind, werden nun noch die Projekt Beispieldateien benötigt , welche im folgenden Link heruntergeladen werden können. Download

Die Beispielanwendung wird erstellt, indem Wavemaker gestartet und das Projekt über File->Import importiert wird . In diesem Zuge dessen, wird das ZIP entpackt und ein Order für dieses Projekt in eurem WaveMaker Home-Folder unter ‚projects‘ angelegt.

Anschließend wird das STS/Eclipse geöffnet und das Projekt über File->Import->Existing Projects into Workspace hinzufügen. Eventl. müssen Sie noch für das Projekt die Pfade des JDK (Wavemaker unterstützt nur JDK 1.6) anpassen. Das ganze sollte dann folgendermaßen aussehen.

Wir nutzen STS in Kombination mit WaveMaker, da WaveMaker keine wirklich gute IDE bzw. keinen guten Code Editor für Java mitbringt, dies liegt aber auch nicht im Fokus des Produktes. Wir empfehlen daher die Entwicklung der Logik in Java (Mittels STS) und die Entwicklung der GUI in WaveMaker. Um dies zu ermöglichen bringt WaveMaker eine Funktionalität namens Java Services mit, im Grunde genommen handelt es sich dabei um Spring Beans (Singeltons) die via DI (Dependency Injection) eingeschleust werden.

Dies wurde in unserem Szenario auch so eingesetzt, d.h. die Methoden die wir erstellen um auf die WebServices vom vCenter und vom Orchestrator zuzugreifen werden als Java Service implementiert und können dann im WaveMaker via Javascript aufgerufen werden. Grundsätzlich ist es theoretisch auch möglich direkt aus Wavemaker auf WebServices (SOAP/REST) zuzugreifen, jedoch hat dies mehrere Nachteile die wir hier Stichpunktartig aufzeigen.

  • Ihre Methoden werden Client-Seitig ausgeführt, d.h. jeder Client benötigt Zugriff auf den entsprechenden WebService, in unserem Fall  vCenter und Orchestrator, ganz zu schweigen von dem enormen Sicherheitsrisiko, dass nicht zu kalkulieren ist. Ein Angreifer könnte beispielsweise den JavaScript Code verändern und alle Ihre virtuellen Maschinen löschen, sofern nicht eine riesige Menge von ACL’s definiert sind. Ein Alptraum.
  • Keine Trennung von Logik und Visualisierungs Code
  • Sie haben keine schönen Objekte (Java) mit denen Sie arbeiten können, sondern müssen extrem umständlich Parameter und Rückgabewerte evaluieren.
  • WaveMaker nutzt AXIS2 um die Stubs zu generieren, im Fall von VMware Orchestrator heisst das, dass die Stubs möglicherweise nicht so erstellt werden wie VMware dies beabsichtigt hat, da der Orchestrator WebService mit AXIS 1 realisiert wurde.

Es existieren einige Beispiele im Netz die direkt auf den WebService zugreifen. Aufgrund der oberen Punkte kann ich nur dringend davon abraten, egal ob zu Testzwecken oder Produktiv.

Nach dem nun das Beispielprojekt sowohl im WaveMaker als auch im STS geöffnet ist, möchten wir an dieser Stelle auf die wichtigsten Dateien/Packages/Libs eingehen.

  • Paket: ch.dunes.vso.webservice – In diesem Paket befinden sich die Stubs des Orchestrator WebServices, die  entweder selbst generiert werden können oder auch in den offizielen Samples zu finden sind.
  • Paket: de.mightcare.service – In diesem Paket befinden sich die jeweiligen Implementierung unserer Methoden die auf Funktionalität der WebServices zurückgreifen.
  • Paket: de.mightycare.types – In diesem Paket befinden sich unsere Typen die als POJO’s definiert sind und uns erlauben Objekte zwischen JavaServices und WaveMaker auszutauschen (Hint: JSON), so das wir dann in der Lage sind auf die Objekte aus Javascript (WaveMaker) heraus zuzugreifen.
  • Libs: Hier ist die VIJAVA erwähnenswert. Hierbei handelt es sich um eine Wrapper API, die ein Aufsatz für die normale VMware API ist und es erlaubt elegant (POJO Style) auf die VMware Objekete zuzugreifen. Leider können wir hier nicht weiter darauf eingehen. Sollte Bedarf an diesem Thema bestehen vermerken Sie dies einfach in den Kommentaren. Desweiteren gibt es hier noch einige Support Libraries wie AXIS, Apache Common Logging, Log4j etc. die uns das Leben erleichtern.

Alle anderen Dateien gehören zu WaveMaker und müssen höchst selten händisch angepasst werden.

Da Sie nun einen ersten Überblick über die wichtigsten Dateien haben können Sie die Applikation noch auf Ihre Umgebung anpassen. (Wir haben bewusst auf Konfigurationsdateien verzichtet um die Beispiele nicht noch weiter zu verkomplizieren. Im Normalfall würden Sie die WebService URL’s sowie Credentials verschlüsselt in einer Datenbank oder einem .properties File ablegen.) Hierzu müssen Sie die beiden Dateien VCenterManager.java und VCOManager.java anpassen. Hier folgende Zeilen editieren:

  • VCOManager.java
    •  private final String username = „XXXX“;
    •  private final String password = „XXXX“;
    • private final String endpoint = „http://XXX.XXX.XXX.XXX:8280/vmware-vmo-webcontrol/webservice“;
    • private final String dunesUriPrefix = „XXX.XXX.XXX.XXX“;
  • VCenterManager.java
    • private final String username = „XXXX“;
    • private final String password = „XXXXXX“;
    • private final String endpoint = „https://XXX.XXX.XXX.XXX/sdk“;

Das war es dann auch schon mit den Anpassungen. Nachdem Sie das gemacht haben sollten Sie die beiden WebServices innerhalb von WaveMaker neu laden, damit dieser die Änderungen die Sie in STS gemacht haben mitbekommt. Hierzu wählen Sie in Wavemaker auf der linken Seite den Reiter Services. Anschließend selektieren Sie nach einander die beiden Services und laden diese über das kleine Icon (Blaues Refresh Symbol) oberhalb des Code Editors neu.

So, nun könnten Sie die Applikation starten. Aber was macht diese Applikation überhaupt?

  • Im ersten Schritt lädt Sie über den VMware vCenter WebService alle VM’s die in diesem vCenter hinterlegt sind. Dies kann je nach Verbindung und Anzahl der VM’s einige Minuten dauern.
  • Anschließend haben Sie die Möglichkeit eine virtuelle Maschine auszuwählen. In diesem Zusammenhang wird auch ein zweiter WebService Aufruf gegen den VMware vCenter WebService gestartet der diese Informationen einholt.
  • Abschliessen können Sie über den Button „Snapshot“ den entsprechenden Orchestrator Workflow aufrufen um einen Snapshot zu erstellen. Der geneigte Kritiker wird an dieser Stelle sagen: „Einen Snapshot? Den kann ich doch auch über das vCenter erstellen.“Das ist freilich korrekt, jedoch ist dies ein Beispiel, genau so gut könnte sich hinter dem Button ein Workflow verbergen, der einen neue Organisation im vCloud Director anlegt, AD User mit dieser Organisation verknüpft , eine Tier-3 Applikation für alle User anlegt und automatisch über Altiris Workflows betankt.

Dies bildet auch den Abschluss dieses Artikels. Sollten Sie Fragen oder Probleme mit dieser Applikation haben, lassen Sie es uns Wissen. Wir werden dann darauf eingehen und der Artikel sinnvoll weiterführen. Wie immer gilt: „Use on your own risk.

Download Project

Mitte/Ende letzten Jahres sind wir auf ein Produkt namens Wavemaker aufmerksam geworden, dass dieses zu diesem Zeitpunkt von VMware erworben wurde. Es handelt sich bei diesem Produkt um ein  „Rapid Application Development“ (RAD) Tool inkl. WYSIWYG-Editor auf Basis von Spring (De-Facto Standard Framework im Enterprise Segment) und des Dojo Toolkits.

Es eignet sich aus unserer Sicht besonders für Applikationen kleiner bis mittlerer Größe. Für Enterprise Anwendungen würden wir eine Entwicklung auf Basis von Spring und einer der verfügbaren Frameworks wie beispielsweise: jQueryDojo ToolkitGoogle Web Toolkit (GWT), VaadinApache Tiles oder eine Kombination empfehlen. In diesem Zusammenhang möchten wir auch auf ein anderes Projekt des Spring Frameworks  namens SpringRoo hinweisen, das ebenfalls sehr interessant ist und euch das Prototyping sehr vereinfachen kann. (Sollten Sie mehr Informationen zu Roo haben wollen, geben Sie einfach Feedback über die Kommentarfunktion und wir werden bei Gelegenheit  auch zu diesem Projekt ein kleines Tutorial veröffentlichen.)

Nun jedoch zurück zum eigentlich Thema dieses Artikels….

Nachdem wir uns ende des letzten Jahres mit Wavemaker beschäftigt hatten und auch immer wieder Anfragen dazu haben, möchten wir an dieser Stelle demonstrieren wie man mit Hilfe dieser Software sehr schnell Webapplikationen erstellen kann die beispielsweise auf den WebService des vCenter’s oder des Orchestrator’s zugreifen. Sie können sich auf Grundlage dieser Informationen zum Beispiel eine Applikation zur Verwaltung eurer (Virtuellen-) Infrastruktur entwerfen (Quasi ein eigenes kleines vCenter inkl. Orchestrierungs-Workflows) um somit einen maßgeschneiderte Ansichten auf diese zu bekommen. Jedoch weisen wir vorab darauf hin, dass wir an dieser Stelle nur einen groben Leitfaden inkl. eines voll funktionsfähigen Beispiels (Springsource Tool Suite (Eclipse) Projekt + Wavemaker Projekt) an die Hand geben können. Sollten Sie jedoch spezifische Fragen haben oder euch etwas unklar sein, können Sie dies gerne in den Kommentaren zu diesem Artikel vermerken und wir werden dann im Einzelfall darauf eingehen.

Voraussetzungen für die Beispielapplikation

Um mit der Applikation zu starten wird Wavemaker selbst benötigt. Bitte herunterladen und installieren. Den entsprechenden Link finden Sie hier. Desweiteren sollten Sie entweder die SpringSource Tool Suite (STS) oder Eclipse als Java Entwicklungsframework nutzen. Bei STS handelt es sich um eine vom Spring Team angepasste Eclipse Version für das Entwickeln von Enterprise Applikationen, die bereits viele nützliche Plugins etc. mit sich bringt, daher können wir diese nur empfehlen.

Nachdem Wavemaker als auch STS/Eclipse installiert sind, werden nun noch die Projekt Beispieldateien benötigt , welche im folgenden Link heruntergeladen werden können. Download

Die Beispielanwendung wird erstellt, indem Wavemaker gestartet und das Projekt über File->Import importiert wird . In diesem Zuge dessen, wird das ZIP entpackt und ein Order für dieses Projekt in eurem WaveMaker Home-Folder unter ‚projects‘ angelegt.

Anschließend wird das STS/Eclipse geöffnet und das Projekt über File->Import->Existing Projects into Workspace hinzufügen. Eventl. müssen Sie noch für das Projekt die Pfade des JDK (Wavemaker unterstützt nur JDK 1.6) anpassen. Das ganze sollte dann folgendermaßen aussehen.

Wir nutzen STS in Kombination mit WaveMaker, da WaveMaker keine wirklich gute IDE bzw. keinen guten Code Editor für Java mitbringt, dies liegt aber auch nicht im Fokus des Produktes. Wir empfehlen daher die Entwicklung der Logik in Java (Mittels STS) und die Entwicklung der GUI in WaveMaker. Um dies zu ermöglichen bringt WaveMaker eine Funktionalität namens Java Services mit, im Grunde genommen handelt es sich dabei um Spring Beans (Singeltons) die via DI (Dependency Injection) eingeschleust werden.

Dies wurde in unserem Szenario auch so eingesetzt, d.h. die Methoden die wir erstellen um auf die WebServices vom vCenter und vom Orchestrator zuzugreifen werden als Java Service implementiert und können dann im WaveMaker via Javascript aufgerufen werden. Grundsätzlich ist es theoretisch auch möglich direkt aus Wavemaker auf WebServices (SOAP/REST) zuzugreifen, jedoch hat dies mehrere Nachteile die wir hier Stichpunktartig aufzeigen.

  • Ihre Methoden werden Client-Seitig ausgeführt, d.h. jeder Client benötigt Zugriff auf den entsprechenden WebService, in unserem Fall  vCenter und Orchestrator, ganz zu schweigen von dem enormen Sicherheitsrisiko, dass nicht zu kalkulieren ist. Ein Angreifer könnte beispielsweise den JavaScript Code verändern und alle Ihre virtuellen Maschinen löschen, sofern nicht eine riesige Menge von ACL’s definiert sind. Ein Alptraum.
  • Keine Trennung von Logik und Visualisierungs Code
  • Sie haben keine schönen Objekte (Java) mit denen Sie arbeiten können, sondern müssen extrem umständlich Parameter und Rückgabewerte evaluieren.
  • WaveMaker nutzt AXIS2 um die Stubs zu generieren, im Fall von VMware Orchestrator heisst das, dass die Stubs möglicherweise nicht so erstellt werden wie VMware dies beabsichtigt hat, da der Orchestrator WebService mit AXIS 1 realisiert wurde.

Es existieren einige Beispiele im Netz die direkt auf den WebService zugreifen. Aufgrund der oberen Punkte kann ich nur dringend davon abraten, egal ob zu Testzwecken oder Produktiv.

Nach dem nun das Beispielprojekt sowohl im WaveMaker als auch im STS geöffnet ist, möchten wir an dieser Stelle auf die wichtigsten Dateien/Packages/Libs eingehen.

  • Paket: ch.dunes.vso.webservice – In diesem Paket befinden sich die Stubs des Orchestrator WebServices, die  entweder selbst generiert werden können oder auch in den offizielen Samples zu finden sind.
  • Paket: de.mightcare.service – In diesem Paket befinden sich die jeweiligen Implementierung unserer Methoden die auf Funktionalität der WebServices zurückgreifen.
  • Paket: de.mightycare.types – In diesem Paket befinden sich unsere Typen die als POJO’s definiert sind und uns erlauben Objekte zwischen JavaServices und WaveMaker auszutauschen (Hint: JSON), so das wir dann in der Lage sind auf die Objekte aus Javascript (WaveMaker) heraus zuzugreifen.
  • Libs: Hier ist die VIJAVA erwähnenswert. Hierbei handelt es sich um eine Wrapper API, die ein Aufsatz für die normale VMware API ist und es erlaubt elegant (POJO Style) auf die VMware Objekete zuzugreifen. Leider können wir hier nicht weiter darauf eingehen. Sollte Bedarf an diesem Thema bestehen vermerken Sie dies einfach in den Kommentaren. Desweiteren gibt es hier noch einige Support Libraries wie AXIS, Apache Common LoggingLog4j etc. die uns das Leben erleichtern.

Alle anderen Dateien gehören zu WaveMaker und müssen höchst selten händisch angepasst werden.

Da Sie nun einen ersten Überblick über die wichtigsten Dateien haben können Sie die Applikation noch auf Ihre Umgebung anpassen. (Wir haben bewusst auf Konfigurationsdateien verzichtet um die Beispiele nicht noch weiter zu verkomplizieren. Im Normalfall würden Sie die WebService URL’s sowie Credentials verschlüsselt in einer Datenbank oder einem .properties File ablegen.) Hierzu müssen Sie die beiden Dateien VCenterManager.java und VCOManager.java anpassen. Hier folgende Zeilen editieren:

  • VCOManager.java
    •  private final String username = „XXXX“;
    •  private final String password = „XXXX“;
    • private final String endpoint = „http://XXX.XXX.XXX.XXX:8280/vmware-vmo-webcontrol/webservice“;
    • private final String dunesUriPrefix = „XXX.XXX.XXX.XXX“;
  • VCenterManager.java
    • private final String username = „XXXX“;
    • private final String password = „XXXXXX“;
    • private final String endpoint = „https://XXX.XXX.XXX.XXX/sdk“;

Das war es dann auch schon mit den Anpassungen. Nachdem Sie das gemacht haben sollten Sie die beiden WebServices innerhalb von WaveMaker neu laden, damit dieser die Änderungen die Sie in STS gemacht haben mitbekommt. Hierzu wählen Sie in Wavemaker auf der linken Seite den Reiter Services. Anschließend selektieren Sie nach einander die beiden Services und laden diese über das kleine Icon (Blaues Refresh Symbol) oberhalb des Code Editors neu.

So, nun könnten Sie die Applikation starten. Aber was macht diese Applikation überhaupt?

  • Im ersten Schritt lädt Sie über den VMware vCenter WebService alle VM’s die in diesem vCenter hinterlegt sind. Dies kann je nach Verbindung und Anzahl der VM’s einige Minuten dauern.
  • Anschließend haben Sie die Möglichkeit eine virtuelle Maschine auszuwählen. In diesem Zusammenhang wird auch ein zweiter WebService Aufruf gegen den VMware vCenter WebService gestartet der diese Informationen einholt.
  • Abschliessen können Sie über den Button „Snapshot“ den entsprechenden Orchestrator Workflow aufrufen um einen Snapshot zu erstellen. Der geneigte Kritiker wird an dieser Stelle sagen: „Einen Snapshot? Den kann ich doch auch über das vCenter erstellen.“Das ist freilich korrekt, jedoch ist dies ein Beispiel, genau so gut könnte sich hinter dem Button ein Workflow verbergen, der einen neue Organisation im vCloud Director anlegt, AD User mit dieser Organisation verknüpft , eine Tier-3 Applikation für alle User anlegt und automatisch über Altiris Workflows betankt.

Dies bildet auch den Abschluss dieses Artikels. Sollten Sie Fragen oder Probleme mit dieser Applikation haben, lassen Sie es uns Wissen. Wir werden dann darauf eingehen und der Artikel sinnvoll weiterführen. Wie immer gilt: „Use on your own risk.

Download Project

VMware Orchestrator WebService

Wir werden immer wieder gefragt, wie man die im VMware Orchestrator  (im folgenden VCO) erstellten Workflows, außerhalb des VCO Clients ausführen kann.

Für diejenigen unter euch, denen VCO kein Begriff ist, sei gesagt, dass es sich bei diesem Produkt um ein mächtiges Automatisierungs- und Orchestrierungs-Tool handelt, das dem VMware vCenter Server kostenlos beiliegt (Eine virtuelle Appliance ist ebenfalls verfügbar).

Weitere Informationen findet man u.a. unter den folgenden Links.

An dieser Stelle möchten wir nicht weiter auf die Funktionalität des VCO’s eingehen. So viel sei jedoch gesagt, der VCO erlaubt es jeden uns bekannten Task in einem virtuellen Datacenter und/oder Private-/Public-/Hybrid- Cloud zu automatisieren inkl. Einbindung bestehender Komponenten, wie beispielsweise einem Active Directory, Datenbanken, Provisioning Tools, Monitoring Tools usw. VCO ist ebenfalls das Bindeglied zwischen Produkten wie VMware Service Manager, VMware vCloud Director, RabbitMQ  und erlaubt somit Rich Cloud Environments zur Verfügung zu stellen.

Nun jedoch zurück zum Thema. Wie kann man im VCO definierte Automatisierungs- und Orchestrierungs- Workflow von „außen“ ausführen/abfragen?! Hierzu bietet der VMware Orchestrator einen WebService Schnittstelle (SOAP) incl. WSDL. Sollte man  Java oder .NET zum externen Aufruf von Workflows nutzen wollen ist dies mittlerweile sehr einfach, da bereits vorgefertigte Stubs und Klassen existieren die Ihr nutzen könnt. (Informationen findet Ihr hier). Möchte man das ganze jedoch mit einer anderen Sprache wie beispielsweise PHP/Perl/C/Python o.ä. realisieren gibt es einige Hürden die man nehmen muss.

Aus diesem Grund geben wir euch am Beispiel von Perl ein exemplarisches Skript an die Hand, das euch alle Schritte zeigt die nötig sind, um den WebService des VCO zu nutzen. Eine Archivdatei, das den Workflow und das Skript enthält, könnt Ihr hier herunterladen. Das Perl Skript sowie der Orchestrator Workflow sind bewusst sehr simpel gehalten, damit wir uns auf das wesentliche konzentrieren können. Das Perl Skript durchläuft dabei folgende Schritte:

  • Es verbindet sich an den WebService von VCO
  • Es versucht unseren Workflow ‚Show GuestOS‘ zu finden
  • Durchsucht alle an den VCO angeschlossen vCenter nach virtuellen Maschinen
  • Serialisiert ein Array in VMware Format mit den eindeutigen Namen der virtuellen Maschinen (dunesUri)
  • Aufruf unseres Workflows mit dem Array
  • Anschließend prüfen wir den Status des Workflows und warten auf dessen Beendigung
  • Nach Abschluss des Tasks erhalten wir von unserem Workflow ein Serialisiertes Array im VMware Format zurück, das eine Liste der Gastbetriebssystem für die übergebenen virtuellen Maschinen enthält. Wir zeigen in diesem Zusammenhang auch, wie man die Informationen De-Serialisiert.

Damit Sie das Perl Skript und den Workflow nutzen könnt sind vor-ab noch folgende Schritte durchzuführen um die WebService Stubs zu generieren.

  • Perl installieren (Unter Linux ist dies in den meisten Fällen über den Paketmanager der Distribution möglich, unter Windows empfehlen wir Strawberry Perl )
  • SOAP::WSDL aus dem CPAN installieren, z.B. via ‚cpan SOAP::WSDL
  • Stubs aus dem WSDL generieren (In diesem Zusammenhang weisen wir darauf hin, das die Stubs von einem AXIS 1.1 kompatiblen Generator erstellt werden müssen, unabhängig davon welche Programmier-/Skript- Sprache verwendet wird.) . Im Fall von Perl ist es ‚wsdl2perl.pl‚ was zusammen mit dem CPAN Modul installiert wird.

Download ZIP

#!/usr/bin/perl
use Getopt::Long;
use Pod::Usage;
use SOAP::WSDL;
use MyInterfaces::VSOWebControlService::webservice;
use MyTypes::Workflow;
use Data::Dumper;

use warnings;
use strict;

my $man = 0;
my $help = 0;
my ( $username, $password );

GetOptions(	'help|?' => $help, 
		'man' => $man,
		'username=s' => $username,
		'password=s' => $password )  or pod2usage(2); 

pod2usage(1) if $help;
pod2usage(-exitstatus => 0, -verbose => 2) if $man;
unless (  defined ( $username ) && defined ( $password ) ) {
	pod2usage(message => "nSyntax error.n", -exitstatus  => 1, -verbose => 2);

}

my $workflowName = "Show GuestOS";

my $interface = MyInterfaces::VSOWebControlService::webservice->new();

# Find workflow

my $response = $interface->getWorkflowsWithName ( {
			workflowName 	=> 	$workflowName,
			username 	=> 	$username,
			password 	=> 	$password,
		},,
	);

die $response if not $response;

my $elements = $response->get_getWorkflowsWithNameReturn();  
die ("Exception: There is no worklows with name: '$workflowName' in the orchestrator.") unless ( defined ($elements)  ) ;
die ("Exception: There are more than one workflow with name '$workflowName' in the orchestrator.") if ( @$elements > 1 ) ;

my $workflowId = $elements->get_id();

$response = $interface->find({
        type =>  "VC:VirtualMachine", # string
        query =>  "", # string
        username =>  $username, # string
        password =>  $password, # string
      },,
	  );
die $response if not $response;

my $vmCount = $response->get_findReturn()->get_totalCount();
die ("Exception: There are no virtual machines in the vCenter's connected to the orchestrator.") if ( ! $vmCount  ) ;

#get all virtual machines
my $vm = $response->get_findReturn()->get_elements()->get_item();

# cycle through all virutal machines and get dunes uri (unique object reference)
my @dunesUri;
for ( my $i = 0; $i < $vmCount ; $i++ ) { 	push (@dunesUri, $vm->[$i]->get_dunesUri());

}

my $vmSerialized = sprintf '#{#VC:VirtualMachine#%s#}#',join('#;#VC:VirtualMachine#', @dunesUri);

# Execute workflow

$response = $interface->executeWorkflow ( {
		workflowId 	=> 	$workflowId,
		username	=>	$username,
		password 	=> 	$password,

		workflowInputs => [ {

				name	=> 	"vms",
				type	=> 	"Array/VC:VirtualMachine",
				value	=>	"$vmSerialized"

		}]

	});
sdie $response if not $response;

my $workflowToken = $response->get_executeWorkflowReturn();

$| = 1;

my $wfStatus;
my $counter=1;
do {
	$response = $interface->getWorkflowTokenStatus( {

		workflowTokenIds 	=>  $workflowToken->get_id(),
		username 		=>  $username,
		password 		=>  $password, 
		},,
	);
	$wfStatus = $response->get_getWorkflowTokenStatusReturn();
	printf ("Workflow status: %s - Time elapsed: %s seconds. n" , $wfStatus, $counter);
	sleep(1);
   	$counter++;
  } while ($wfStatus eq "running");

$response = $interface->getWorkflowTokenResult( {
        workflowTokenId         =>  $workflowToken->get_id(),
        username                =>  $username,
        password                =>  $password,
        },,
);

my $wfResult = $response->get_getWorkflowTokenResultReturn();
if ($wfStatus eq "failed") {
	printf ("Reason: %sn", $wfResult->[0]->get_value());
}else {

	my $returnSerialized =  $wfResult->[1]->get_value();
	$returnSerialized =~ s/^#{#string#(.*)#}#$/$1/;
	my @ready = split ('#;#string#', $returnSerialized);

	foreach (@ready) {
		print "$_n";
	}	

}

__END__

=head1 NAME

showGuestOSFromAllVms

=head1 SYNOPSIS

Use:

	perl showGuestOSFromAllVms.pl [--help] [--man] --username --password

Examples:

	perl showGuestOSFromAllVms.pl --help

	perl showGuestOSFromAllVms.pl --man

	perl showGuestOSFromAllVms.pl --username xxxx --password xxx

=head1 DESCRIPTION

B demonstrates the use of orchestrator webservice API with Perl. It calls the workflow 'Show GuestOS' for all VM's (Danger! It will use all SdkConnectiosn of the Orchestrator). It also demonstrates how to pass simple and complex types (inclusive serialization/desirialization) to workflows, handle exceptions and handle return values from a workflow.

=head1 ARGUMENTS

=over 8

=item B

	(Optional.) Print a brief help message and exits.

=item B

	(Optional.) Prints the manual page and exits.

=back
=cut

Wir werden immer wieder gefragt wie man die im VMware Orchestrator  (im folgenden VCO) erstellten Workflows außerhalb des VCO Clients ausführen kann.

Für diejenigen unter euch, denen VCO kein Begriff ist, sei gesagt es handelt sich bei diesem Produkt um ein mächtiges Automatisierungs- und Orchestrierungs-Tool das dem VMware vCenter Server kostenlos beiliegt (Eine VA ist ebenfalls verfügbar). Weitere Informationen findet man u.a. unter den folgenden Links.

An dieser Stelle möchten wir nicht weiter auf die Funktionalität des VCO’s eingehen. So viel sei jedoch gesagt, der VCO erlaubt es jeden uns bekannten Task in einem virtuellen Datacenter und/oder Private-/Public-/Hybrid- Cloud zu automatisieren inkl. Einbindung bestehender Komponenten, wie beispielsweise einem Active Directory, Datenbanken, Provisioning Tools, Monitoring Tools usw. VCO ist ebenfalls das Bindeglied zwischen Produkten wie VMware Service Manager, VMware vCloud Director, RabbitMQ  und erlaubt somit Rich Cloud Environemnts zur Verfügung zu stellen.

Nun jedoch zurück zum Thema, wie man im VCO definierte Automatisierungs- und Orchestrierungs- Workflow von „außen“ ausführen/abfragen kann. Hierzu bietet der VMware Orchestrator einen WebService Schnittstelle (SOAP) incl. WSDL. Sollte man  Java oder .NET zum externen Aufruf von Workflows nutzen wollen ist dies mittlerweile sehr einfach, da es bereits vorgefertigte Stubs und Klassen gibt die Ihr ganz normal einbinden könnt. (Informationen findet Ihr hier). Möchte man das ganze jedoch mit PHP/Perl o.ä. realisieren gibt es einige Hürden die man nehmen muss. WIr haben hierzu ein kleines Perl Skript inkl. eines Orchestrator Workflows erstellt, Ihr findet diese Dateien im Anhang dieses Blog Eintrags. Die beiden Komponenten sind bewusst sehr simpel gehalten, damit wir uns auf das wesentliche konzentrieren können, die Serialisierung/De-Serialisierung von komplexen Datentypen. Das Perl Skript durchläuft dabei folgende Schritte:

  • Es verbindet sich an den WebService von VCO
  • Es versucht unseren Workflow ‚Show GuestOS‘ zu finden
  • Dursucht alle an den VCO angeschlossen vCenter nach virtuellen Maschinen
  • Serialisiert ein Array in VMware Format mit den eindeutigen Namen der virtuellen Maschinen (dunesUri)
  • Aufruf unseres Workflows mit dem Array
  • Anschließend prüfen wir den Status des Workflows und warten auf dessen Beendigung
  • Nach Abschluss des Tasks erhalten wir von unserem Workflow ein Serialisiertes Array im VMware Format zurück, das eine Liste der Gastbetriebssystem für die übergebenen virtuellen Maschinen enthält. Wir zeigen in diesem Zusammenhang auch wie man die Informationen De-Serialisiert.

Anbei findet Ihr das vollständig Perl-Skript das den Aufruf von Workflows inkl. Serialisierung/De-Serialisierung aufzeigt. Vor-Ab sind noch folgende Schritte durchzuführen um die WebService Stubs zu generieren.

  • Perl installieren (Unter Linux ist dies in den meisten Fällen über den Paketmanager der Distribution möglich, unter Windows würde ich Strawberry Perl empfehlen)
  • SOAP::WSDL aus dem CPAN installieren, z.B. via ‚cpan SOAP::WSDL
  • Stubs aus dem WSDL generieren (In diesem Zusammenhang weise ich darauf hin das wenn Ihr die Stubs generiert einen AXIS 1.1 kompatiblen Generator nutzen müsst, unabhängig welche Programmier-/Skript- Sprache ihr verwendet.) . Im Fall von Perl nutzt Ihr ‚wsdl2perl.pl‚ was zusammen mit dem CPAN Modul installiert wurde.
#!/usr/bin/perl
use Getopt::Long;
use Pod::Usage;
use SOAP::WSDL;
use MyInterfaces::VSOWebControlService::webservice;
use MyTypes::Workflow;
use Data::Dumper;

use warnings;
use strict;

my $man = 0;
my $help = 0;
my ( $username, $password );

GetOptions(	'help|?' => $help,
		'man' => $man,
		'username=s' => $username,
		'password=s' => $password )  or pod2usage(2); 

pod2usage(1) if $help;
pod2usage(-exitstatus => 0, -verbose => 2) if $man;
unless (  defined ( $username ) && defined ( $password ) ) {
	pod2usage(message => "nSyntax error.n", -exitstatus  => 1, -verbose => 2);

}

my $workflowName = "Show GuestOS";

my $interface = MyInterfaces::VSOWebControlService::webservice->new();

# Find workflow

my $response = $interface->getWorkflowsWithName ( {
			workflowName 	=> 	$workflowName,
			username 	=> 	$username,
			password 	=> 	$password,
		},,
	);

die $response if not $response;

my $elements = $response->get_getWorkflowsWithNameReturn();
die ("Exception: There is no worklows with name: '$workflowName' in the orchestrator.") unless ( defined ($elements)  ) ;
die ("Exception: There are more than one workflow with name '$workflowName' in the orchestrator.") if ( @$elements > 1 ) ;

my $workflowId = $elements->get_id();

$response = $interface->find({
        type =>  "VC:VirtualMachine", # string
        query =>  "", # string
        username =>  $username, # string
        password =>  $password, # string
      },,
	  );
die $response if not $response;

my $vmCount = $response->get_findReturn()->get_totalCount();
die ("Exception: There are no virtual machines in the vCenter's connected to the orchestrator.") if ( ! $vmCount  ) ;

#get all virtual machines
my $vm = $response->get_findReturn()->get_elements()->get_item();

# cycle through all virutal machines and get dunes uri (unique object reference)
my @dunesUri;
for ( my $i = 0; $i < $vmCount ; $i++ ) { 	push (@dunesUri, $vm->[$i]->get_dunesUri());

}

my $vmSerialized = sprintf '#{#VC:VirtualMachine#%s#}#',join('#;#VC:VirtualMachine#', @dunesUri);

# Execute workflow

$response = $interface->executeWorkflow ( {
		workflowId 	=> 	$workflowId,
		username	=>	$username,
		password 	=> 	$password,

		workflowInputs => [ {

				name	=> 	"vms",
				type	=> 	"Array/VC:VirtualMachine",
				value	=>	"$vmSerialized"

		}]

	});
sdie $response if not $response;

my $workflowToken = $response->get_executeWorkflowReturn();

$| = 1;

my $wfStatus;
my $counter=1;
do {
	$response = $interface->getWorkflowTokenStatus( {

		workflowTokenIds 	=>  $workflowToken->get_id(),
		username 		=>  $username,
		password 		=>  $password,
		},,
	);
	$wfStatus = $response->get_getWorkflowTokenStatusReturn();
	printf ("Workflow status: %s - Time elapsed: %s seconds. n" , $wfStatus, $counter);
	sleep(1);
   	$counter++;
  } while ($wfStatus eq "running");

$response = $interface->getWorkflowTokenResult( {
        workflowTokenId         =>  $workflowToken->get_id(),
        username                =>  $username,
        password                =>  $password,
        },,
);

my $wfResult = $response->get_getWorkflowTokenResultReturn();
if ($wfStatus eq "failed") {
	printf ("Reason: %sn", $wfResult->[0]->get_value());
}else {

	my $returnSerialized =  $wfResult->[1]->get_value();
	$returnSerialized =~ s/^#{#string#(.*)#}#$/$1/;
	my @ready = split ('#;#string#', $returnSerialized);

	foreach (@ready) {
		print "$_n";
	}	

}

__END__

=head1 NAME

showGuestOSFromAllVms

=head1 SYNOPSIS

Use:

	perl showGuestOSFromAllVms.pl [--help] [--man] --username --password

Examples:

	perl showGuestOSFromAllVms.pl --help

	perl showGuestOSFromAllVms.pl --man

	perl showGuestOSFromAllVms.pl --username xxxx --password xxx

=head1 DESCRIPTION

B demonstrates the use of orchestrator webservice API with Perl. It calls the workflow 'Show GuestOS' for all VM's (Danger! It will use all SdkConnectiosn of the Orchestrator). It also demonstrates how to pass simple and complex types (inclusive serialization/desirialization) to workflows, handle exceptions and handle return values from a workflow.

=head1 ARGUMENTS

=over 8

=item B

	(Optional.) Print a brief help message and exits.

=item B

	(Optional.) Prints the manual page and exits.

=back
=cut