Question Problème de cohérence avec la portée des paramètres Stambia

Bonjour,
Je rencontre une difficulté avec la portée des variables dans les processus Stambia et qui rend incohérent nos développements.

Pour l'exemple, j'utilise un processus TEST qui prend 2 paramètres en entrée p1 et p2 auxquels j'attribue dans le Designer la valeur par défaut : "default".
Dans le processus, j'ai deux variables PARAMETRE1 et PARAMETRE2 auxquelles j'assigne respectivement les valeurs de p1 et p2.
Puis j'insère dans une table la valeur des deux variables.

J'utilise trois syntaxes différentes pour l''assignation des deux variables :
1) ${../p1}$ et ${../p2}$
2) ${~/p1}$ et ${~/p2}$
3) ${/p1}$ et ${/p2}$

J'appelle le processus de deux manières différentes :
1) depuis le DESIGNER
2) depuis une ligne de commande: ./startdelivery.sh -name TEST -var p1 param1 -var p2 param2

Comme on peut le voir, lorsque j'exécute en ligne de commande, j'attribue aux 2 paramètres d'entrée les valeurs param1 et param2.

J'obtiens ceci :

- Pour la syntaxe 1 :
* par le designer : PARAMETRE1 = default | PARAMETRE2 = default
* par ligne de cde: PARAMETRE1 = default | PARAMETRE2 = default

- Pour la syntaxe 2 :
* par le designer : PARAMETRE1 = default | PARAMETRE2 = default
* par ligne de cde: PARAMETRE1 = default | PARAMETRE2 = default

- Pour la syntaxe 3 :
* par le designer : PARAMETRE1 = ${/p1}$ | PARAMETRE2 = ${/p2}$
* par ligne de cde: PARAMETRE1 = param1 | PARAMETRE2 = param2

Donc, on voit que par ligne de commande, les paramètres entrants ne sont jamais pris en compte pour les 2 premières syntaxes. Or, en production, tous nos processus sont lancés par ligne de commande.
Cependant, avec la 3e syntaxe, dans le designer, les paramètres par défaut ne sont pas pris en compte, ce qui est dommageable pour les tests (parce qu'il faut toujours veiller à changer la syntaxe lors de la publication pour mise en production). Mais plus problématique, les processus en web services lorsqu'il sont appelés via la technologie C# fonctionne comme le designer. C'est-à-dire que pour mon exemple TEST, lorsque je le publie en web services, lorsque je l'appelle via la syntaxe 3, les variables se retrouve avec les valeurs ${/p1}$ et ${/p2} ; il ne retrouve donc pas les paramètres d'entrée.

En regardant dans Analytics, je vois qu'il y a 2 niveaux : le niveau SESSION et le niveau ACTION et je comprends donc que les 2 première syntaxes renvoient au niveau ACTION et la 3e au niveau SESSION. Donc si je fais les bonnes conclusion, il n'y a pas de niveau SESSION lors d'un appel via le DESIGNER ou en WEB SERVICES d'où le fait qu'il ne retrouve pas les valeurs des paramètres d'entrée.

Bref, ceci me pose un problème car je suis obligé de publier deux fois le même processus avec deux syntaxes différentes selon que ce soit en web service ou non.

Y a-t-il une solution à ce problème afin de n'avoir qu'une seule syntaxe qui fonctionne sur tous les cas (Ligne de commande, Designer, Web services) ?.

En pièce jointe l'image du processus de TEST.

Merci par avance.

Bonjour Thomas,

Merci bien pour cette réponse. C'est parfait pour moi.

Cordialement,
Rachid

Bonjour,

Je relance le sujet car la solution donnée ne fonctionne plus.

Pourtant je me souviens que la première fois que je l'ai essayé ça a fonctionné, mais maintenant non.

Toujours avec le même processus TEST, j'exécute avec ces lignes de commande :

# Déclaration des variables globales.
. /var/opt/AUTOMIC/DUAS/EURDIF_eurodif-rc-01/mgr/U_ANTE_UPROC

# Lancement d’un delivery
export STAMBIA_HOME=$STAMBIA_HOME5
export STAMBIA_PROPERTIES_LOCATION=$STAMBIA_HOME/properties
cd $STAMBIA_HOME
./startdelivery.sh -name TEST -var ~/p1 param1 -var ~/p2 param2

Pourtant, lorsque je regardes les variables dans Stambia Analytics, p1 et p2 apparaissent avec leur valeur par défaut pour le process TEST. (cf capture d'écran).
J'ai testé en enlevant dans le designer les paramètres p1 et p2 comme paramètre de process en entrée et dans ce cas-là, p1 et p2 n'existent pas (il n'apparaissent pas dans les variables du processus TEST dans Analytics).

Avez-vous une piste sur la raison de ce problème ?

Cdt,
Rachid

Je ne pense pas qu'il y ait un LogLevel sur le processus. Je regarde ça et ouvre un ticket le cas échéant.
Merci pour ce retour.

Cdt,
Rachid