Activer un flux de travail SharePoint en mettant à jour un élément de la liste via le service Web Liste

Question

Je développe un simple flux de travail séquentiel SharePoint qui devrait être lié à une bibliothèque de documents. Lors de l’association du petit flux de travail à une bibliothèque de documents, j’ai coché ces options

• Autoriser ce flux de travail à être manuellement commencé par un utilisateur authentifié avec les autorisations d'édition d'éléments.
• Démarrer ce flux de travail quand un nouvel élément est créé.
• Démarrer ce flux de travail lorsque un élément est modifié.

Maintenant, je télécharge un document dans cette bibliothèque et le flux de travail commence et envoie par exemple un courrier électronique. C'est terminé et tout va bien.

Lorsque je sélectionne Modifier les propriétés sur le nouvel élément et enregistre une modification, le flux de travail est à nouveau déclenché. Absolument ce à quoi nous nous attendions.

Même lors de la copie d'un nouvel élément dans la bibliothèque à l'aide du service Web Copy.asmx, le flux de travail démarre normalement.

Mais maintenant , je souhaite mettre à jour l'élément via le fichier WebService Lists.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 en cours de mise à jour (l'horodatage a été modifié et une propriété fictive également), mais le flux de travail NE redémarre PAS.

Ce comportement est reproductible sur notre système de test de développement et .

Vérification des journaux d’erreurs (C: \ Program Files \ Fichiers communs \ Microsoft partagés \ extensions de serveur Web \ 12 \ LOGS) J'ai découvert un message d'erreur étrange:

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 peut-il confirmer ce comportement? Ou des astuces de solution?

Je vous tiens au courant de tout développement sur ce sujet.

Answer 1

Enfin, nous avons maîtrisé les processus de support technique de Microsoft et obtenu une solution!

Tout d'abord, Microsoft a déclaré qu'il s'agissait d'un bogue. Il s’agit d’un bogue mineur, car il existe une bonne solution de contournement, ce qui peut prendre un peu plus de temps, jusqu’à ce que ce bogue soit corrigé (le technicien du support a dit quelque chose avec le prochain service pack ou la prochaine version (!)).

Mais maintenant pour le problème.

Le rappel

Regardons le code CAML de ma question:

<Method ID='1' Cmd='Update'>
  <Field Name='ID'>1</Field>
  <Field Name='myDummyPropertyField'>NewValue</Field>
</Method>

Pour une raison quelconque, le gestionnaire de flux de travail ne fonctionne pas avec l'ID, nous avons entré la deuxième ligne. Étrange, toutes les autres commandes SharePoint fonctionnent avec l'ID, mais pas avec le gestionnaire de flux de travail. Le gestionnaire de flux de travail fonctionne avec le " pleinement qualifié " Nom du document. Par conséquent, comme nous n'avions aucune idée et que nous n'avions saisi aucun nom de document qualifié complet, Workflow Manager utilisait par défaut le nom de la bibliothèque de documents actuelle. Et maintenant, le message d'erreur commence à avoir un sens:

The object specified does not belong to a list.

Bien sûr, l’objet (bibliothèque de documents) n’appartient pas à une liste, c’est la liste.

La solution

Nous devons ajouter une ligne supplémentaire à notre requête CAML:

<Field Name='FileRef'>/sites/mySite/myDocLib/myFolder/myDocument.txt</Field>

FileRef transmet le nom de document qualifié complet au gestionnaire de flux de travail, qui - à présent totalement satisfait - démarre le flux de travail de l'élément.

Attention, vous devez inclure le chemin d'accès absolu complet du serveur, en omettant votre nom de serveur (trouvé par exemple dans la propriété ServerRelativePath de votre SPItem).

Requête CAML complète:

 <Method ID='1' Cmd='Update'>
    <Field Name='ID'>1</Field>
    <Field Name='FileRef'>/sites/mySite/myDocLib/myFolder/myDocument.txt</Field>
    <Field Name='myDummyPropertyField'>NewValue</Field>
  </Method>

L'avenir

Peut-être que ce comportement non documenté sera corrigé dans l'un des prochains Service Packs, peut-être pas. Le support technique Microsoft s'est excusé et va publier un article MSDN sur ce sujet. Pour le mois prochain, j'espère que cet article sur stackoverflow aidera les développeurs dans la même situation.

Merci d'avoir lu!

Answer 2

Nous avons rencontré un problème similaire avec un flux de travaux d'approbation. Pour le résoudre, nous avons écrit notre propre récepteur d’événements et l’avons joint à la liste. Selon que l'élément a été mis à jour ou modifié, nous avons ensuite déclenché le workflow d'approbation.

J'espère que cela vous aidera ...

Answer 3

J'ai également rencontré ce problème et découvert qu'une fois qu'un flux de travail avait démarré, il ne pouvait plus être redémarré automatiquement, quelle que soit la méthode de mise à jour de l'élément. Vous pouvez cependant redémarrer manuellement le flux de travail autant de fois que vous le souhaitez.

Answer 4

J'ai vu le même comportement. Mais alors vous obtenez tels messages , montrant aux utilisateurs comment en créer un par jour pour configurer des rappels par e-mail.