2012-03-24 36 views
6

Hemos migrado recientemente de la plataforma MOSS 2007 a SP 2010. Tenemos este flujo de trabajo de SharePoint Designer muy utilizado (500 o más instancias por día). (usa infopath para enviar datos) Básicamente es un flujo de trabajo de aprobación en serie que implica muchos niveles de aprobación. Después de la migración, casi el 90% de nuestro flujo de trabajo termina en estado "Ocurrió" con la siguiente descripción del error: El flujo de trabajo no pudo actualizar el elemento, posiblemente porque una o más columnas para el elemento requieren un tipo de información diferente.Error de flujo de trabajo: el flujo de trabajo no pudo actualizar el elemento, posiblemente porque una o más columnas para el elemento requieren un tipo diferente de información

He buscado en muchos sitios web y msdn, intenté posiblemente todas las soluciones proporcionadas, pero ninguna parece funcionar. No hay un patrón establecido para los flujos de trabajo que producen errores y reiniciar el flujo de trabajo siempre resuelve el problema.

  1. Hemos emparejado todas las columnas/tipo de contenido y no hay diferencia en MOSS 2007 y nuevas formas biblioteca

  2. Los niveles de permisos de usuarios no se cambian

Una gran cantidad de sitios mencionar la introducción de una pausa en el flujo de trabajo antes del evento de actualización, pero soy escéptico al hacerlo. ¿Cuál podría ser la posible causa/solución? no podemos identificar nada que sea común o dirigirnos a la causa raíz entre estos flujos de trabajo con falla del 90%. Algunas de las instancias de flujo de trabajo también generan un error, el flujo de trabajo no pudo actualizar el elemento mientras estaba desprotegido a otro usuario.

Cualquier ayuda sería muy apreciada.

Respuesta

4

Tuve el mismo problema en el pasado y el retraso de 1 minuto lo resolvió. En mi experiencia, las inconsistencias en términos de qué elementos fallan y cuáles no, nos hicieron mirar el camino de un problema de bloqueo. No tenía ningún sentido de lo contrario. Si tomamos un elemento específico en la lista y lo probamos, a veces el flujo de trabajo se ejecutará correctamente y otras veces fallará. Dependiendo del hardware que usamos, obtendríamos resultados completamente diferentes con la misma configuración.

Otros con un informe de problema similar bloqueando el 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!

Cuando se hizo la migración, participó nuevo hardware? También se debe tener en cuenta que SharePoint 2010 requiere más potencia que 2007.

0

Antes de asumir un problema de bloqueo/temporización, asegúrese de que su flujo de trabajo no esté actualizando al tipo de columna incorrecto. En nuestro caso, intentamos actualizar un campo Persona o Grupo con datos no válidos.

1

El problema parece ser, de hecho, en relación con el intento de cambiar el campo bloqueado. Si no desea introducir un retraso de 1 minuto en su flujo de trabajo antes de cambiar los campos previamente actualizados en su flujo de trabajo (eso siempre debería funcionar ...) es posible que desee agregar Esperar cambio de campo en la acción del elemento actual entre las actualizaciones del mismo campo. En algunas circunstancias, eso es posible y funcionó bastante bien en este caso.

0

Para mí que estaba relacionado con los permisos de usuario:

flujo de trabajo fue la creación de un elemento en otra lista en nombre del usuario y que estaba teniendo sólo lectura permisos en esa lista, dando contribuyen permisos en otra lista funcionó .

Cuestiones relacionadas