Archives de catégorie : C#

Split de listes dans Orchestrator

Orchestrator, c’est un peu le pain quotidien dans mon projet Cloud Privé. Avec le temps, on a appris à se connaitre, s’apprécier, se détester. De temps en temps, je tombe sur un sujet qui semble si simple mais qui devient si compliqué à mettre en œuvre. Généralement, c’est là qu’on aime détester le produit et il ne nous le rend bien. Le split de listes est un de ces cas.

Dans mon cas, je devais accepter une liste de serveurs en paramètre d’entrée pour déclencher des opérations en parallèle, genre déclencher des redémarrages de machines virtuelles. Au début, je pensais que cela allait être développé en cinq minutes. Problème, je me suis vite rendu compte que cela n’allait pas être aussi simple. Il fallait que le résultat de mon split de liste soit stocké dans un tableau. Le problème qui était si simple est devenu bien plus compliqué.

J’ai vite compris que la notion de collection Orchestrator allait être une partie de la solution. Je suis donc partie sur cette piste. En creusant un peu, on comprend que si on veut utiliser les collections, faudra en passer par du C#. Bon, attaquons le problème par la face nord. Ce qui me sauve, c’est qu’on peut faire du C# sans installer Visual Studio, juste avec l’activité .Net Script fournie par Orchestrator. On va commencer par récupérer les paramètres de l’activité « Initialize Data » et réaliser le split dans un tableau.

clip_image001[4]

Juste pour rire, le sujet traité en C#, le tout sans installer Visual Studio. Quand on n’a pas fait de C, C++ ou jamais fait de C#, ça prend un peu de temps.

clip_image002[4]

 

Pour que cela fonctionne, il faut deux choses :

  • Un ou plusieurs namespaces
  • Au moins un Assembly

Dès lors qu’on fait appel au framework .Net, il faut référencer ceux que nous allons utiliser. Ça évite de devoir les référencer à chaque fois dans notre code. Au minimum, on a besoin de la classe System. Dans notre contexte, on va même être plus précis avec la classe System.Collections.Generic. On va en avoir besoin.

clip_image003[4]

 

La notion d’Assembly, c’est juste la version de Framework que nous allons utiliser. Je vais la jouer Old school avec un bon vieux Framework Dot.Net 2.0 pour plateforme X86. Pourquoi ? Ben par ce qu’Orchestrator est aussi une application X86. ca a son importance?

clip_image004[4]

 

Pour préparer la suite, nous allons avoir besoin de configurer notre variable de sortie nommée VMlistO. Ce sera une variable de type « String » pour laquelle on aura activé la case d’option « Collection ».

clip_image005[4]

 

Une fois qu’on exécute cela dans le debugger Orchestrator, on obtient le résultat ci-dessous :

clip_image006[4]

 

Et magie, cela fonctionne puisque chaque serveur est bien considéré comme un élément distinct de la collection que l’activité suivante pourra récupérer pour traitement (redémarrer le serveur en question).

clip_image007[4]

 

C’était rigolo en C# mais ce n’est pas forcément votre langage de prédilection, ni le mien. On a beau dire, j’ai mal. Mal que ce soit aussi compliqué d’obtenir ce résultat aussi simple. Revenons donc à PowerShell. Dans le principe général, rien ne change.

clip_image008[4]

 

En PowerShell, le code est très ressemblant. Y a juste un grand secret. PowerShell ne vous impose pas de déclarer et typer vos variables. Et cette seule ligne va tout changer.

clip_image009[4]

 

Powershell reposant sur le Dot.Net Framework, il n’y a donc plus besoin de déclarer son usage. C’est beaucoup plus simple ainsi.

clip_image010[4]

 

Autre différence, dans la déclaration de variable de sortie, on constate qu’il n’est pas possible de déclarer que notre variable sera une collection. Par contre, c’est notre déclaration de variable qui va se charger de cela.

clip_image011[4]

 

Au final, dans le debugger Orchestrator, j’ai bien une variable VMListOutput.

clip_image012[4]

 

Dans le détail, on obtient bien le même résultat.

clip_image013[4]

 

Conclusion, tout est une histoire de rigueur dans la déclaration des variables. C’est ça qui fait toute la différence. Au passage, je recommande cet excellent article : Automation–Orchestrator Tip/Trick–Run .Net Script Activity + PowerShell + Published Data Arrays.

Après, il reste aussi possible de travailler autrement avec les workflows PowerShell. Un grand merci à Laurent DARDENNE pour ce tutorial qui a éclairé le sujet. Un workflow pour rebooter des serveurs, c’est effectivement une bonne idée, sauf que dans mon cas, c’est une fausse bonne idée, pour les raisons suivantes :

  • Les workflows PowerShell, ça veut dire une instance PowerShell X64. Or avec Orchestrator, on n’a que la version X86 avec Orchestrator. Ne présumez jamais de la version d’Orchestrator.
  • Les workflows permettent de reprendre leur activité au redémarrage du serveur, encore faut-il que ce soit dans le même contexte de sécurité. Dans mon cas, si je dois redémarrer, c’est que ma machine virtuelle vient de joindre le domaine et doit continuer son processus d’installation avec un compte de service

Donc maintenant, plus d’excuse, on déclare ses variables car Orchestrator sait en tenir compte.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)