Windows PowerShell: PowerShell-Skripte versus PowerShell-Workflows

  • Artikel

Jeden Monat in diesem Jahr präsentieren Don Jones eine Ratenzahlung in einem 12-Teil-Tutorial auf Windows PowerShell -Workflow. Wir empfehlen Ihnen, durch die Serie in Ordnung, zu lesen, beginnend mit der Januar 2013 Spalte.

Don Jones

Arbeitsabläufe aussehen viel wie ein Windows PowerShell -Funktion oder ein Skript, aber sie sind nicht. Die Ähnlichkeit ist nur oberflächlich, und es möglicherweise gar nicht ganz durch die Haut.

Man muss bedenken, dass Windows PowerShell zu Workflows in einem völlig separaten Technologie zu übersetzen — Windows Workflow Foundation (WF). Das bedeutet, dass Sie nur tun können, was Sie in WF duplizieren können. Code läuft in eine ganz andere Art von Umgebung, die eigene Regeln und Einschränkungen hat. In der Tat können die Unterschiede zwischen einem Workflow und ein "normales" Skript beträchtlich sein.

Ein Runspace gegen viele

In einem normalen Skript läuft alles im Skript in einen einzigen Runspace, mit einer einzigen Bereichshierarchie. Ein Runspace entspricht ungefähr einem Windows PowerShell -Prozess. Wenn Sie denken der ein Windows PowerShell -Konsole-Fenster, ist einen einzigen Runspace. Das bedeutet, dass alles gleich, konsequente und beständige in diesen Runspace ist.

Variablen, Befehle, Laufwerke und alles andere beginnen alle eine Möglichkeit. Sie bleiben unverändert, es sei denn, Sie ändern. In diesen Runspace keine Änderungen Sie "kleben", für die Dauer dieses Prozesses.

In einem Workflow, jede Aktivität — jeden Befehl, Inline-Script-Block und So weiter — eigene Runspace haben können. Das heißt, wenn Sie eine Änderung in einem vornehmen, es nicht in alle anderen sichtbar wäre. Einstellung einer Variablen in einem Teil Ihres Workflows vielleicht keine Änderung in einem anderen Teil des Workflows, machen, wenn Sie besondere Maßnahmen zur sonst treffen.

Wie Sie gesehen, in haben letzten Monat Artikel, wenn Sie eine Variable auf der obersten Ebene des Workflows definieren, gibt es im gesamten Workflow (das System unternimmt Schritte um sicherzustellen, dass dies gilt). Wenn ein Befehl innerhalb des Workflows eine Variable erstellt wird, wird nicht diese Variable für den Rest des Workflows verfügbar.

Dies bedeutet Modul Nutzung auch anders ist. Importieren ein Modul in einem Punkt machen nicht unbedingt Befehle verfügbar zu einem späteren Zeitpunkt. Du musst viel mehr darauf achten, denn ein einheitlichen Workflow im wesentlichen mehrere unabhängige Bereiche erstrecken kann.

Syntaktische Unterschiede

Es gibt eine Reihe von Unterschieden in der Syntax innerhalb eines Workflows, das die ich in früheren Artikeln in dieser Serie hingewiesen habe:

  • Positionelle Parameter kann nicht verwendet werden. Sie müssen jeden Befehlsparameter buchstabieren. Wenn Sie die Ausführung von Dir C:\Windows verwendet, müssen Sie Get-ChildItem-Weg C:\Windows stattdessen lernen. Sie können weiterhin verwenden Aliase (z. B. Dir) oder Parameternamen (z. B. –Comput für – Computername) abgeschnitten.
  • Workflows können Parameter haben, aber sie können nur Buchstaben, Zahlen, unterstrich und Bindestrich im Namen enthalten. Das unterscheidet sich von normalen Windows PowerShell -Skript-Regeln.
  • Sie können kein Modul in der Workflow-Sitzung importieren. In der Tat nicht Befehle wirklich ändern die aktuelle Sitzung und haben keine Auswirkungen auf nachfolgende Befehle. Wenn ein Workflow ein Modul verwenden muss, müssen Sie den –PSRequiredModules-Aktivität-Parameter verwenden.
  • Für die InlineScript Aktivität und Befehle, die Workflow-Aktivität-Implementierungen haben, erhalten Sie eine Reihe von zusätzlichen Befehlsparametern, einschließlich des –PSRequiredModules-Parameters bereits erwähnt.
  • Methoden von Objekten kann nicht in einem Workflow ausgeführt werden, sofern Sie dies innerhalb einer Inline-Script-Block tun. Das Objekt muss innerhalb der Inline-Script-Block in Reihenfolge für die-Methode hergestellt werden.
  • Dot-Source Skripts nicht möglich.
  • Sie können nicht den "&" Aufruf-Operator verwenden.
  • Switch Konstrukte müssen den –CaseSensitive-Parameter einschließen. Das Workflow entspricht das Switch-Konstrukt wird nativ Groß-/Kleinschreibung beachtet. SWITCH-Anweisungen müssen Konstanten verwendet werden. Vergleichsoperatoren, reguläre Ausdrücke, Dateiverweise oder Skriptblöcke können nicht. Grundsätzlich versuchen Sie, Switch Konstrukte zu vermeiden.
  • Break und Continue-Anweisungen sind nicht zulässig.
  • Nur PSDrives von Windows PowerShell -Kern-Anbieter hinzugefügt — Dateisystem, Registrierung, Zertifikatspeicher, Umwelt, Funktion, Variable und WS-Management — gelten. Um einen PSDrive erstellt von einem Modul zu verwenden, führen Sie die Aktivität mit einem –PSRequiredModules-Parameter, und geben Sie den Namen des Moduls.

Ja, das ist eine Menge Unterschiede. Wenn Sie eine sorgfältige Windows PowerShell -Programmierer sind, laufen Sie gegen weniger davon, wie Ihre Parameter benennen. Sie werden immer noch Unterschiede auftreten, vergaßen Sie, bis Sie sich wirklich mit dem Schreiben von Workflows vertraut.

Boni

Windows PowerShell Workflow ist nicht alle schlechten Nachrichten Unterschiede — in der Tat, es gibt Ihnen eine Tonne von Funktionen kostenlos.  Jeder Workflow erhält integrierten Parameter, einschließlich:

  • ‑AsJob führt den Workflow als Hintergrundjob. Sie können es einen Auftragsnamen geben, mithilfe von –JobName.
  • –PSComputerName führt den Workflow auf dem angegebenen Computer oder Computer mit Windows PowerShell -Remoting.
  • –PSCredential und eine Vielzahl von zugehörigen Parametern können Sie Alternative Authentifizierungsdetails angeben.
  • –PSPort und andere verbindungsbezogenen-Parameter können Sie Alternative Konnektivität Details für die Remotingkomponente des Workflow anzugeben.

Bemerken Sie eine Anzahl von diesen Parametern mit –PS starten? Einen Namespace wird genannt. Vermeiden Sie erstellen Ihre eigenen Parameter, die auch mit –PS beginnen. Wenn eine zukünftige Version von Windows PowerShell neue Parameter hinzufügt, werden sie wahrscheinlich mit –PS anfangen. Wenn Sie in der Regel, das Präfix, das Sie mit Ihrem eigenen Parameternamen Kollisionen vermeiden vermeiden.

Nicht schlimmer, nicht besser, aber anders

Die praktische Folge hier ist, dass Workflows Windows PowerShell -Skripts nicht. Sie sind anders. Sie haben einige Unterschiede, die Ihr Leben erleichtern können. Einige andere Unterschiede können ein bisschen mehr Arbeit von Ihnen verlangen. Die Unterschiede wissen helfen Ihnen weitere Schreiben effizienter Arbeitsabläufe schnell beginnen.

Don Jones

Don Jones ist ein Windows PowerShell -MVP-Auszeichnung, Empfänger und als Redakteur beim TechNet Magazine*.*Er hat vier Bücher über Windows PowerShell Version 3, einschließlich freie Plätze auf Windows PowerShell -Remoting und Erstellen von HTML-Berichten in Windows PowerShellzusammen. Finden sie alle zur PowerShellBooks.com, oder Jones -Fragen in der Diskussionsforen auf PowerShell.org.

Verwandte Inhalte