Tir d'un Flux de travail SharePoint par la mise à jour d'un élément de la liste par le biais de la Liste de Webservice
Je suis en train d'élaborer, une simple SharePoint Workflow Séquentiel qui doit être lié à une bibliothèque de documents. Lors de l'association de la petite flux de travail à une bibliothèque de documents, j'ai vérifié ces options
- Permettre à ce flux de travail manuellement
a commencé par un utilisateur authentifié
avec les Autorisations Modifier les Éléments. - Commencer
ce flux de travail lorsqu'un nouvel élément est
créée. - Démarrer le flux de travail lorsque
un élément est modifié.
Maintenant j'ai télécharger un document à cette bibliothèque et le flux de travail démarre et par exemple, envoie un mail. Il complète et tout va bien.
Quand j'sélectionnez Modifier les Propriétés sur le nouveau poste et enregistrer un changement, le flux de travail est déclenché à nouveau. Tout à fait ce que nous attendions.
Même lors de la copie d'un nouvel Élément dans la bibliothèque avec l'aide de la Copie.asmx Webservice, le flux de travail démarre normalement.
Mais maintenant je veux mettre à jour l'élément via le SharePoint WebService Listes.asmx.
Mon CAML va ici:
<Method ID='1' Cmd='Update'>
<Field Name='ID'>1</Field>
<Field Name='myDummyPropertyField'>NewValue</Field>
</Method>
L'Élément est mis à jour (timestamp a changé et une propriété factice, trop), mais le flux de travail ne recommence PAS.
Ce comportement est reproduit sur notre développement et système de test.
Vérifier les journaux d'erreur (C:\Program Files\Fichiers Communs\Microsoft Shared\web server extensions\12\LOGS), j'ai découvert un étrange message d'erreur:
09/25/2008 16:51:40.17 w3wp.exe (0x1D94) 0x1D60 Windows SharePoint Services General 6875 Critical Error loading and running event receiver Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver in Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Additional information is below. : The object specified does not belong to a list.
Quelqu'un qui peut confirmer ce comportement? Ou de toute solution de conseils?
Je suis de vous tenir informé de toute évolution sur ce sujet.
Pensez-vous que votre workaroung va le faire dans la production de l'utiliser? Et avez-vous trouvé un moyen de déclencher les flux de travail à l'extérieur? J'ai ouvert un litige en services de support technique microsoft. J'espère qu'ils nous sortiront de cette question. Bien sûr, je vais poster toutes les news ici!
OriginalL'auteur Johannes Hädrich | 2008-09-25
Vous devez vous connecter pour publier un commentaire.
Enfin, nous avons obtenu grâce à l'appui des services de processus de chez Microsoft et a obtenu une solution!
Tout d'abord, Microsoft a déclaré que cela soit un bug. C'est un bug mineur, parce qu'il y est une bonne solution, donc il peut prendre un peu plus de temps, jusqu'à ce que ce bug sera corrigé (le technicien a dit quelque chose avec le prochain service pack oder prochaine version (!)).
Mais maintenant pour le problème.
La reaseon
Jetons un coup d'oeil au code CAML de ma question:
Pour une raison quelconque, le Gestionnaire de Flux de travail ne fonctionne pas avec l'ID, nous sommes entrés dans la deuxième ligne. Étrange, tous les autres SharePoint commandes de travail avec l'ID, mais pas le Gestionnaire de Flux de travail. Le Gestionnaire de Workflow fonctionne avec le "pleinement qualifié de" nom du document. Ainsi, parce que nous n'avions aucune idée et n'a pas saisi toutes les pleinement qualifié du nom du document, le Gestionnaire de Flux de travail par défaut, le nom de l'actuelle bibliothèque de documents. Et maintenant, le message d'erreur commence à prendre du sens:
Bien sûr, l'objet (de la bibliothèque de documents) n'appartient pas à une liste, il s'AGIT de la liste.
La solution
Nous devons ajouter une ligne supplémentaire à notre Requête CAML:
La FileRef passe le complet le nom du document pour le Gestionnaire de Flux de travail, qui est maintenant totalement heureux - démarre le flux de travail de l'élément.
Attention, vous devez inclure le plein absolu chemin d'accès au serveur, en omettant le nom de votre serveur (qui se trouve par exemple dans ServerRelativePath propriété de votre SPItem).
De travail complète, CAML Requête:
L'avenir
Peut-être ce sans-papiers comportement sera fixée dans l'un des prochains packs de service, peut-être pas. Support de Microsoft, a présenté ses excuses et va sortir un Article MSDN sur ce sujet. Pour le mois prochain, j'espère que cet article sur stackoverflow va aider les développeurs dans la même situation.
Merci pour la lecture!
OriginalL'auteur
Nous avons été confrontés à un problème similaire avec un Flux de travail d'Approbation.
Pour le résoudre, nous avons écrit notre propre Récepteur d'Événement et l'ont attaché à la liste.
Selon que l'article a été mis à jour ou modifiés, nous avons ensuite tiré le Flux de travail d'Approbation.
Espère que cela aide...
OriginalL'auteur
J'ai rencontré ce problème et trouvé une fois qu'un flux de travail a commencé, il ne peut pas être re-démarré automatiquement, peu importe comment vous mettez à jour l'article. Toutefois, vous pouvez démarrer manuellement le flux de travail de nouveau, autant de fois que vous le souhaitez.
OriginalL'auteur
J'ai vu le même comportement. Mais ensuite, vous obtenez messages comme celui-ci, montrant aux gens comment créer un par jour de mettre en place des rappels par courriel.
OriginalL'auteur