Le blog technique

Introduction

L’une des grandes nouveautés de Powershell 3.0 est l’intégration des Workflows. Pour généraliser ceux-ci représente une série d’action sur lesquels on va pouvoir effectuer des actions pendant l’exécution. Concrètement, grâce à ceux-ci nous pouvons désormais :
– Paralléliser l’exécution d’actions indépendantes les unes des autres. Cela était déjà faisable via les jobs mais la syntaxe des Workflow est orientée pour les traitements lourds.
– Interrompre puis reprendre des tâches.
– Placer des checkpoints permettant de reprendre des traitements à un endroit donné. Par exemple, si le workflow crashe, nous pouvons reprendre son exécution à partir du checkpoint et non dès le début.

Exemple d’utilisation

On peut imaginer toute sorte d’utilisation :
– Réaliser des pings en parallèle sur des ordinateurs (Traitement sur de multiples postes en même temps).
– Renommer un ordinateur puis reprendre l’exécution du workflow une fois le poste redémarré pour qu’il envoi un mail de confirmation à un administrateur (ou qu’il effectue un traitement).
– La création de machines virtuelles en parallèle.  Puis, on réalise un checkpoint, puisqu’elles n’auront plus à être recréées. Enfin on démarre les machines virtuelles en parallèle et on leurs fait rejoindre le domaine de l’entreprise.
– Créer parallèlement de nombreux ordres de déplacement de boîtes aux lettres dans le cas d’une migration Exchange.
– Créer un workflow contenant d’autres workflows tous exécuté en parallèle (Récupération en même temps, des comptes Active Directory désactivés, expiré, et verrouillé).

Tests et syntaxe

Ici, nous verrons comment implémentés les concepts que l’on a énoncé dans nos scripts. Les différents exemples se veulent simples afin de se focaliser sur la syntaxe.

La syntaxe est similaire au fonction. En effet, seul le mot clé diffère. Il s’agit de "workflow". L’appel au workflow se fait de la même façon que les fonctions.

Tout d’abord, nous allons comparer le temps d’exécution d’un workflow qui exécute 2 pauses d’une seconde en parallèle et une fonction qui réalise la même opération les unes à la suite des autres. Aussi au niveau de la syntaxe, on remarque que ce qui est parallélisé se trouve dans un block de code (entre accolades) précédé du mot clé "parallel".

Le résultat montre bien la différence entre les 2 modes d’exécution, puisque le workflow se réalise en un peu plus d’une seconde contre 2 pour la fonction.

A l’intérieur d’un bloc "parallel", il est possible d’insérer un bloc "sequence" pour être certain que les actions contenu dans celui-ci ne seront pas parallélisées. 

Le résultat obtenu permet de constater que les actions en parallèle s’exécute dans un ordre indéterminable (ici, le résultat de la ligne 9 s’affiche avant celui de la ligne 6 par exemple).

Il est aussi possible de gérer une boucle "ForEach" au travers de multiples exécution simultanées. Il suffit d’ajouter le paramètre "parallel".

Certaines commandes ne peuvent être traitées par le framework Workflow, il faut donc les inscrire dans un bloc "inlinescript". En voici un exemple avec "Get-ChildItem".

Pour qu’une variable déclaré dans un workflow soit accessible dans un bloc "inlinescript", il faut le préfixer par le mot clé "using:". Ci ce n’est pas le cas, alors Powershell est incapable de retrouver la valeur.

Il en est de même si l’on souhaite modifier une valeur déclarer en dehors d’un bloc "parallel". Il faudra que celui-ci soit préfixé du mot "workflow:".

Enfin, le dernier thème abordé, sera celui de la sauvegarde, de la mise en pause et de la reprise d’un workflow.

Tout d’abord, la commande "Checkpoint-Workflow" permet de sauvegarder l’état d’un workflow. Ainsi, si celui-ci s’arrête à cause d’une erreur notamment, il pourra être repris à l’endroit où il s’est arrêté. Cela peut être intéressant pour éviter de ré exécuter des traitements lourds.

"Suspend Workflow" permet quant à elle de mettre en pause un traitement. Cette commande intègre automatiquement un checkpoint implicite afin de reprendre plus tard le workflow où il s’est arrêté.

Lorsqu’un workflow est suspendu via "Suspend-Workflow" ou une autre commande comme "Restart-Computer", il est possible de reprendre un traitement en cours via 2 méthodes. La première est manuelle.Lorsque l’on exécute le code ci-dessous, un job est créé. Grâce à l’un de ces attributs comme le nom ou l’ID , il est possible de redémarrer le workflow.

Pour l’exemple ci-dessous la commande à exécuter serait :

Get-Job -Name Job2 | Resume-Job -Wait

Afin de réaliser la même chose de façon automatisée, on crée un nouveau "job trigger". Celui-ci va nous permettre de gérer de l’évènementiel (lancer une tâche automatiquement à un moment donné).

L’exemple ci-dessous montre la création d’un "job trigger" qui lancera une tâche au démarrage. Cette dernière récupère le Workflow en suspend (ici "Myjob"), et le reprend. Contrairement à l’exemple précédent, on remarque qu’il est possible de définir le nom du job que prendre le workflow. En effet, lorsque l’on invoke un workflow, il existe le paramètre "JobName" qui permet de spécifier ce nom. Ce dernier est un paramètre qui existera pour n’importe quel workflow qui sera créé.