Windows PowerShell : Ressemble beaucoup à un workflow
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 grâce à la série dans l'ordre, commençant par la janvier 2013 colonne.
Don Jones
Les workflows apparence un peu comme les scripts ou les fonctions Windows PowerShell — mais ils ne le sont pas. Cette similitude n'a fleur de peau, et peut-être il n'est pas même s'étendre tout au long de la peau.
Il faut toujours se rappeler que Windows PowerShell doit traduire des workflows dans une technologie totalement distincte — Windows Workflow Foundation (WF). Cela signifie que vous ne pouvez faire des choses qui peuvent être dupliquées dans le pare-feu Windows. Ensuite, le code s'exécutera dans un tout autre genre d'environnement qui a ses propres règles et restrictions.
Exécuter un script comme un flux de travail
Pour exécuter un workflow, la méthode la plus simple consiste à simplement exécuter tout script Windows PowerShell standard comme un flux de travail. Vous pouvez faire cela avec la commande Invoke-AsWorkflow. Cette commande vit dans le module PSWorkflow, bien que Windows PowerShell version 3 devrait être en mesure de découvrir et d'exécuter la commande sans que vous ayez besoin de charger explicitement le module tout d'abord. Cette commande encapsule essentiellement votre script entier dans un bloc InlineScript, ce qui signifie qu'il s'exécute dans WF comme une seule étape.
Cela signifie que vous ne devrez pas vous soucier de Windows PowerShell restriction de flux de travail. Cependant, aussi ne vous profiter de certaines fonctionnalités de flux de travail de Windows PowerShell , comme la possibilité de reprendre un processus interrompu. Dans ce cas, votre « process » comprendra de l'ensemble du script en cours d'exécution en une seule étape. N'a aucun moyen pour cela reprendre à mi-chemin à travers si vous devez suspendre ou interrompre. Voici un exemple, dans lequel j'ai créé un bloc de script avec un peu de commandes et puis les exécuter comme un flux de travail :
$script = { $name = Get-Content Env:\COMPUTERNAME $name | Out-File c:\MyName.txt Get-Service } Invoke-AsWorkflow -Expression $script -PSComputerName DC,CLIENT
J'ai utilisé une variable ici une des raisons était de démontrer que WF tout cela fonctionne comme un InlineScript unique. N'oubliez pas que chaque commande WF exécute obtient son propre environnement frais. Il n'y a aucun moyen intégré pour rendre persistantes les données entre les commandes. Cela signifie que les variables sont nativement assez inutiles. Cependant, parce que tout cela est implicitement encapsulé comme un InlineScript seule étape, la variable que j'ai créé persistera tout au long.
Alors pourquoi vous ennuyer ? Windows PowerShell Flux de travail vous donne encore quelques avantages supplémentaires. Il y a un certain nombre de paramètres partagés par tous les workflows. Ceux-ci vous permettent de spécifier des choses telles que des noms d'ordinateurs cible et ainsi de suite. Votre script héritera d'une infrastructure de base pour un travail multiserveur. Pour les scripts de longue durée, vous pouvez démarrer un flux de travail, puis déconnectez de l'ordinateur distant, tandis que le flux de travail continue à couler, ce qui est agréable.
Syntaxe formelle de flux de travail
Voici un workflow très simple :
Workflow New-Server { Get-Content -Path Env:\COMPUTERNAME | Out-File -FilePath C:\MyName.txt Get-NetAdapter -Physical } New-Server -PSComputerName CLIENT,DC
Flux de travail est une sorte de commande Windows PowerShell , comme une applet de commande, le script ou la fonction. Cela étant le cas, vous pouvez les exécuter simplement en appelant leur nom, comme je l'ai fait sur la dernière ligne de cet exemple. N'oubliez pas, tous les workflows héritent d'un certain nombre de paramètres intégrés, tels que –PSComputerName. Flux de travail s'appuient également sur la fonctionnalité d'accès distant Windows PowerShell , qui est activée sur les deux ordinateurs dans cet exemple.
Le résultat pratique est que les deux commandes du flux de travail sont déroulent directement sur les ordinateurs distants, avec les résultats en revenir à mon ordinateur. Je n'avais pas de code rien de tout cela, ou même créer un paramètre de nom d'ordinateur. Je n'avais pas d'énumérer les noms d'ordinateurs, de créer des connexions, ou toute autre chose. Windows PowerShell Flux de travail le fait tout pour moi. Il n'y a absolument rien dans ce script, je ne pouvais pas parvenus sans Windows PowerShell Workflow — il faudrait juste un peu plus de travail de ma part.
Vous remarquerez que j'ai énoncé les noms de commande dans mon flux de travail. J'ai aussi utilisé des paramètres nommés dans tous les cas. C'est toujours une pratique exemplaire dans n'importe quel script Windows PowerShell , mais il est obligatoire dans un workflow. Vous ne pouvez pas utiliser les paramètres positionnels. Il faut tout préciser ou vous obtiendrez une erreur.
Découvrez maintenant ce flux de travail (pas que vous aurez besoin d'importer de la session PSWorkflow dans votre instance de coquille afin que le mot-clé « Workflow » d'être légales) :
Workflow New-Server { $name = Get-Content -Path Env:\COMPUTERNAME Get-Content -Path Env:\COMPUTERNAME | Out-File -FilePath C:\MyName.txt Get-NetAdapter -Physical $name | Out-File -FilePath C:\MyOtherName.txt } New-Server -PSComputerName CLIENT,DC
Quand j'ai d'abord écrit cet exemple, j'ai pensé: « MyOtherName.txt sera vide. » N'oubliez pas, le contenu de chaque flux de travail exécuté comme une commande distincte, sans contexte partagé entre eux. Lorsque j'ai exécuté cet exemple, cependant, cela a fonctionné. En effet, le nom de l'ordinateur a été écrit à la fois MyName.txt et MyOtherName.txt. Ce qui donne ?
Windows PowerShell ne fait beaucoup de choses sous le capot pour tenter de s'assurer que vous obtenez les résultats que vous attendez dans un flux de travail. Par exemple, une commande de flux de travail « normal » est écrit de manière très spécifique. WF nativement impossible d'exécuter n'importe quelle cmdlet Windows PowerShell vieux. L'équipe Windows PowerShell fournit des équivalents WF pour une énorme liste d'applets de commande native, donc il n'y a souvent un mappage un à un entre les applets de commande et activités WF.
Lorsque vous utilisez une applet de commande qui n'est pas une activité correspondante, Windows PowerShell inclut implicitement dans votre code dans une activité WF InlineScript. Qui a pour effet de rendre WF exécuter Windows PowerShell, exécuter votre commande Windows PowerShell et ensuite récupérer les résultats dans WF. Donc beaucoup de choses qui « ne devrait pas » travailler fonctionnera, car Windows PowerShell il hacks ensemble pour vous.
Le danger ici est que dépannage peut devenir incroyablement difficile, parce que vous ne serez pas toujours en mesure de voir ce que fait Windows PowerShell sous le capot. Dans le cas de cet exemple, Windows PowerShell garantit que les variables de niveau supérieur persistent tout au long du flux de travail.
Là où nous allons prochaines
Croyez-le ou non, vous avez déjà assez pour commencer à écrire des workflows de base. Vous pouvez avoir ces cibler n'importe quel ordinateur où vous avez installé Windows PowerShell version 3 et activé l'accès distant. Une partie de la raison pour activer l'accès distant, c'est qu'il crée une configuration de session Windows PowerShell Workflow utilise. Si vous avez activé l'accès distant sur un ordinateur avec Windows PowerShell version 2 et ensuite installé la version 3, vous aurez envie de ré-exécuter Enable-PSRemoting pour créer la configuration nécessaire.
Gardez vos workflows assez simple. Exécuter une séquence de commandes et ne fais pas beaucoup de manœuvres de fantaisie. Vous ne devriez avoir aucun problème, et vous pourrez profiter de la communication à distance de Workflow intégré Windows PowerShell , ciblant plusieurs ordinateurs et d'autres fonctionnalités.
Le mois prochain, je vais commencer à obtenir plus compliqué. Je vais regarder les différences profondes entre un workflow et un script Windows PowerShell habituel et commencez à explorer certaines des fonctionnalités de Workflow Windows PowerShell plus intéressantes.
.jpg)
Don Jonesest une récompense de MVP Windows PowerShell vainqueur et au TechNet Magazine. Il a co-écrit quatre livres sur Windows PowerShell version 3, y compris plusieurs titres gratuits sur la création des rapports HTML dans Windows PowerShell et Windows PowerShell Remoting. Trouvez-les tous à PowerShellBooks.com, ou demandez à votre question dans les forums de discussion à PowerShell.org Jones .