hin255 - Fotolia
Workflows oder Skripte: Vor- und Nachteile beim Arbeiten mit der PowerShell
PowerShell-Skripte haben ihre Stärken – und einige kleine Schwächen. Mit PowerShell-Workflows lassen sich einige dieser Einschränkungen umgehen.
PowerShell-Skripte sind seit Jahren weit verbreitet und erfreuen sich unter Administratoren großer Beliebtheit. Skripte sind aber nicht die einzige Möglichkeit, PowerShell-Code auszuführen. Zum herkömmlichen Scripting bietet die PowerShell nämlich eine Alternative, die einige Vorteile mit sich bringt.
Workflows und Skripte der PowerShell sind sich sehr ähnlich: beide bestehen aus einer Abfolge programmatischer Schritte oder Aktivitäten. PowerShell kann mit dem Betriebssystem Windows interagieren, tauscht sich aber auch auf tieferer Ebene mit einigen Serveranwendungen aus. Damit können Administratoren so ziemlich jede denkbare Aufgabe auch programmatisch abarbeiten lassen.
Und trotzdem weist die PowerShell Einschränkungen auf, die aber durch die Einbeziehung des .NET Frameworks von der PowerShell aus aufgelöst werden können. Mit .NET können beispielsweise grafische Schnittstellen über Skripte angesprochen werden. Auch mathematische Operationen, die das .NET Framework anbietet, können reichhaltiger sein als das eigene Angebot der PowerShell.
PowerShell Workflows arbeiten mit der Windows Workflow Foundation (WWF), die Teil des .NET Frameworks ist. Sie umfassen eine Programmierschnittstelle und eine Workflow Engine, die dem Erzeugen von Workflows dient. Ähnlich wie Skripte bestehen auch Workflows aus einer Aneinanderreihung von Aktivitäten, von denen jede einzelne eine bestimmte Aufgabe erfüllt. Mehrere solcher Aktivitäten lassen sich in einem komplexen PowerShell-Workflow zusammenfassen.
Diese Aktivitäten werden dann als .NET-Aktivitäten modelliert. Das .NET Framework bietet eine Bibliothek an, die bereits die gängigsten Aktivitäten zum Anlegen von .NET-Workflows enthält. Mit dieser Funktionalität können Administratoren ihre eigenen Aktivitäten erstellen und vergleichbare Workflows in der PowerShell abbilden.
Weitere Artikel zur PowerShell:
Kostenloses E-Handbook zu PowerShell-Grundlagen
Die 25 wichtigsten PowerShell-Befehle
Tipps zur Konfiguration der PowerShell-Ausführungsrichtlinie
Workflows und Skripte: Die Grenzen der PowerShell
PowerShell-Skripte können durch den Griff in das erweiterte Angebot des .NET Frameworks außerordentlich funktionsstark werden. Allerdings bleibt es auch damit dabei, dass PowerShell-Skripte an einen Prozess des Betriebssystems gebunden sind. Öffnet man zum Beispiel ein PowerShell-Fenster und startet ein PowerShell-Skript, so gehört dieses Fenster zu einem Prozess, der die Ausführungsumgebung für dieses Skript wird. Im Grunde ist ein PowerShell-Fenster also eine Sandbox-Umgebung.
Diese Prozessisolierung ist in vielen Fällen sinnvoll und hilfreich, sie kann aber auch Probleme verursachen. Öffnet man etwa ein PowerShell-Fenster, legt wie in Abbildung 1 eine Variable $A an und versucht dann, diese Variable von einem anderen PowerShell-Fenster aus anzusprechen, so schlägt dieser Zugriff aufgrund der Isolierung der unterschiedlichen PowerShell-Prozessumgebungen für die PowerShell-Fenster fehl.
Vorteile von PowerShell-Workflows
PowerShell-Workflows sind dagegen nicht an ein PowerShell-Fenster gebunden. Daher können sie auch auf mehreren unterschiedlichen Geräten simultan ablaufen. So kann man beispielsweise auch mehrere Workflows simultan und parallel betreiben. Dadurch können Runbooks mit gesonderten Aktivitäten erstellt werden, die simultan statt nacheinander ablaufen. Dadurch wird die Abarbeitung der Aufgaben, etwa das Provisionieren virtueller Maschinen, erheblich effizienter.
Auch ein größeres Problem wird von PowerShell-Workflows adressiert: Läuft ein PowerShell-Skript während des Systemneustarts, so geht jeglicher Fortschritt verloren – das Skript muss komplett neu ausgeführt werden. PowerShell-Workflows können den Fortschritt im Blick behalten und können ihre Aufgaben somit nach einem Neustart, dem Verlust der Netzwerkverbindung oder nach anderen Unterbrechungen fortführen. Ein weiterer Vorteil: PowerShell-Workflows lassen sich auch ohne Kenntnisse des .NET Framework nutzen.
Grundsätzlich eignen sich alle längeren und komplexen Skripte auch für PowerShell-Workflows. Allerdings wird nicht jedes PowerShell-Cmdlet für die Nutzung in Workflows unterstützt. Dies wiederum relativiert sich allerdings durch die Nutzbarkeit der Funktion InlineScript, die auch nicht-unterstützte Kommandos in Workflows integrieren kann. Mehrere PowerShell-Workflows können simultan ablaufen, aber jeder Workflow hat seine eigene Prozessumgebung. Daher können andere Workflows im Zweifelsfall nicht auf Änderungen der Umgebungsbedingungen reagieren, etwa auf die Deklaration einer Variable in einem einzelnen Workflow.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
