Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!
Free Trial

Forum

Trouvez des réponses, posez des questions, et partagez votre expertise d’Alteryx.
TIPS de la semaine

Chaque semaine, découvrez de nouvelles astuces et bonnes pratiques pour devenir un expert !

Voir l'index
RÉSOLU

Le partage d'un workflow en répertoire réseau ou sur le disque local ????

Bourgi
Météore

Bonjour,

 

Je souhaite partager un workflow avec des collègues et donc plusieurs utilisateurs (possibilité qu'ils l'utilisent en même temps) mais chacun dispose un dossier le répertoire réseau.

 

Nous avons fait le test dans un répertoire réseau et nous avons toujours des erreurs (voir les photos) alors que dans le disque local c'est OK.

 

Capture d’écran 2021-08-26 164030_LI (3).jpg

Capture d’écran 2021-08-26 164059_LI.jpg

Ma question est : Est-ce qu'il faut le partager sur le répertoire réseau (si oui comment procéder) ou dans le disque local de son poste ???    

 

Nous souhaiterons mes collègues et moi travailler sur réseau.

NB: J'ai utilisé la dépendances de workflow options Tout UNC.

J'ai 10 fichiers (sources différentes) en entrée et 14 sorties. J'ai aussi utilisé les outils Message et Block Until Done.

 

Merci d'avance.

 

6 RÉPONSES 6
PeterA1
Alteryx
Alteryx

Bonjour @Bourgi et s'il vous plait excusez mon pauvre francais, 

 

je pense que l'erreur vient potentiellement du fait que les fichiers de votre outil "input data" peuvent être

ouverts par un autre utilisateur car ils se trouvent sur un dossier du répertoire réseau. 

 

est-il possible que les fichiers soient ouverts par un autre utilisateur au moment de l'exécution?

 

-Peter

 

Bourgi
Météore

Bonjour @PeterA1 ,

 

Non, les fichiers sont fermés au moment où nous réalisons l'exécution du workflow.

On a pensé la même chose que vous mais le problème existe toujours. 

 

Abdou,

 

 

PeterA1
Alteryx
Alteryx

une autre option, si vous devez garantir l'ordre du processus est d'utiliser une macro batch au lieu de bloquer jusqu'à ce que ce soit fait. Ce Knowlege Base explains more

Bourgi
Météore

Merci beaucoup, je vais regarder cette solution.

 

 

StephaneP
Alteryx
Alteryx

Bonjour @Bourgi ,

 

En complément de la proposition de @PeterA1  voici un autre approche à tester.

 

Il me semble d'après le message que l'erreur vient des outils de sortie. Cette erreur se produit généralement dans 2 cas.

 

1. Lorsqu'Alteryx essaye d'écrire dans un fichier qui est déjà locké par un utilisateur ou par un workflow qui essaye lui aussi d'écrire dedans. Ceci peut se produire si 2 personnes lancent des workflows quasi simultanément qui écrivent dans le même fichier en sortie. Le 1er n'aura pas d'erreur et le 2ème aura votre erreur.

On ne peut pas faire grand chose nativement. En contournement, vous pouvez modifiez vos workflows pour écrire la valeur 1 dans un fichier ENCOURS.txt dans un répertoire qui précisera aux autres workflows que vous êtes en cours d'écriture et le repasser à 0 à la fin de votre traitement. Et ainsi les workflows peuvent tester la valeur dans ce fichier lorqu'on les lance et s'arreter si il est à 1.

 

2. Cela peut aussi se produire si dans un même workflow vous écrivez dans le même fichier de sortie via 2 branches distinctes.

Exemple: La branche 1 écris dans l'onglet S1 du fichier output.xlsx (et donc le locke) et la branche 2 écris dans l'onglet S2 du même fichier output.xlsx avant que la branche 1 est terminée. Elle sort donc en erreur.

 

Pour éviter cela on peut utiliser l'objet "Block Until Done" (Bloquer jusqu'à la fin" en français) qui impose à Alteryx de traiter les branches dans l'ordre. Dans cet exemple d'abord écrire l'onglet Corporate puis l'onglet Local.

StephaneP_0-1631913360924.png

Ceci implique d'avoir à un moment au moins un flux commun dont partiront les 2 branches.

 

Enfin, souvent le fait de passer de local à réseau modifie les temps d'écriture/lecture. Et donc parfois des workflows qui se bloquent sur un emplacement réseau ne se bloquent pas sur un autre...Idem si les volumes d'écritures augmentent cela peut générer plus de temps d'écriture et donc plus de risque de lock.

 

J'espère que cela aidera.

 

Bonne soirée,

Stéphane Portier
Sales Engineer
Alteryx
MarieC
Alteryx Alumni (Retired)

Merci @PeterA1  et @StephaneP 

Étiquettes