Nous avons récemment migré de Moss 2007 sur la plate-forme SP 2010. Nous avons ce flux de travail SharePoint Designer fortement utilisé (500 et plus d'instances par jour) qui utilise InfoPath pour soumettre des données. Il s'agit essentiellement d'un flux de travail d'approbation en série impliquant de nombreux niveaux d'approbation. Après la migration, près de 90% de notre flux de travail est terminé par «Erreur survenue» de l'état avec la description suivante de l'erreur:
Le flux de travail n'a pas pu mettre à jour l'élément, éventuellement car une ou plusieurs colonnes pour l'élément nécessitent un type d'informations différent.
Il n'y a pas de motif défini pour les flux de travail qui entraînent une erreur et le redémarrage du workflow résout toujours le problème.
Nous avons assorti toutes les colonnes / Type de contenu et il n'y a pas de différence dans MOSS 2007 et la nouvelle bibliothèque de formulaires
Les niveaux d'autorisation des utilisateurs ne sont pas modifiés
Beaucoup de sites mentionnent une pause dans le flux de travail avant l'événement de mise à jour, mais je suis sceptique à le faire. Quelle pourrait être la cause / solution possible? Nous ne pouvons identifier rien qui soit commun ou direct à la cause fondamentale parmi ces flux de travail échoués à 90%. Une partie de l'instance de flux de travail entraîne également une erreur:
Le flux de travail n'a pas pu mettre à jour l'élément tel qu'il a été vérifié à un autre utilisateur.
5 Réponses :
J'ai eu le même problème dans le passé et le retard de 1 minute résolu. D'après mon expérience, les incohérences sur lesquelles les articles échouent et qui n'ont pas, nous avons fait la recherche de la voie d'un problème de verrouillage. Cela n'a eu aucun sens autrement. Si nous avons pris un élément spécifique dans la liste et que nous avons testé, le flux de travail fonctionnerait parfois avec succès et d'autres fois, cela échouerait. Selon le matériel que nous avons utilisé, nous obtenions des résultats entièrement différents avec la même configuration.
Autres avec un rapport de numéro similaire Verrouiller comme problème. http: //social.technet .microsoft.com / Forums / FR-US / SharePoint2010Customization / Fil / FC4E1073-D67F-449A-B443-E5805F5358C7
Il m'a semblé que c'était peut-être un problème de verrouillage / chronométrage ... apparu le flux de travail a lancé et essayé de mettre à jour des champs dans le doc élément de la bibliothèque avant que les serrures ne soient libérés sur la forme INFOPATH créé l'article!
Lorsque vous avez fait la migration, le nouveau matériel était-il impliqué? En outre, le facteur de SharePoint 2010 nécessite plus de pouvoir que 2007.
Avant d'assumer une question de verrouillage / chronométrage, assurez-vous que votre flux de travail n'est pas à jour sur le type de colonne incorrect. Dans notre cas, nous essayions de mettre à jour une personne ou un champ de groupe avec des données non valides.
Si cela se produit au hasard, probablement assez sûr d'exclure la question des autorisations. Je pense que j'ai pu résoudre mon problème et basé sur mes tests - jusqu'à présent si bon.
http: / /wwww.eveningblog.com/archive/sharepoint-2010-Error-the-workflow-could-not-update-the-item/
Le problème semble être en fait lié à la tentative de modification du champ verrouillé. Si vous ne souhaitez pas introduire de délai de 1 minute à votre flux de travail avant de modifier les champs précédemment mis à jour de votre flux de travail (qui devrait toujours fonctionner ..) Vous voudrez peut-être ajouter une attente de changement de champ dans l'action actuelle des mises à jour du même champ. Dans certaines circonstances qui sont possibles et travaillaient assez bien en mai.
Il peut y avoir beaucoup de causes pour la question, pour moi, il était lié aux autorisations de l'utilisateur:
Workflow créait un élément dans une autre liste pour le compte de l'utilisateur et il ne disposait que d'autorisations sur cette liste, en donnant des autorisations de contribution sur une autre liste qu'il a fonctionné.