Discussion :

[funckfot]

la commande UNIX "pmcmd startworkflow" permet de lancer directement un workflow sans modifier les "properties" du workflow.

Cependant, certaines options de la session doivent être modifié manuellement dans le workflow manager (obligé de faire un chek out). Sauf si l'on a déterminé une variable (exemple ! $$OWNER ou $DBConnection_XX) dans la session et présente dans le fichier de paramétrage. A ce moment là nous passons par le fichier de paramétrage.

ma question est : "y a t'il un moyen de transmettre des options de la session autrement que par le fichier de paramétrage lorsque j'utilise une commande UNIX?"
Exemple : la connexion, le schéma ...

[alexisongagna]

Bonjour,

J'ai compris ta question mais j'en ai une pour toi. Pourquoi ta session doit etre en chek out avant de lancer ton workflow ?

[funckfot]

Bonjour,

J'ai compris ta question mais j'en ai une pour toi. Pourquoi ta session doit etre en chek out avant de lancer ton workflow ?

je crois que les sessions ne peuvent pas être en check out, mais plutôt les workflows.

Sinon justement, l'utilité de cette commande c'est justement de ne rien mettre en check out.
C'est pour des histoires de fiabilités et de besoins lors de la livraison pour le client.

[alexisongagna]

Bonjour,

Les procédures de livraison varient effectivement d'un client à un autre.
Mais, normalement, ce qui doit être exécuté en prod est censé être propre et fonctionnel. Dans ce cas, tous les objets sont stockés dans le repository en mode checkin (ne peut être modifié).

Tous les objects peuvent être en checkin/ check out (mapping, session et workflow). Sur ton poste de développement tu récupères les objets du repo de dev et tu les check out sur ton poste pour éventuellement les modifier. Mais une fois testés et recettés, les objets sont chek in. Pour livrer tu ne livres que les objets check in, c'est à dire les objects qui ne sont pas en cours de dev.

[funckfot]

Bonjour,

Les procédures de livraison varient effectivement d'un client à un autre.
Mais, normalement, ce qui doit être exécuté en prod est censé être propre et fonctionnel. Dans ce cas, tous les objets sont stockés dans le repository en mode checkin (ne peut être modifié).

Tous les objects peuvent être en checkin/ check out (mapping, session et workflow). Sur ton poste de développement tu récupères les objets du repo de dev et tu les check out sur ton poste pour éventuellement les modifier. Mais une fois testés et recettés, les objets sont chek in. Pour livrer tu ne livres que les objets check in, c'est à dire les objects qui ne sont pas en cours de dev.

Tu sais si je demande cela, c'est que le problème est un peu plus compliqué. Pour le coup nous avons des normes aussi de dev et on ne peut pas tout faire.
Nous avons des des folder commun. c'est un peu complexe.

[alexisongagna]

Ok. Je comprends bien. Les procédures d'industrialisation varient d'un client à un autre. Bon courage.