En complément à l’article sur les boucles, voici un appendice présentant une manière de relancer une action dans Stambia tirant parti de cette méthode.

Note : Le process présenté dans cet article est fourni dans l’archive zip disponible ci-dessous et importable dans Stambia.

Le process présenté ici est un process générique permettant de relancer plusieurs fois une action en utilisant une boucle. On peut ainsi très facilement l’utiliser pour relancer une copie de fichier, un envoi FTP ou tout autre action qui aurait échoué en ne modifiant que le nom du paramètre que l’on va tester et les messages à afficher.Il doit être mis en place de la façon suivante :

Il doit être mis en place de la façon suivante :

On a une étape de copie. En cas d’erreur, on souhaite que cette dernière soit lancée jusqu’à 3 fois au maximum en attendant à chaque fois 5000 ms.

On spécifie le nombre d’exécutions maximal « nbIteration », le temps d’attente entre chaque exécution « wait » et le nom du paramètre « paramName » qui va être renvoyé par le process RETRY ici nbExecutionError.

Enfin, on teste que la valeur du paramètre ainsi renvoyé est inférieure à notre nombre d’itération max via la condition d’exécution « ${./nbExecutionError}$ < ${./nbIterationError}$ ».

Les paramètres messageError et messageLastError servent si l’on souhaite déclencher des actions à chaque boucle (par exemple envoyer un mail, loguer une erreur …). Les actions peuvent être différentes si l’on est sur la dernière itération ou pas (voir ci-dessous).

Le sous-process « RETRY » se présente sous la forme suivante :

Dans le script, on compte simplement le nombre d’exécution du script auquel on ajoute 1 (car lorsque le script s’exécute pour la première fois sa valeur ${../CORE_NB_EXECUTIONS}$ vaut encore 0) :

nbExec = parseInt("${../CORE_NB_EXECUTIONS}$") + 1;
__ctx__.publishVariable("../../" + "${../paramName}$", nbExec);
__ctx__.publishVariable("../nbExecution", nbExec);

Le résultat du script est publié dans un paramètre nommé avec la valeur de « paramName ». Cela permet d’avoir plusieurs process RETRY dans le même process principal afin de pouvoir mettre un process de relance pour chaque action pour laquelle on veut des tentatives de relance.

Une fois que l’on a déterminé le nombre d’exécutions en cours, on fait une action en conséquence :

• Ce n’est pas la dernière itération : On attend le temps demandé et on logue « l’erreur »
• C’est la dernière itération : On logue « l’erreur » de type dernière itération

Ce process est très pratique pour gérer les nombreux problèmes pouvant survenir sur une durée très courte (fichier non accessible au moment de la copie, FTP non accessible quelques secondes …). Il peut être réutilisé à loisir en n’ayant qu’à modifier 3 paramètres.