Automic Workload Automation

Bonjour,

Si une tâche donnée d'un workflow est en erreur, j'ai besoin que celle-ci soit relancée n fois après un délai de 3 min.
Durant ces relances, la tâche ne doit pas être considérée comme étant en erreur par le workflow.
Si après ces n tentatives, la tâche est encore en erreur, alors il faut que le workflow la considère comme une erreur (gestion du statut dans les attributs du JOBP).

Je pense que cela doit se paramétrer dans la post-condition de la tâche, mais je ne trouve pas comment paramétrer pour répondre à mon besoin.

Merci d'avance pour votre aide

Bonjour Samuel,

Il est en effet possible de redémarrer une tâche via les post-conditions du workflow avec la condition STATUS et l'action RESTART TASK.



Cependant dans ce cas précis c'est un peu différent car il y a une notion de durée et de nombre de redémarrages.
Il faut donc plutôt recourir à du script dans l'onglet post-traitement de la tâche concernée.

On peut utiliser par exemple

• &$RESTART_COUNT#pour évaluer le nombre de redémarrages de la tâche
• &$STATUS#pour déterminer le statut de la tâche
• :WAITpour définir le temps d'attente
• :RESTART_UC_OBJECT pour redémarrer la tâche

Cordialement,
Antoine

Bonjour Antoine,

Merci pour ton retour.

&$STATUS# n'est pas compris (je suis en V11.2.1)
La ligne dans le post-trt::SET &STAT#=&$STATUS#
l'erreur:  'U01001308 Variable '$STATUS#' has not yet been defined.'.
Est ce une fonction disponible depuis la version 11.2.2

Pour précision &$RUNID# est bien interprété quant à lui (:SET &RUNID#=&$RUNID#).

 

Pour la relance, cela fonctionne ... trop bien, c'est une boucle infinie:
&$RESTART_COUNT# semble avoir toujours la valeur 0
Donc mon test qui vérifie si cette variable est < à ma valeur max de relance ne peut être résolu.

Est ce que mon utilisation de&$RESTART_COUNT#  est bonne ?

Traitement (le script exitN.sh sort en exit correspondant au paramètre donné - ici exit 5) :
echo test erreur
/appli/automic/test/exitN.sh 5
CR=$?
echo "CR=$CR"
!Export du CR pour le post-traitement
:REGISTER_VARIABLE "CR#", $CR

Post-Traitement:
!Valorisation du compteur de relance
:SET &RESTART#=&$RESTART_COUNT#
:PRINT "compteur de relance=&RESTART#"
!Prise en compte du Code retour
:PRINT "CR=&CR#"
!Nom du job courant
:SET &JOB_NAME#=&$NAME#
:PRINT "JOB_NAME=&JOB_NAME#"
!RUNID du lancement courant
:SET &ID_JOB#=SYS_ACT_ME_NR()
:PRINT "RUNID=&ID_JOB#"
!Nombre de relance max
:SET &MAX#=1
:PRINT "Nombre max de relance autorisée=&MAX#"

!Si job en erreur, vérification du nombre de relance
:IF &CR# <> "0"
Relance <= au nombre de relance max autorisé -> re-soumission du job
:  IF &RESTART# <= &MAX#
:    PRINT "Relance &RESTART# initiée"
:    WAIT 5
:    SET &RET#=RESTART_UC_OBJECT(&JOB_NAME#,&ID_JOB#)
!Relance max atteinte -> Erreur
:  ELSE   
:    PRINT "Nombre de relance max atteinte, sortie erreur"
:    EXIT &CR#
:  ENDIF
:ENDIF

Contenu du log du Post-traitement
2016-10-04 16:24:45 - U00020206 La variable '&CR#' a été enregistrée avec la valeur '5'.
2016-10-04 16:24:45 - U00020408 compteur de relance=0000000000000000
2016-10-04 16:24:45 - U00020408 CR=5
2016-10-04 16:24:45 - U00020408 JOB_NAME=TEST.JOBS.RESOUMETTRE_ERREUR
2016-10-04 16:24:45 - U00020408 RUNID=0005102724
2016-10-04 16:24:45 - U00020408 Nombre max de relance autorisée=0000000000000001
2016-10-04 16:24:45 - U00020408 Relance 0000000000000000 initiée
2016-10-04 16:24:51 - U00007000 'TEST.JOBS.RESOUMETTRE_ERREUR' activé avec le RunID '0005102726'.

 

 

 

Au temps pour moi, certaines variables ne peuvent être utilisées ailleurs que dans les postconditions du workflow. &$STATUS# en fait partie.

Autre difficulté rencontrée : le redémarrage fait référence au RunID de la première exécution, et hérite donc de ses variables. C'est la raison pour laquelle tu obtiens une boucle infinie, car ton compteur de redémarrages est réinitialisé à chaque exécution.
Pour contourner ce problème je te conseille de stocker la valeur attribuée à ce compteur dans un objet variable statique séparé. Ensuite tu changes et récupères les valeurs grâce à :PUT_VAR et GET_VAR.

Voici un exemple avec un Job Unix qui termine délibérément en erreur.

Onglet traitement

!On vérifie si la tâche a été redémarrée
:IF &$RESTARTED# = 'N'
!Si c'est la première exécution on instancie le compteur avec la valeur 0
:PUT_VAR VARA.RESTART,'RESTARTS',0
:ENDIF
exit 1

Onglet post_traitement

!Nombre maximum de redémarrages
:SET &MAX# = 3

!On récupère le code retour
:SET  &RETURNCODE# = GET_UC_OBJECT_STATUS( ,,"RETCODE")

!Si l'exécution s'est terminée en erreur
:IF &RETURNCODE# > '0'

!On vérifie le nombre de redémarrages
:  SET &RESTARTS# = GET_VAR(VARA.RESTART,'RESTARTS')

!Si ce nombre est inférieur au maximum
:  IF &RESTARTS# <= &MAX#
:    WAIT 10
!On relance
:    SET &ACT# = RESTART_UC_OBJECT(&$NAME#,&$RUNID#)

!Puis on incrémente d'1 le compteur de redémarrages
:    SET &RESTARTS# = &RESTARTS# +1
!Et on stocke la valeur dans l'objet variable
:    PUT_VAR VARA.RESTART,'RESTARTS',&RESTARTS#
:  ELSE
:    PRINT Le nombre maximum de redémarrages a été atteint. Le job ne sera plus redémarré.
!On change le code retour = 0 pour que le job se termine sans erreur
:    MODIFY_STATE RETCODE=0
:  ENDIF
:ENDIF



L'objet VARA.RESTARTS ressemble à ça :

https://us.v-cdn.net/5019921/uploads/editor/ms/5gckis14oj46.png" width="538">

Et voici les statistiques montrant que le job s'est terminé sans erreur au bout du 5e lancement (original + 3 relances + dernier en statut OK lorsque le max a été atteint):

https://us.v-cdn.net/5019921/uploads/editor/l1/olw8gwgpk6pc.png" width="614">

Voilà, j'espère que ça répond à ton besoin...

Cordialement,
Antoine

Merci Antoine,

J'avais pensé à cette solution de déporter le compteur dans une variable externe, mais cela me pose un souci dans mon contexte.

Le but, à l'origine, est que nous créons un Job SQL qui vérifie la dispo de la BDD avant de lancer les job applicatifs. Si le job SQL est en erreur, on veut le resoumettre quelques minutes après pour enlever le cas d'un problème réseau, un A/R en cours, ... . Si après ces n relances, on est toujours en erreur, alors on déclare un incident.
Mais ce job est générique et va servir dans x JOBP.

En prenant cette variable externe, il faut avoir une ligne par JOBP.
Ainsi, le job à relancer récupère le nom de son JOBP et travaille avec la ligne correspondante.

Si cela reste la seule solution, nous utiliserons cette méthode.

En effet c'est la seule solution à mon avis, car les variables de script ne permettent pas de répondre au besoin dans ce type de cas...

Tu peux éventuellement créer une variable statique de façon dynamique avec CREATE_OBJECT, mais ça demande encore un peu plus de codage.

En fouillant le forum anglais, il y a une solution beaucoup plus simple et qui reprend ce qu'Antoine proposait au début ... mais avec une option supplémentaire, cela répond à mon besoin

 

https://community.automic.com/discussion/4930/how-to-execute-a-job-more-than-the-once-post-conditions-else-allows#latest

 

La 1ere réponse deJesse Getzie avec la copie d'écran est explicite sur le paramétrage à apporter.

Merci Samuel!! Comme quoi les solutions les plus simples sont les meilleures...