Windows PowerShell : Activités de workflow en détail
Chaque mois de cette année, Don Jones présentera une tranche dans un tutoriel de 12 parties le Workflow Windows PowerShell . Nous vous encourageons à lire la série dans l'ordre, commençant par la janvier 2013 colonne.
Don Jones
Lorsque vous écrivez un workflow dans Windows PowerShell, vous devez retenir que chaque commande doit être traduit en un Windows Workflow Foundation (WF) ou une activité InlineScript.
Tout d'abord, ce qui est une activité ? Flux de travail de Windows PowerShell est finalement traduit en quelque chose que WF comprend. Ce que comprend le WF est activités. Dans WF, une activité est une seule action qui se déroule au sein d'un workflow.
La plupart des commandes Windows PowerShell noyau ont des activités équivalentes. Ces activités sont complètement distinctes des commandes. En d'autres termes, l'équipe de Microsoft a dû s'asseoir et écrire les deux la commande Windows PowerShell — tels que Where-Object — et une activité WF correspondante qui fait la même chose.
Donc, ils sont vraiment deux structures parallèles. Lorsque vous utilisez une commande dans un workflow, Windows PowerShell vérifie si il y a eu une activité équivalente écrit et installé sur l'ordinateur. S'il y en a un, alors c'est ce que le flux de travail utilisera.
Il s'agit d'une considération importante. Il est tout à fait possible qu'autres équipes de Microsoft et même des tierces parties, sera auteur les activités à l'avenir. Avant de pouvoir les utiliser, cependant, ils doivent être installés et inscrits sur n'importe quel ordinateur exécutera les workflows que vous écrivez. Comment vous y prendre, qui sera différent d'un produit.
Absence d'activité
Si vous utilisez une commande qui n'est pas une activité WF équivalente, Windows PowerShell enveloppera la commande dans un bloc de InlineScript implicit. InlineScript est une activité reconnue nativement par WF. Fondamentalement, il raconte WF pour lancer une copie de Windows PowerShell, exécutez la commande et puis fermez cette copie de Windows PowerShell.
Parce que l'emballage InlineScript peut survenir implicitement — ce qui signifie vous ne voyez pas ce qui se passe — vous pouvez être complètement inconscients que ça se passe. Dans Windows PowerShell 3.0, en fait, il est difficile de comprendre quelles commandes possèdent des équivalents WF et ceux qui ne. Vous pourriez ne jamais être en mesure de dire ce qui est géré comme une activité autochtone et ce qui est enveloppé dans un InlineScript. Pour la plupart, vous n'avez pas besoin de savoir. Il crée cependant, certains effets.
Si vous deviez essayer ceci, par exemple, il échouerait :
Workflow My-Workflow { Import-Module DHCPServer Get-DHCPServerv4Scope }
Le flux de travail échoue car il n'y a aucune activité WF pour Import-Module. Chaque activité doit se passer dans son propre processus (plus ou moins). N'oubliez pas de vous pouvez interrompre et reprendre plus tard un flux de travail, ce qui signifie chaque commande doit faire son propre programme d'installation et le démontage. Rien ne peut compter sur rien d'autre après avoir couru dans la même mémoire ou processus. Windows PowerShell ne sera pas envelopper Import-Module dans un InlineScript car cela ouvrez Windows PowerShell, exécutez Import-Module et puis fermez Windows PowerShell. Cela serait effectivement décharger le module et rendre l'ensemble de l'exercice inutile.
Ce qui suit, toutefois, va travailler :
Workflow My-Workflow { InlineScript { Import-Module DHCPServer Get-DHCPServerv4Scope } }
Cela ajoute un bloc de InlineScript explicit. Cela signifie que les deux commandes s'exécutent dans la même session Windows PowerShell .
Blocs InlineScript
Vous pouvez probablement imaginer combien de vos flux de production pourrait être divisée en un ou plusieurs blocs InlineScript. Après tout, si vous devez exécuter plusieurs commandes dans un processus et ont ces commandes à partager les résultats et sortie, puis un InlineScript est le chemin à parcourir.
N'oubliez pas que chaque InlineScript est son propre processus de Windows PowerShell autonome. Par exemple, cela ne marchera pas :
Workflow My-Workflow { InlineScript { Import-Module DHCPServer $scopes = Get-DHCPServerv4Scope } InlineScript { ForEach ($scope in $scopes) { Write $scope.IPAddress } } }
La variable $scopes créée dans la première InlineScript n'existe pas dans le second. Le code va échouer ou simplement ne rien faire. Maintenant vous pouvez penser, « pourquoi ne je viens de mettre tout dans un seul bloc InlineScript? » Vous pourriez :
Workflow My-Workflow { InlineScript { Import-Module DHCPServer $scopes = Get-DHCPServerv4Scope ForEach ($scope in $scopes) { Write $scope.IPAddress } } }
Le problème que vous rencontrez maintenant, c'est que votre flux de travail se compose d'une seule activité. WF prend uniquement en charge la reprise et des points de contrôle inter-activités. Votre flux de travail simple-activité ne peut pas être suspendu, a repris ou interrompu.
À bien des égards, vous avez supprimé les avantages de faire un workflow en premier lieu. Vous obtenez toujours un support intégré pour l'exécution à distance. Si il s'agissait d'un processus à plusieurs étapes longues, cependant, vous ne pouvait pas survivre à un échec (comme une panne réseau d'interruption ou de la puissance) et reprendre là où vous a laissé.
Workflow devient donc un puzzle architectural intéressant. Vous souhaitez que chaque tâche aussi discret et autonome que possible. Ce faisant, vous pouvez obtenir un soutien maximal pour l'interruption et la reprise. Cependant, vous êtes limité par la limite de processus d'échange d'information entre les commandes.
En fait, ce qui rendrait Windows PowerShell Workflow beaucoup plus utile est la possibilité pour une activité à conserver les informations dans un magasin externe (comme le SQL Server). Un moyen autre que l'activité pourrait ramasser et utiliser cette information. Tel un magasin externe deviendrait une sorte de magasin variable persistante, externe.
Malheureusement, Windows PowerShell en mode natif n'offre pas une telle chose. Il n'y a aucune raison, cependant, que vous ne pouvait pas construire quelque chose comme ça sur votre propre.
.jpg)
**Don Jones**est une récompense de MVP Windows PowerShell destinataire et un rédacteur de contribution à TechNet Magazine. Il a co-écrit quatre livres sur Windows PowerShell version 3, y compris celles qui sont libres sur Windows PowerShell remoting et de création de rapports HTML dans Windows PowerShell. Trouvez-les tous à PowerShellBooks.com, ou poser des questions de Jones dans les forums de discussion à PowerShell.org.