Comment se servir des boucles dans Stambia pour répondre à des besoins spécifiques ? C’est ce que nous allons voir à travers quelques exemples d’utilisation.

Note : Pour chaque processus présenté, le projet est fourni dans l’archive zip disponible ci-dessous et importable dans Stambia. Le nom des différents process est indiqué sous chaque capture d’écran.

Mise en place d’une boucle simple

La mise en place d’une boucle via Stambia, est très simple. Par exemple :

On a ici 2 boucles indépendantes, la première commençant sur l’action « Start » exécutée une seule fois et la seconde commençant par « Start Sleep ». Ces deux boucles sont infinies.

Afin d’ajouter une condition de fin si nécessaire à une boucle, il est par exemple possible de mettre un nombre d’itération maximale. Pour cela on va vérifier le nombre d’exécution de l’action Sleep via  « ${Sleep/CORE_NB_EXECUTIONS}$ » :

Tant que cette valeur est inférieure ou égale à 3, on continuer à boucler. Au-delà, on sort de la boucle.

Les boucles peuvent avoir plusieurs utilités telles que :

• L’attente d’un code retour
• L’attente d’un changement de valeur dans une table
• L’attente de fichier
• La mise en place d’un timeout
• …

Cas d’utilisation 1 : Désactiver l’exécution d’une action en fonction de la durée de l’action précédente

Parfois, il peut arriver que l’on souhaite empêcher le déclenchement d’une action finale si l’action initiale est trop longue. Les boucles peuvent permettre de gérer ces cas de figure. Pourquoi une boucle et pas une simple étape Sleep avec un lien inhibiteur ? Tout simplement car la boucle permet de passer à la suite bien plus rapidement si l’action initiale est terminée dans les temps. En effet, on aura 1 seule itération d’attente contre toute la durée du Sleep sinon. Sachant que :

1 itération (en ms) = durée totale (en ms)/nombre itérations. Si on veut de la réactivité, il faudra donc privilégier un nombre d’itération assez important.

Figure 3 : Boucle avec inhibiteur.
A gauche, le process dure moins longtemps que la boucle.
A droite, il dure plus longtemps.
(Process Loop_Iteration_Inhibitory)

On voit que dans le cas où l’étape « Process » se termine rapidement, on n’entre pas du tout dans la boucle, ou juste pour le nombre minimum d’itération. Dès que le Process est terminé, on ne recommence pas d’itération de la boucle. L’étape « Process_Final » est bien lancée tout de suite après la fin d’étape « Process ».

Dans le cas où l’étape « Process » dure plus longtemps que la boucle, l’étape « Process_Final n’est pas lancée. Il faut tout de même attendre la fin d’étape « Process ». Il serait possible de faire volontairement tomber en erreur le processus Stambia afin de stopper l’exécution (ce qui n’est pas le cas ici).

Dans le cas où l’étape « Process » dure plus longtemps que la boucle, l’étape « Process_Final » n’est pas lancée. Il faut tout de même attendre la fin d’étape « Process ». Il serait aussi possible de faire volontairement tomber en erreur le processus Stambia afin de stopper l’exécution (ce qui n’est pas le cas ici).

Cas d’utilisation 2 : Détecter des fichiers générés par un outil externe

Nous allons ici voir un cas d’utilisation spécifique. Lorsque des fichiers sont générés par un outil externe suite à une action effectuée via Stambia, il est parfois nécessaire d’attendre qu’un nombre précis de fichiers soient disponibles avant de déclencher la suite du processus (un envoi de mail par exemple).

Dans le processus présenté ci-dessous, on attend :

• La génération de 6 fichiers « .pdf » dans le répertoire « C:\XXX\ »
• Ces fichiers doivent avoir une date de création supérieure au paramètre dateStart. En effet, il est possible d’avoir déjà des fichiers dans le répertoire à scanner mais déjà traitées lors d’exécutions précédentes.
• On autorise 60 itérations avec un temps d’attente de 5000 ms entre chaque itération.
• Une fois que l’on a détecté les 6 fichiers, on les envoie par mail.
• Si au bout de toutes les itérations prévues on n’a pas détecté 6 fichiers, on envoie le nombre de fichiers disponibles en spécifiant que tous ne sont pas présents.

Dans un premier temps, à l’aide d’une étape fileWait, on scanne le répertoire dans lequel on s’attend à recevoir les fichiers. Ensuite, via une requête SQL sur la base de logs Stambia, on compte le nombre de fichiers détectés. Si on a :

• Le nombre de fichiers attendu, on prépare l’envoie des fichiers en concaténant leur nom afin de les ajouter au mail indiquant que les fichiers sont disponibles en pièce jointe.
• Si on n’a pas le bon nombre de fichiers, et que l’on n’a pas atteint le nombre d’itérations maximum, on attend le temps indiqué et on rejoue l’étape de détection des fichiers.
• Si on n’a pas le bon nombre de fichiers et que l’on a atteint le nombre d’itérations maximum, on prépare l’envoi des fichiers incomplets en concaténant leur nom afin de les ajouter au mail indiquant que les fichiers sont partiellement disponibles en pièce jointe.

On voit qu’il est finalement très simple de traiter cette problématique via un processus Stambia. Il serait aussi possible de mettre un troisième type de mail si on ne détecte aucun fichier.