-1

Un peu d'expérience: Je travaille pour une entreprise qui produit un produit qui a un flux de travail pour des projets comportant de nombreuses tâches en même temps. Pour cette discussion, disons que le projet A crée 4 sous-projets.Sharepoint Designer 2007 - Flux de travail et relations de flux de travail secondaires

Le projet principal et les 4 flux de travail de sous-projet créeront des tâches dans la liste principale des tâches. Le principal problème que je rencontre est de savoir comment associer les tâches créées par les workflows des sous-projets au projet principal.

Par exemple:

projet A est créé dans la liste des projets. Cette liste est associée à un flux de travail appelé "démarrage du projet". Ce workflow est un workflow de démarrage manuel qui, lorsqu'il est démarré, crée les quatre sous-projets dans une liste de sous-projets. Ces sous-projets doivent s'exécuter simultanément, c'est pourquoi je les ai créés dans une liste secondaire avec leurs propres workflows. La liste des sous-projets a 4 flux de travail associés pour gérer les 4 sous-projets - chacun de ces "démarrage automatique" lorsque les sous-projets sont créés dans la liste des sous-projets.

De toute façon, pour économiser quelques je désignerai les sous-projets sous forme d'unités 1 - 4.

Je crée le projet A et commencer manuellement est workflow. Le workflow de démarrage du projet crée les éléments Unit 1, Unit 2, Unit 3 et Unit 4 dans la liste des sous-projets (en même temps, car comme je l'ai déjà dit, ces éléments doivent être exécutés simultanément). Chacun des flux de travail du gestionnaire d'unités commence et commence à créer leurs tâches à effectuer dans la liste des tâches. J'utilise la tâche «Attribuer une tâche à faire» car tout ce que j'ai besoin de savoir pour que le flux de travail progresse dans ses étapes est de savoir si le travail est terminé ou non. Une fois tous les workflows de 4 unités terminés, le flux de travail de Project Start commencera à gérer les parties finales du projet avant la fin avec des tâches supplémentaires (approbations du gestionnaire, etc.).


Maintenant, la question que j'ai est que le point de vue que je l'ai mis en place pour la liste des tâches affiche les colonnes « titre, date de début, date de fin, l'état d'achèvement et un lien ». La colonne de lien affiche un lien renvoyant à l'élément de liste de création. Pour cet exemple, le flux de travail du gestionnaire Unit 1 fonctionne sur l'élément UNIT 1 créé par le projet A. Ainsi, pour "Exemple de tâche 1" créé par le workflow du gestionnaire d'unité, le lien est "Unité 1". Cela n'est pas entièrement utile car lorsque quelqu'un regarde sa liste de tâches, il peut avoir plusieurs "exemple de tâche 1" de plusieurs projets. L'affichage de UNIT 1 comme élément de référence ne signifie rien pour l'utilisateur. Ce que je veux afficher est le titre du projet maître afin qu'ils puissent trier leurs tâches par projet. Le tri par "Unité x" ne signifie rien.

Maintenant, ma solution initiale était de créer une colonne "projet" dans la liste des tâches. Dans cette colonne, je pourrais créer un autre sous-workflow que tout ce qu'il ferait serait de rechercher le projet initialement créé en recherchant et en référençant le flux de travail et les ID d'élément et de définir cette nouvelle variable "projet" au projet maître initiateur. cet exemple). Ce flux de travail fonctionne! Cependant, et cela semble être un problème "courant" dans MOSS 2007, le fait que ce sous-workflow s'exécute dans la liste des tâches peut (et a) créé plusieurs erreurs de verrouillage qui montrent - "cet élément ne peut pas être modifié comme il est verrouillé par un flux de travail déjà en cours d'exécution ". Cette erreur réduit le workflow à un arrêt et n'est pas une erreur qui est récupérable. J'ai recherché cette erreur et c'est une erreur inévitable qui n'a aucune solution simple et facilement déployable. Cela a quelque chose à voir avec la base de données backend et comment/quand elle stocke les variables de l'item de tâche de mise à jour et ainsi de suite. Une fois le flux de travail verrouillé, vous avez terminé.Donc, ce dont j'ai vraiment besoin, c'est d'une solution astucieuse pour associer le projet principal à n'importe quelle sous-tâche. Si la tâche est créée par le workflow "démarrage du projet", cela se fait automatiquement car la colonne "link" associe automatiquement cette tâche à l'item de création ... qui dans ce cas est "projet a" - assez facile. Cependant, en raison de mon besoin pour les sous-éléments supplémentaires sur une liste séparée avec leurs propres flux de travail ..... Je perds cette référence.

Existe-t-il un moyen d'associer les tâches créées à partir des workflows de la liste de sous-projets au projet principal sans avoir à appeler un autre sous-workflow pour définir cette variable. (c'est-à-dire: un moyen d'éviter le problème "cet élément est bloqué par un flux de travail en cours d'exécution").

Je pense que je réfléchis trop à cette solution et que je ne vois plus la forêt pour les arbres.

+1

Très franchement, personne ne va lire ceci. Vous obtiendrez de meilleurs résultats si vous condensez votre question autant que possible. – James

+0

J'ai essayé de condenser le plus possible tout en laissant autant d'informations pertinentes que possible. Il y a certaines exigences pour cette solution particulière qui ne sont pas «communes» à d'autres situations similaires. D'où le poste est un peu plus long que la plupart. –

Répondre

0

Malheureusement, je pense que votre solution est d'arrêter d'utiliser SharePoint Designer pour ce flux de travail. Vous pouvez soit acheter un produit de flux de travail tiers pour SP2007, soit créer une fonctionnalité de workflow dans le code à l'aide de Visual Studio.

Vous voulez arriver à une position où 1 flux de travail peut faire tout ce que vous voulez: exécuter un projet et créer 4 branches parallèles, chacune créant des tâches exactement comme vous le souhaitez (avec une colonne Projet) plutôt que les options très limitées que vous avez de SPD.

Questions connexes