Workflow-Konzepte in Windows PowerShell

Wichtig

Diese Version von Service Management Automation (SMA) hat das Supportende erreicht. Sie sollten ein Upgrade auf SMA 2019 durchführen.

Ein Runbooktyp für Service Management Automation basiert auf Windows PowerShell Workflows. Dieser Abschnitt bietet eine kurze Übersicht über wichtige 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 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. Wenngleich der Workflow mit Windows PowerShell-Syntax geschrieben und über Windows PowerShell gestartet wird, erfolgt die Verarbeitung durch Windows Workflow Foundation.

Grundlegende Struktur

Ein Windows PowerShell Workflow beginnt mit dem Schlüsselwort Workflow, gefolgt vom Text des Skripts, das in geschweifte Klammern eingeschlossen ist. Der Name des Workflows folgt dem Schlüsselwort Workflow, wie in der folgenden Syntax gezeigt. Der Name des Workflows stimmt mit dem Namen des Automation-Runbooks überein.

Workflow Test-Runbook
{
   <Commands>
}

Um dem Workflow Parameter hinzuzufügen, verwenden Sie das Param-Schlüsselwort, 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 Attribut „Parameter“ verwendet, mit dem angegeben wird, ob der Parameter obligatorisch ist oder nicht.

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. Für Cmdlets ohne entsprechende Aktivität führt Windows PowerShell Workflow das Cmdlet automatisch in 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 fügen 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 es das automatische Laden von Modulen, was bedeutet, dass Cmdlets aus installierten Modulen verwendet werden können, ohne sie mit Import-Modulein das Skript zu importieren.

Jedes Windows PowerShell Moduls kann in Automation importiert werden, solange sich alle Abhängigkeiten in einem einzelnen Ordner befinden können. Wenn das Modul von Registrierungseinstellungen oder Dateien abhängt, die sich nicht im Standardpfad befinden, kann es importiert werden. Es funktioniert jedoch 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. Statt einen Bereitstellungsprozess nach dem anderen auszuführen, könnten die Aktionen gleichzeitig ausgeführt werden, um die Gesamteffizienz zu erhöhen. 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 startet "Activity1" für alle Elemente in der Auflistung gleichzeitig. "Activity2" wird für alle Elemente gestartet, nachdem "Activity1" abgeschlossen wurde. "Activity3" startet erst, wenn sowohl "Activity1" als auch "Activity2" für alle Elemente abgeschlossen wurden.

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

Das Sequence-Schlüsselwort wird verwendet, um Befehle nacheinander innerhalb eines Parallel-Skriptblocks auszuführen. Der Sequence-Skriptblock wird parallel zu anderen Befehlen ausgeführt, aber die Befehle innerhalb des Blocks werden 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. „Activity5“ wird gestartet, nachdem alle anderen Aktivitäten abgeschlossen wurden.

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, und das Runbook wird angehalten. 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 Runbooks nach Aktivitäten festlegen, die fehleranfällig sind und beim Fortsetzen des Runbooks nicht wiederholt werden sollen. 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. Falls die Erstellung erfolgreich ist, später jedoch ein Fehler im Runbook auftritt, werden die virtuellen Maschinen nicht erneut erstellt, wenn Sie das Runbook fortsetzen.

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 Aktivität Suspend-Workflow an sich selbst hält. 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 Befehlsblock in einer separaten, nicht workflowbezogenen Sitzung aus und gibt die 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 werden soll.

Der InlineScript-Block verwendet die nachstehende Syntax.

InlineScript
{
  <Script Block>
} <Common Parameters>

Die häufigste Verwendung von InlineScript in einem Runbook ist das Ausführen eines Codeblocks auf einem anderen Computer. 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.

Inline script diagram

Um den Codeblock auf einem anderen Computer ausführen zu können, 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

InlineScript-Aktivitäten können zwar in bestimmten Runbooks wichtig sein, sollten aber nur bei Bedarf aus den folgenden Gründen verwendet werden:

  • Prüfpunkte können nicht innerhalb eines InlineScript-Blocks verwendet werden. 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 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 InlineScriptverwenden müssen, sollten Sie dessen Umfang minimieren. Wenn Ihr Runbook beispielsweise eine Sammlung durch iteriert, während auf jedes Element der gleiche Vorgang ausgeführt 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 verarbeiten.

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. Eine Variable namens $abc, die außerhalb von InlineScript festgelegt wurde, würde z. B. $using:abc in einem InlineScript-Objekt werden.

  • Weisen Sie die Ausgabe einer Variablen zu, und geben Sie alle Daten aus, die an den Ausgabestream zurückgegeben werden sollen, um die Ausgabe eines InlineScript-Skriptszurück zu geben. Im folgenden Beispiel wird die Zeichenfolge "hi" einer Variablen namens $output.

    $output = InlineScript { Write-Output "hi" }
    
  • Vermeiden Sie das Definieren von Workflows im InlineScript-Bereich. Obwohl einige Workflows möglicherweise ordnungsgemäß ausgeführt werden, wurde dieses Szenario nicht getestet. Daher können verwirrende Fehlermeldungen oder ein unerwartetes Verhalten auftreten.

Weitere Informationen zur Verwendung von InlineScript findenSie unter Running Windows PowerShell Commands in a Workflow and about_InlineScript.

Nächste Schritte

Erstellen von Automation Runbooks