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.

Le comportement que vous décrivez semble normal, il est peut être nécessaire de clarifier l'usage des syntaxes de la ligne de commande et l'usage des syntaxes de références aux paramètres.

Usage dans un process :
- Syntaxe 1 ${../p1}$ fait référence au paramètre de process nommé p1, situé sur l'élément parent de l'élément en cours (syntaxe relative)
- Syntaxe 2 ${~/p1}$ fait référence au paramètre de process nommé p1, situé à la racine du process.
- Syntaxe 3 ${/p1}$ fait référence à une Variable de session nommée p1 (syntaxe principalement employée pour accéder à CORE_SESSION_ID, etc.)

En ligne de commande, il convient de spécifier le chemin du paramètre que vous passez :
startdelivery.sh -name TEST -var ~/p1 param1 -var ~/p2 param2
La syntaxe que vous avez indiqué dans votre message a peut être créé des variables de session, ce qui explique pourquoi ${/p1}$ a fonctionné.

Après avoir regardé la capture d'écran de votre process TEST, je pense que vous pouvez laisser la syntaxe ${../p1}$ dans les actions Variable Manager, il faut simplement que vous utilisiez la bonne syntaxe en ligne de commande : -var ~/p1 param1 -var ~/p2 param2
Cela devrait fonctionner ainsi, sans modifier le process et dans les 3 modes : Designer, Ligne de commande et Webservice

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

Est-ce qu'il y aurait un logLevel défini ? Si c'est le cas et s'il supprime les actions alors c'est normal.
Dans ce cas vous pouvez voir dans la log com.indy.engine.42000.TEST.log des lignes de ce type :
04/04/2018 11:44:55,379 INFO - TEST Start purge Log Thread for session: 0a4722010162900b7df1ddbf2911d121
04/04/2018 11:44:55,379 INFO - TEST Purge Log Thread is started for session: 0a4722010162900b7df1ddbf2911d121

Est-ce le cas ? Si non je vous invite à ouvrir un ticket auprès du support.

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