Partager via

Windows PowerShell : Scripts PowerShell contre workflows PowerShell

  • Article

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

Workflows apparence beaucoup à un script ou une fonction Windows PowerShell , mais ils ne sont pas. Leur similitude n'a fleur de peau, et il ne peut même pas être tout au long de la peau.

Il faut se rappeler que Windows PowerShell doit traduire les workflows dans une technologie totalement distincte — Windows Workflow Foundation (WF). Cela signifie que vous ne pouvez faire des choses que vous pouvez dupliquer dans WF. Votre code s'exécutera dans un tout autre genre d'environnement qui a ses propres règles et restrictions. En fait, les différences entre un workflow et un script « normal » peuvent être importantes.

Un espace d'exploitation par rapport à nombreux

Dans une écriture standard, tout dans le script s'exécute dans une instance d'exécution unique, avec une hiérarchie de portée unique. Une instance d'exécution équivaut grosso modo à un processus de Windows PowerShell . Si vous considérez qu'une fenêtre de console Windows PowerShell , qui est une instance d'exécution unique. Cela signifie que tout est pareil, cohérente et persistant au sein de cette instance d'exécution.

Variables, les commandes, les disques et tout le reste tous commencent à aller. Ils restent les mêmes, à moins que vous les modifiiez. Au sein de cette instance d'exécution, toutes les modifications vous faites « coller » pour la durée de ce processus.

Dans un flux de travail, chaque activité — chaque commandement, de bloc de script inline et ainsi de suite — peut avoir son propre espace d'exploitation. Cela signifie que si vous apportez une modification dans l'un, il ne serait pas visible dans tous les autres. Définissant une variable dans une partie de votre flux de travail peut ne faire aucun changement dans une autre partie du flux de travail, sauf si vous prenez des mesures spéciales pour assurer, dans le cas contraire.

Comme vous l'avez vu dans article du mois dernier, si vous définissez une variable au niveau supérieur du flux de travail, il existe tout au long du flux de travail (le système prend des mesures pour s'assurer que cela est vrai). Si une commande dans le flux de travail crée une variable, cette variable ne sera pas disponible pour le reste du flux de travail.

Cela signifie l'utilisation de module est également différente. Importer un module à un moment donné n'est pas nécessairement faire commandes disponibles à un moment ultérieur. Vous devrez prendre beaucoup plus de soin, car un seul flux de travail peut couvrir essentiellement plusieurs étendues indépendants.

Différences syntaxiques

Il y a un certain nombre de différences de syntaxe dans un flux de travail, que certains dont j'ai souligné dans les articles précédents de cette série :

  • Vous ne pouvez pas utiliser les paramètres positionnels. Vous devez épeler chaque paramètre de la commande. Si vous êtes habitué à Dir C:\Windows, vous aurez besoin d'apprendre – Path de Get-ChildItem C:\Windows plutôt. Vous pouvez toujours utiliser des alias (par exemple Dir) ou tronquée des noms de paramètres (par exemple –Comput pour – ComputerName).
  • Flux de travail peut avoir des paramètres, mais ils peuvent inclure uniquement des lettres, chiffres, le caractère de soulignement et le trait d'Union dans leurs noms. Les règles normales de script Windows PowerShell qui diffère.
  • Vous ne pouvez pas importer un module dans la session de flux de travail. En fait, les commandes ne peut pas vraiment changer la session en cours et aient un effet sur les commandes suivantes. Si un flux de travail doit utiliser un module, vous devez utiliser le paramètre de l'activité –PSRequiredModules.
  • Pour les commandes qui ont des implémentations de l'activité de flux de travail et d'activité InlineScript, vous obtenez un groupe de paramètres de la commande supplémentaire, y compris le paramètre –PSRequiredModules a été mentionné précédemment.
  • Vous ne pouvez pas exécuter des méthodes d'objets dans un flux de travail, sauf si vous le faites dans un bloc de script inline. L'objet doit être apportée dans le bloc de script inline afin que la méthode fonctionne.
  • Vous ne pouvez pas les scripts de point source.
  • Vous ne pouvez pas utiliser l'opérateur d'invocation « & ».
  • Constructions de l'interrupteur doivent inclure le paramètre –CaseSensitive. L'équivalent de flux de travail de la construction de commutateur est sensible à la casse en mode natif. Instructions Switch doivent utiliser des constantes. Vous ne pouvez pas utiliser d'opérateurs de comparaison, les expressions régulières, les références de fichier ou les blocs de script. Fondamentalement, essayez d'éviter des constructions de l'interrupteur.
  • Pause et continuer des déclarations ne sont pas autorisées.
  • Seulement PSDrives ajouté par les fournisseurs de base de Windows PowerShell — dossier système, Registre, magasin de certificats, environnement, fonction, variable et WS-Management — sont valides. Pour utiliser un PSDrive créé par un module, exécutez l'activité avec un paramètre de –PSRequiredModules et spécifiez le nom du module.

Oui, c'est beaucoup de différences. Si vous êtes un programmeur de Windows PowerShell prudent, vous ne manquerez contre moins d'entre eux, comme nommer vos paramètres. Vous rencontrerez toujours des différences, que vous avez oublié jusqu'à ce que vous devenez vraiment familier avec l'écriture de flux de travail.

Bonus

Windows PowerShell Flux de travail n'est pas toutes les différences de mauvaises nouvelles, en fait, il te donne une tonne de fonctionnalités gratuitement.  Chaque flux de travail gagne des paramètres intégrés, y compris :

  • – AsJob exécute le flux de travail comme une tâche en arrière-plan. Vous pouvez lui donner un nom de travail à l'aide de –JobName.
  • –PSComputerName s'exécute le flux de travail sur l'ordinateur désigné ou ordinateurs, utilisez les fonctionnalités distantes Windows PowerShell .
  • –PSCredential et divers paramètres connexes vous permettent de spécifier des informations d'authentification alternatives.
  • –PSPort et autres paramètres liés à la connexion vous permettent de spécifier les détails de la connectivité de rechange pour le composant distante de flux de travail.

Remarqué un certain nombre de ces paramètres commencent par –PS ? Cela s'appelle un espace de noms. Vous devez éviter la création de vos propres paramètres qui commencent également par –PS. Si une version future de Windows PowerShell ajoute de nouveaux paramètres, ils vont probablement commencer avec –PS. Si vous évitez généralement le préfixe, vous éviterez les collisions avec vos propres noms de paramètre.

Pas pire, pas mieux, mais différent

Le résultat pratique ici, c'est que le flux de travail ne sont pas scripts Windows PowerShell . Ils sont différents. Ils ont des différences qui peuvent rendre votre vie plus facile. D'autres différences peuvent exiger un peu plus de travail de votre part. Connaître les différences peut vous aider plus rapidement commencer à écrire le flux de travail efficace.

Don Jones

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.

Contenus associés