zur Startseite von solmera GmbH
Start Kontakt Impressum

Evolution of dPEX – Step 3

Pipelining Basics am Beispiel "DSMinitializeRequest"

Veröffentlicht am Dienstag, 12.08.2014

 

In diesem  Beitrag zeige ich, wie die bisher vorhandenen Funktionen auf ein mehr Powershell typisches Verhalten umgestellt werden können. Zu diesem Zweck baue ich die Funktion „DSMInitializeRequest“ um, damit diese dann über die Powershell-Pipeline angesprochen werden kann und ihre Ergebnisse an die Pipeline weiterleitet.

Vorarbeiten

Zur Erinnerung:
„DSMInitializeRequest“ ergänzt jeden Request an die DSM SOAP Schnittstelle um ein Header und ein Serverinfo-Objekt. Das Serverinfo-Objekt wird beim Verbindungsaufbau zum DSM Webservice bislang in verschiedenen Variablen gespeichert, die dann bei „DSMInitializeRequest“ verwendet werden müssen.

Zur Vereinfachung werden wir zukünftig das ServerInfo-Objekt als gesamtes zur weiteren Verwendung speichern.

Zusammenfassung der bisherigen Funktionen

Die bisherigen drei Funktionen

  • „DSMinitializeRequest“
  • „DSMinitializeRequestHeader“
  • „DSMinitializeRequestServerInfo“

… fassen wir zusammen und benutzen für den Namen und die Version des SOAP-Clients die Beschreibung und die Version des Moduls.  Danach melden sich die dPEX im Administrationsservice mit ihrer Versionsnummer, was ein Erkennen von veralteten Modulen erleichtert.

Die neue Variable „DSMServerinfo“ vom Type „DSM.ServerInfo“ ersetzt die Variablen MetaModelVersion, CmdbGUID und CmdbVersionString.

Umbau zur „Pipeline-Funktion“

Die Funktion „DSMinitializeRequest“ arbeitet mit einer Referenz auf das eigentliche Request-Objekt. Das ist aus Performancesicht sehr gut, die Benutzung ist aber eher umständlich, da man immer erst eine Referenz auf das neu erstellte Request-Objekt erstellen muss.

Ich möchte deshalb eine Funktion aufbauen, welche sich über die Powershell-Pipeline „füttern“ lässt, und damit einen Aufruf in der Form:

New-Object DSM.GetObjectRequest | Initialize-DSMRequest

erlaubt.

Dazu implementiere ich eine Advanced Function mit folgendem Rahmen:

Die Funktion erwartet ein [Object] als Input (das Request-Objekt) und akzeptiert diesen Input über die Pipeline (ValueFromPipeline=$true).

Der BEGIN Block wird einmal pro „Pipelinevorgang“ durchlaufen auch wenn mehrere Objekte in der Pipeline sind. Damit eignet sich der Block für ansonsten statische Dinge der Funktion. In diesem Fall sind das die Variablen und Objekte, die für alle Pipelineobjekte gleich sind.

Der PROCESS Block wird für jedes Objekt der Pipeline aufgerufen modifiziert dann das einzelne Objekt und gibt es an die weitere Pipeline weiter.

Der END Block wird nach dem letzten Pipelineobjekt aufgerufen und eignet sich für Aufräumarbeiten. Bei dieser Funktion bleibt er leer, da nur Objekte innerhalb des Funktionsscopes erstellt wurde, die eh nach dem verlassen der Funktion gelöscht werden.

Mit diesen Anpassungen kann man dann ein neues Requestobjekt so erzeugen und direkt initialisieren:

$request = New-Object DSM.GetObjectRequest | Initialize-DSMRequest

Und mit diesem PROCESS Block

… funktioniert auch die Übergabe per Referenz wieder wie gewohnt:

$request = New-Object DSM.GetObjectRequest
Initialize-DSMRequest([ref]$request)

Die neue Funktion „Initialize-DSMRequest” deckt damit alle Anforderungen ab und löst „DSMinitializeRequest“ ab. Im Modul erreichen wir das durch ein Alias auf die neue Funktion.

Set-Alias -Name DSMinitializeRequest
            -Value Initialize-DSMRequest
            -Description "Only for downward compatibility."

 

Ausblick

Noch keiner.

Download dPEX - Step 3 - V1.3.0.0
 
 
 
Autor: Lars Junkmann
 
Markiert in: Powershell, DSM, SOAP
 
 

Vertrieb und Support

Emails    
 
Free Call    
+49 (08 00) 00 765 00
kostenfreier Anruf