2012-03-24 11 views
6

Abbiamo migrato di recente dalla piattaforma MOSS 2007 alla piattaforma SP 2010. Abbiamo questo flusso di lavoro di SharePoint Designer molto utilizzato (500 e più istanze al giorno). (usa l'infopath per inviare dati) È fondamentalmente un flusso di lavoro di approvazione seriale che coinvolge molti livelli di approvazione. Dopo la migrazione quasi il 90% del nostro flusso di lavoro termina nello stato "Errore occorso" con la seguente descrizione dell'errore: Il flusso di lavoro non è stato in grado di aggiornare l'elemento, probabilmente perché una o più colonne per l'articolo richiedono un diverso tipo di informazioni.Errore flusso di lavoro: il flusso di lavoro non è stato in grado di aggiornare l'articolo, probabilmente perché una o più colonne per l'articolo richiedono un diverso tipo di informazioni

Ho cercato un sacco di siti Web e msdn, ho provato tutte le soluzioni possibili, ma nessuna sembra funzionare. Non esiste un modello predefinito per i flussi di lavoro che generano errori e il riavvio del flusso di lavoro risolve sempre il problema.

  1. Abbiamo abbinato tutte le colonne/tipo di contenuto e non v'è alcuna differenza di MOSS 2007 e le nuove forme biblioteca

  2. livelli di autorizzazione degli utenti non vengono modificate

Un sacco di siti menziono l'introduzione di una pausa nel flusso di lavoro prima dell'evento di aggiornamento, ma sono scettico nel farlo. Qual è la possibile causa/soluzione? non possiamo identificare nulla di comune o indirizzarci alla causa principale di questi flussi di lavoro che non rispondono al 90%. Anche alcune istanze del flusso di lavoro hanno generato un errore, il flusso di lavoro non è stato in grado di aggiornare l'elemento quando è stato estratto da un altro utente.

Qualsiasi aiuto sarebbe molto apprezzato.

risposta

4

Ho avuto lo stesso problema in passato e il ritardo di 1 minuto è stato risolto. Nella mia esperienza, le incongruenze in termini di quali elementi falliscono e quali no, ci hanno spinti a guardare in basso il percorso di un problema di blocco. Non aveva senso altrimenti. Se abbiamo preso un elemento specifico nell'elenco e lo abbiamo testato, a volte il flusso di lavoro sarebbe stato eseguito correttamente e altre volte non avrebbe funzionato. A seconda dell'hardware utilizzato, otterremmo risultati completamente diversi con la stessa configurazione.

Altri con un problema simile segnalano il blocco come problema. http://social.technet.microsoft.com/Forums/en-US/sharepoint2010customization/thread/fc4e1073-d67f-449a-b443-e5805f5358c7

It appeared to me that maybe it was a locking/timing issue....it appeared the workflow kicked off and tried updating fields in the doc library item before the locks were released on the InfoPath form that created the item!

quando hai fatto la migrazione, è stato coinvolto il nuovo hardware? Anche in questo caso, SharePoint 2010 richiede più potenza rispetto al 2007.

0

Prima di assumere un problema di blocco/temporizzazione, assicurarsi che il flusso di lavoro non si aggiorni al tipo di colonna errato. Nel nostro caso, stavamo tentando di aggiornare un campo Persona o Gruppo con dati non validi.

1

Il problema sembra essere infatti correlate a tentativo di cambiare il campo protetto. Se non si desidera introdurre 1 minuto di ritardo nel flusso di lavoro prima di modificare i campi precedentemente aggiornati nel proprio flusso di lavoro (che dovrebbe funzionare sempre), è possibile aggiungere Wait for Field Change in Current item action tra gli aggiornamenti dello stesso campo. In alcune circostanze è possibile e ha funzionato abbastanza bene nel caso di maggio.

0

Per me era legato a permessi degli utenti:

flusso di lavoro è stata la creazione di un elemento in un altro elenco sul conto dell'utente e lui stava avendo letto solo i permessi in quella lista, dando contribuire permessi su un'altra lista ha funzionato .