Workflow-Konzepte in Windows PowerShell

Wichtig

Diese Version von Service Management Automation (SMA) hat das Ende des Supports erreicht. Es wird empfohlen, ein Upgrade auf SMA 2022 durchzuführen.

Ein Runbooktyp für die Automatisierung der Dienstverwaltung basiert auf Windows PowerShell Workflows. Dieser Artikel bietet eine kurze Übersicht über die wichtigen Features von Workflows, die für Automation-Runbooks üblich sind. Ausführliche Informationen zu Workflows finden Sie unter Einführung in Windows PowerShell Workflow.

Die Runbookstruktur ist zwischen Runbooks für Service Management Automation und für Microsoft Azure Automation identisch, obwohl die beiden in der Regel mit unterschiedlichen Ressourcen funktionieren.

Windows PowerShell-Workflows

Bei einem Workflow handelt es sich um eine Sequenz von programmierten, zusammenhängenden Schritten, mit denen zeitaufwendige Aufgaben ausgeführt werden oder für die mehrere Schritte auf mehreren Geräten oder verwalteten Knoten koordiniert werden müssen. Die Vorteile eines Workflows gegenüber einem normalen Skript liegen darin, dass eine Aktion gleichzeitig für mehrere Geräte ausgeführt und bei Auftreten von Fehlern eine automatische Wiederherstellung durchgeführt werden kann. Ein Windows PowerShell-Workflow ist ein Windows PowerShell-Skript, das Windows Workflow Foundation nutzt. Während der Workflow mit Windows PowerShell Syntax geschrieben und von Windows PowerShell gestartet wird, wird er von Windows Workflow Foundation verarbeitet.

Grundlegende Struktur

Ein Windows PowerShell Workflow beginnt mit dem Workflow-Schlüsselwort (keyword) gefolgt vom Textkörper des Skripts, der in Klammern eingeschlossen ist. Der Name des Workflows folgt dem Workflow-Schlüsselwort (keyword), wie in der folgenden Syntax gezeigt. Der Name des Workflows entspricht dem Namen des Automation-Runbooks.

Workflow Test-Runbook
{
   <Commands>
}

Verwenden Sie zum Hinzufügen von Parametern zum Workflow die Param-Schlüsselwort (keyword), wie in der folgenden Syntax gezeigt. Wenn der Benutzer das Runbook startet, wird er vom Verwaltungsportal aufgefordert, Werte für diese Parameter anzugeben. In diesem Beispiel wird das optionale Parameter-Attribut verwendet, das angibt, ob der Parameter obligatorisch ist.

Workflow Test-Runbook
{
  Param
  (
   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>,

   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>
  )
  <Commands>
}

Benennung

Der Name des Workflows sollte dem Format „Verb-Substantiv“ folgen. Dies ist das Standardformat bei Windows PowerShell. Eine Liste mit zulässigen Verben finden Sie unter Approved Verbs for Windows PowerShell Commands (Zulässige Verben für Windows PowerShell-Befehle) . Der Name des Workflows muss mit dem Namen des Automation-Runbooks übereinstimmen. Wenn das Runbook importiert wird, muss der Dateiname mit dem Workflownamen übereinstimmen und auf .ps1 enden.

Einschränkungen

Eine vollständige Liste der Einschränkungen und Syntaxunterschiede zwischen Windows PowerShell-Workflows und Windows PowerShell finden Sie unter Syntaxunterschiede zwischen Skriptworkflows und Skripts.

activities

Eine Aktivität ist eine bestimmte Aufgabe in einem Workflow. Ebenso wie ein Skript aus einem oder mehreren Befehlen zusammengesetzt ist, setzt sich ein Workflow aus einer oder mehreren Aktivitäten zusammen, die in einer bestimmten Reihenfolge ausgeführt werden. Windows PowerShell Workflow konvertiert viele der Windows PowerShell-Cmdlets automatisch in Aktivitäten, wenn ein Workflow ausgeführt wird. Wenn Sie eines dieser Cmdlets in Ihrem Runbook angeben, wird von Windows Workflow Foundation tatsächlich die entsprechende Aktivität ausgeführt. Bei Cmdlets ohne entsprechende Aktivität führt Windows PowerShell Workflow das Cmdlet automatisch innerhalb einer InlineScript-Aktivität aus. Es gibt eine Reihe von Cmdlets, die ausgeschlossen sind und nicht in einem Workflow verwendet werden können, es sei denn, Sie schließen sie explizit in einen InlineScript-Block ein. Weitere Informationen zu diesen Konzepten finden Sie unter Verwenden von Aktivitäten in Skriptworkflows.

Workflowaktivitäten teilen sich einen Satz allgemeiner Parameter, um ihren Betrieb zu konfigurieren. Ausführliche Informationen zu den allgemeinen Workflowparametern finden Sie unter about_WorkflowCommonParameters.

Integrationsmodule

Ein Integrationsmodul ist ein Paket, das ein Windows PowerShell Modul enthält und in Automation importiert werden kann. Windows PowerShell Module enthalten Cmdlets, die in Automation-Runbooks verwendet werden können. Produkte und Dienste wie Operations Manager und Azure haben Module, die für den Betrieb spezifische Cmdlets enthalten.

Integrationsmodule, die in Automation importiert werden, sind automatisch für alle Runbooks verfügbar. Da Automation auf Windows PowerShell 4.0 basiert, unterstützt sie das automatische Laden von Modulen, was bedeutet, dass Cmdlets aus installierten Modulen verwendet werden können, ohne sie mit Import-Module in das Skript zu importieren.

Jedes Windows PowerShell Moduls kann in Automation importiert werden, solange sich alle zugehörigen Abhängigkeiten in einem einzigen Ordner befinden können. Wenn das Modul von Registrierungseinstellungen oder Dateien abhängt, die sich nicht im Standardpfad befinden, kann es importiert werden, funktioniert aber höchstwahrscheinlich nicht, da Automation seine Abhängigkeiten nicht finden kann. Module mit externen Abhängigkeiten können in einem Runbook verwendet werden, wenn sie auf einem anderen Host installiert sind, und mit einem InlineScript -Skriptblock kann dann auf sie zugegriffen werden.

Mit Service Management Automation können Sie Module mit externen Abhängigkeiten verwenden, indem Sie sie auf jedem Workerserver installieren. Obwohl die Cmdlets in diesen Modulen in Runbooks verwendet werden können, werden sie von Automation nicht ermittelt, um Funktionen wie den Assistenten zum Einfügen von Aktivitäten zu unterstützen. Wenn Sie diese Funktion nutzen möchten, können Sie ein portables Modul mit dem Cmdlet New-SmaPortableModule erstellen. Dieses Cmdlet erstellt ein Modul, das einen Stub für jedes seiner Cmdlets enthält und in Automation importiert werden kann. Wenn eines dieser Cmdlets von einem Runbook verwendet wird, wird der Aufruf vom Stub an das eigentliche Cmdlet im externen Modul umgeleitet. Dieses Modul muss auf jedem Workerserver installiert sein. Andernfalls wird der Aufruf mit einem Fehler abgebrochen.

Parallelausführung

Ein Vorteil von Windows PowerShell-Workflows besteht darin, dass sie einen Satz an Befehlen parallel – und nicht wie in einem typischen Skript sequenziell – ausführen können. Dies ist bei Runbooks besonders hilfreich, da möglicherweise mehrere Aktionen ausgeführt werden, die eine längere Zeit benötigen. Beispielsweise stellt ein Runbook möglicherweise eine Reihe von virtuellen Maschinen bereit. Anstatt jeden Bereitstellungsprozess nacheinander durchzuführen, könnten die Aktionen gleichzeitig ausgeführt werden, wodurch die Gesamteffizienz erhöht wird. Erst wenn alle Aktionen abgeschlossen wären, würde das Runbook fortgesetzt.

Sie können mit dem Schlüsselwort Parallel einen Skriptblock mit mehreren Befehlen erstellen, die gleichzeitig ausgeführt werden. Diese Methode wird in der nachstehend gezeigten Syntax verwendet. In diesem Fall starten "Activity1" und "Activity2" gleichzeitig. "Activity3" startet erst, wenn sowohl "Activity1" als auch "Activity2" abgeschlossen wurden.

Parallel
{
  <Activity1>
  <Activity2>
}
<Activity3>

Sie können das Konstrukt ForEach -Parallel verwenden, um Befehle für jedes Element in einer Auflistung gleichzeitig zu verarbeiten. Die Elemente in der Auflistung werden parallel ausgeführt, während die Befehle im Skriptblock sequenziell ausgeführt werden. Diese Methode wird in der nachstehend gezeigten Syntax verwendet. In diesem Fall wird Activity1 für alle Elemente in der Auflistung gleichzeitig gestartet. "Activity2" wird für alle Elemente gestartet, nachdem "Activity1" abgeschlossen wurde. Aktivität3 wird erst gestartet, nachdem Aktivität1 und Aktivität2 für alle Elemente abgeschlossen sind.

ForEach -Parallel ($<item> in $<collection>)
{
  <Activity1>
  <Activity2>
}
<Activity3>

Die Sequenz-Schlüsselwort (keyword) wird verwendet, um Befehle in Sequenz in einem parallelen Skriptblock auszuführen. Der Sequenzskriptblock wird parallel zu anderen Befehlen ausgeführt, die Befehle im Block werden jedoch sequenziell ausgeführt. Diese Methode wird in der nachstehend gezeigten Syntax verwendet. In diesem Fall werden „Activity1“, „Activity2“ und „Activity3“ zur selben Zeit gestartet. „Activity4“ wird erst gestartet, wenn „Activity3“ abgeschlossen wurde. Aktivität5 wird gestartet, nachdem alle anderen Aktivitäten abgeschlossen sind.

Parallel
{
  <Activity1>
  <Activity2>

  Sequence
  {
   <Activity3>
   <Activity4>
  }
}
<Activity5>

Prüfpunkte

Ein Prüfpunkt ist ein Snapshot des aktuellen Status des Workflows, in dem die aktuellen Variablenwerte und alle bis zu diesem Zeitpunkt generierten Ausgaben enthalten sind. Der letzte Prüfpunkt, der in einem Runbook abgeschlossen werden soll, wird in der Automation-Datenbank gespeichert, sodass der Workflow auch bei einem Ausfall fortgesetzt werden kann. Nach Abschluss des Runbookauftrags werden die Prüfpunktdaten gelöscht.

Sie können mithilfe der Aktivität Checkpoint-Workflow einen Prüfpunkt in einem Workflow setzen. Wenn Sie diese Aktivität einem Runbook hinzufügen, wird umgehend ein Prüfpunkt erstellt. Falls das Runbook aufgrund eines Fehlers angehalten wird, kann es ab dem Punkt des zuletzt festgelegten Prüfpunkts fortgesetzt werden.

Im folgenden Beispielcode tritt nach Activity2 ein Fehler auf, der dazu führt, dass das Runbook angehalten wird. Wenn der Auftrag fortgesetzt wird, wird er mit der Ausführung von „Activity2“ fortgesetzt, da hier der letzte Prüfpunkt festgelegt wurde.

<Activity1>
Checkpoint-Workflow
<Activity2>
<Error>
<Activity3>

Sie sollten Prüfpunkte in einem Runbook nach Aktivitäten festlegen, die möglicherweise fehleranfällig sind und nicht wiederholt werden sollten, wenn das Runbook fortgesetzt wird. Beispiel: Von Ihrem Runbook wird eine virtuelle Maschine erstellt. Sie können sowohl vor als auch nach den Befehlen zum Erstellen des virtuellen Computers einen Prüfpunkt setzen. Falls bei der Erstellung ein Fehler auftritt, werden die Befehle wiederholt, wenn Sie das Runbook fortsetzen. Wenn die Erstellung erfolgreich war, das Runbook jedoch später fehlschlägt, wird der virtuelle Computer nicht mehr erstellt, wenn das Runbook fortgesetzt wird.

Weitere Informationen zu Prüfpunkten finden Sie unter Hinzufügen von Prüfpunkten zu einem Skriptworkflow.

Anhalten eines Runbooks

Sie können erzwingen, dass sich ein Runbook mit der Suspend-Workflow-Aktivität ansetzt. Von dieser Aktivität wird ein Prüfpunkt festgelegt, und der Workflow wird sofort angehalten. Das Anhalten von Workflow ist hilfreich bei Runbooks, bei denen ein manueller Schritt erforderlich ist, bevor weitere Aktivitäten ausgeführt werden können.

Weitere Informationen zum Anhalten eines Workflows finden Sie unter Making a Workflow Suspend Itself (Automatisches Anhalten eines Workflows).

InlineScript

Die InlineScript-Aktivität führt einen Block von Befehlen in einer separaten Sitzung ohne Workflow aus und gibt seine Ausgabe an den Workflow zurück. Wenngleich die Befehle in einem Workflow zur Verarbeitung an Windows Workflow Foundation gesendet werden, werden die Befehle in einem InlineScript-Block durch Windows PowerShell verarbeitet. Die Aktivität verwendet die allgemeinen Standardparameter des Workflows, einschließlich PSComputerName und PSCredential, mit denen Sie angeben können, dass der Codeblock auf einem anderen Computer oder mit alternativen Anmeldeinformationen ausgeführt wird.

Der InlineScript-Block verwendet die nachstehende Syntax.

InlineScript
{
  <Script Block>
} <Common Parameters>

Die häufigste Verwendung von InlineScript in einem Runbook besteht darin, einen Codeblock auf einem anderen Computer auszuführen. Dies ist erforderlich, wenn Cmdlets in Ihrem Runbook nicht in Automation installiert sind oder wenn die Aktion nur über Berechtigungen verfügt, die lokal auf dem Zielcomputer ausgeführt werden können. Dies wird im folgenden Diagramm veranschaulicht.

Um den Codeblock auf einem anderen Computer auszuführen, werden die Parameter PSComputer und PSCredential mit der InlineScript-Aktivität verwendet. In einem Runbook wird normalerweise eine globale Ressource wie Credential oder Connection verwendet, um Werte für diese Parameter anzugeben. Mit dem folgenden Beispielcode wird eine Reihe von Befehlen auf einem Computer ausgeführt, der durch eine Verbindung namens „MyConnection“ angegeben wird.

$con = Get-AutomationConnection -Name 'MyConnection'
$securepassword = ConvertTo-SecureString -AsPlainText -String $con.Password -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $con.Username, $securepassword
InlineScript
{
  <Commands>
} -PSComputer $con.ComputerName -PSCredential $cred

Obwohl InlineScript-Aktivitäten in bestimmten Runbooks kritisch sein können, sollten sie nur verwendet werden, wenn dies aus den folgenden Gründen erforderlich ist:

• Sie können keine Prüfpunkte innerhalb eines InlineScript-Blocks verwenden. Wenn im Block ein Fehler auftritt, muss der gesamte Block wiederholt werden.

• InlineScript wirkt sich auf die Skalierbarkeit des Runbooks aus, da es die Windows PowerShell Sitzung für die gesamte Länge des InlineScript-Blocks enthält.

• Aktivitäten wie Get-AutomationVariable und Get-AutomationPSCredential sind in einem InlineScript-Block nicht verfügbar.

Wenn Sie ein InlineScript verwenden müssen, sollten Sie dessen Bereich minimieren. Wenn Ihr Runbook beispielsweise eine Auflistung durchläuft, während der gleiche Vorgang auf jedes Element angewendet wird, sollte die Schleife außerhalb von InlineScript auftreten. Dies bietet die folgenden Vorteile:

• Sie können nach jedem Durchlauf einen Prüfpunkt festlegen. Wenn der Auftrag angehalten oder unterbrochen und dann wieder fortgesetzt wird, kann die Schleife fortgesetzt werden.

• Sie können ForEach "Parallel " verwenden, um Sammlungselemente gleichzeitig zu behandeln.

Beachten Sie die folgenden Empfehlungen, wenn Sie in Ihrem Runbook ein InlineScript verwenden:

• Sie können jedoch mit dem Bereichsmodifizierer $Using Werte an das Skript übergeben. Beispielsweise würde eine Variable namens $abc, die außerhalb von InlineScript festgelegt wurde, in einem InlineScript $using:abc werden.

• Um die Ausgabe eines InlineScript-Elements zurückzugeben, weisen Sie die Ausgabe einer Variablen zu und geben alle Daten aus, die an den Ausgabedatenstrom zurückgegeben werden sollen. Im folgenden Beispiel wird die Zeichenfolge hi einer Variablen namens $output zugewiesen.

  $output = InlineScript { Write-Output "hi" }
  

• Vermeiden Sie das Definieren von Workflows im InlineScript-Bereich . Obwohl einige Workflows möglicherweise ordnungsgemäß funktionieren, ist dies kein getestetes Szenario. Daher können verwirrende Fehlermeldungen oder ein unerwartetes Verhalten auftreten.

Weitere Informationen zur Verwendung von InlineScript finden Sie unter Ausführen Windows PowerShell Befehle in einem Workflow und about_InlineScript.

Nächste Schritte

• Erstellen von Automatisierungsrunbooks.