Windows PowerShell : Environnement du workflow Windows PowerShell
Chaque mois cette année, Don Jones présentera une partie d'un didacticiel en 12 parties sur 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
Comme j'ai expliqué le mois dernier, le flux de travail de Windows PowerShell est une nouvelle fonctionnalité de la version 3 de Windows Management Framework. Il est préinstallé sur Windows Server 2012 et Windows 8. Il est également disponible pour Windows 7, Windows Server 2008 et Windows Server 2008 R2. Vous aurez besoin de l'un de ces systèmes d'exploitation pour exécuter un workflow. Vous pouvez également avoir une cible de flux de travail — c'est-à-dire, effectuer des tâches contre — n'importe quelle version de Windows, selon la tâche que vous essayez d'accomplir.
Il y a deux principales conditions préalables à l'utilisation de flux de travail Windows PowerShell , mis à part les exigences de système standard pour Windows PowerShell version 3. Tout d'abord, vous aurez besoin d'utiliser le module de PSWorkflow groupé pour activer des fonctionnalités de flux de travail à l'intérieur de la coquille. Deuxièmement, vous aurez besoin d'avoir Windows PowerShell Remoting activé sur les ordinateurs que vous avez l'intention de cibler avec Windows PowerShell Workflow.
Accès distant n'a pas besoin nécessairement d'être exécuté sur l'ordinateur où vous exécutez le flux de travail, mais quelle que soit la machines que vous prévoyez pour l'inventaire, configurer ou gérer autrement devront avoir accès à distance activé. Windows PowerShell Flux de travail utilise Remoting comme protocole de communication primaire. Il n'y a probablement certains workflows que vous pourriez écrire qui n'auraient pas besoin de communication à distance, mais ceux qui sont peu nombreuses et espacées.
Remoting est un composant largement incompris de Windows PowerShell. Des plusieurs organisations gens de sécurité IT adoptent une approche-non-déployer. Qui est erroné et malheureux. Ces mêmes gens soucieux de la sécurité n'ont aucun problème, ce qui permet à un grand nombre d'autre personnel de gestion des protocoles de communication comme le protocole RDP (Remote Desktop), appels de procédure distante (RPC) et HTTP.
Remoting est la voie à suivre pour les communications de gestion dans un environnement Windows. Microsoft va bientôt commencer à consolider ces anciens protocoles d'accès distant. Accès distant utilise HTTP et HTTPS, est hautement configurable et administrable, et vous pouvez centralement il verrouiller l'avec un objet de stratégie de groupe (GPO). Il est aussi généralement plus sûr, plus contrôlable et plus contrôlable que ces anciens protocoles. Pour une discussion plus complète des implications de sécurité d'accès distant et son architecture, considérer le téléchargement de l'e-livre libre, «Secrets de PowerShell Remoting. »
À l'intérieur d'un flux de travail
Le plus grand défi que vous aurez lorsque vous approchez de Workflow Windows PowerShell est de se rappeler qu'il ressemble à un script Windows PowerShell (plus précisément, une fonction), mais ce n'est pas. Le "langageWindows PowerShell vous écrivez est traduit en un langage externe (XAML). Puis elle est exécutée par une autre-technologieWindows PowerShell .
En conséquence, il y a quelques règles différentes. Certains de ceux qui sont purement syntaxiques. De manière générale, vous aurez besoin d'utiliser des noms d'applet de commande complète pour les applets de commande Exécuter. En outre, les paramètres positionnels et des noms de paramètre tronquée ne sont pas autorisés. Vous devez utiliser des noms de paramètre complet.
Ce qui peut être plus déroutant est l'environnement global au sein d'un workflow. Tout l'intérêt d'un flux de travail est que vous pouvez interrompre et reprendre le flux de travail délibérément ou de le faire en réaction à quelque chose va mal dans votre environnement (par exemple, une perte de puissance).
Cela signifie que chaque commande dans un flux de travail doit essentiellement autonome. Il doit avoir aucune conscience de ce qu'ont fait les autres commandes et aucun moyen natif de données persistantes entre les commandes. Cela signifie également que vous ne pouvez pas définir une variable destinée à contenir la sortie d'une commande et ensuite passer cette variable comme entrée pour une autre commande. Il ne fonctionne tout simplement pas. En outre, vous ne peut pas charger les modules contenant des commandes supplémentaires. Il n'y a aucun environnement persistant charger le module.
Le bloc spécial InlineScript {} qui peut figurer dans un flux de travail maintenant devient votre meilleur ami. Chaque InlineScript fonctionne essentiellement comme une seule unité. Windows Workflow Foundation (WWF) tourne un exemplaire de Windows PowerShell, confitures dans la InlineScript ensemble, et il s'exécute. Le contenu d'un InlineScript se comporte comme un script Windows PowerShell traditionnel.
Il y a aussi un InlineScript implicite. WWF ne peut pas exécuter commandes Windows PowerShell en dehors d'un InlineScript. Lorsque vous utilisez une applet de commande Windows PowerShell dans votre workflow, Windows PowerShell vérifie si un natif WWF équivalent est disponible et raconte la WWF à courir qu'à la place.
L'équipe Windows PowerShell a écrit équivalents WWF pour beaucoup de commandes Windows PowerShell native, mais lorsque vous essayez d'utiliser une cmdlet qui n'est pas une version native de la WWF, Windows PowerShell encapsule implicitement votre commande dans un bloc InlineScript. Cela provoque la WWF lancer Windows PowerShell, exécuter votre commande, puis fermez cette instance de Windows PowerShell.
Ce manque de persistance entre les commandes, c'est ce qui aide Windows PowerShell Workflow rendre vos scripts peuvent être repris. Il s'agit d'une grande partie de Pourquoi Workflow Windows PowerShell peut paralléliser les commandes dans un script. Il les transforme en machines automatisées multithread. Toutefois, le manque de persistance est une dérogation majeure à des scripts Windows PowerShell comment normaux et fonctions de travail. Il faut beaucoup de planification supplémentaires pour faire un script de fonctionner correctement.
Il ne sera pas rare de voir des workflows qui consistent en un tas de blocs InlineScript. Ni qu'il sera rare de voir les flux de travail qui n'est rien de plus qu'un seul bloc InlineScript long.
Ces flux de travail auront des capacités de parallélisation ou reprendre limitées (ou inexistantes). Un InlineScript est une seule unité de travail. Simplement, vous pouvez choisir d'exécuter ces scripts comme des fonctions normales, à l'aide d'accès distant plutôt que sur des workflows. Vous serais obtenir très peu des avantages réels des flux de travail de Windows PowerShell quand même.
Gardez ces pratique
Une chose que manque nettement Windows PowerShell Workflow est un moyen de persistance des données d'un flux de travail entre les commandes. Cela rendrait utile dans un large éventail de circonstances. Si un flux de travail ont été interrompue et a repris, commandes pourraient facilement recréer les informations d'État telles que les adresses IP, les noms d'ordinateurs, les noms d'utilisateur ou tout autre chose et continue à s'exécuter.
Compte tenu de cette lacune native, c'est quelque chose que vous voudrez probablement créer pour vous-même. Mettre en place une instance de SQL Server (même une instance de l'Express gratuite) et créer des tables de base de données dans laquelle vos flux de travail peut enregistrer des données. Un flux de travail aura besoin des moyens d'identifier de manière univoque lui-même, telles que le nom de flux de travail et le nom de l'ordinateur, que chaque instance de workflow est le ciblage.
Votre flux de travail peut être constituée alors d'un certain nombre de blocs InlineScript discrets. Chacun d'eux va lire l'état actuel de la base de données, effectuer certaines tâches et, si nécessaire, mettre à jour la base de données avec de nouvelles informations. C'est une honte que fonctionnalités de Workflow Windows PowerShell ne peut pas aider à automatiser ce processus. Peut-être un "flux de travail$: variable « architecture qui utilise des fichiers XML ou SQL Server sous le capot pourrait aider, mais c'est quelque chose pour une future version.
La bonne nouvelle est qu'il est assez facile de « rouler » persistance à l'aide du SQL Server. SQL Server est préférable aux fichiers XML car il est plus évolutif, vous pouvez y accéder plus facilement à partir de plusieurs emplacements réseau et il supporte mieux accès simultané de plusieurs instances à la fois.
La classe Microsoft .NET Framework System.Data.Sql.SqlClient est facile à utiliser. Il y a des exemples dans mon «Apprendre PowerShell taillanderie en un mois de repas"e-book. En fait, mon co-auteur et j'ai créé un module entier, vous pouvez réutiliser et Télécharger gratuitement dans le cadre des scripts d'exemple du livre.
Avec ces préliminaires de la route, nous sommes prêts à commencer à examiner ce qui ressemble à un workflow de base. Qui fera l'objet de la chronique du mois prochain.
.jpg)
Don Jones est 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 à Jones PowerShell.org.