Discussion :

[michelS]

Bonjour,

J'ai plusieurs context, DEV, TEST, PROD,... chacun avec ses variables.
Existe-il un moyen pour connaitre sur quel type de context j'ai lancé le job (DEV...)

Par avance merci.

A +

[emenuet]

Bonjour,

Il existe une variable contextStr, que tu peux utiliser.

[michelS]

Merci, je ne l'avais pas vu celle là.

A +

[michelS]

Bonjour,

pour info, en 5.4.1 à partir du studio, contextStr renvoi toujours TEST et ce ne serais pas un bug !!

[NicolasTT]

Bonjour Michel,

ton message m'a inquiété. J'ai vérifié, contextStr me retourne bien DEV, REC ou PROD.

Je suis en TOS 5.4.1.

[michelS]

Alors là, tu m' intéresses. Dans mes tests, j'ai un job qui lance deux sous jobs. Dans ces deux sous jobs, je fais un sendmail avec dans le texte "Contexte: "+contextStr.
Que je fasse exécuter en TEST ou PROD, j'ai toujours TEST. Si je rajoute une information faisant partie des contextes --> context.HOST, j'ai bien la valeur correspondant au contexte mais contextStr reste TEST.
J'ai envoyé l'exemple au support qui m'a confirmé que cela était normal ce que je trouvait étrange.
J'avais bien coché l'option d'appliquer les contextes aux sous jobs.
Pour pallier au problème, unique solution, changer dans l'onglet composant du sous job si Test ou Prod.

A +

[NicolasTT]

Ce serait le passage dans le job fils (tRunJob) qui poserait souci.

J'ai fait le test d'un job père qui appelle mon job affichant la valeur de contextStr, et là, le résultat n'est pas celui que j'attendais. J'ai le même comportement que toi.

Je lance le job père avec l'environnement PROD et le job fils m'affiche DEV (l'environnement par défaut de mon job fils).

Merci de ton message.

[michelS]

Et, ce n'est pas un bug.
Chose rassurante si en plus de mettre le contextStr, tu ajoutes une variable existante, celle-ci correspond bien à la bonne.

J'ai enlevé le résolu car, le problème n'est plus résolu aujourd'hui