2010-01-14 11 views
8

¿Cómo resolver este problema (en WF4):Cargando persistió flujo de trabajo después de workflowdefinition ha cambiado en WF4

puedo crear un flujo de trabajo en XAML y empezar a varios de ellos que, tengo un persistancestore y todos los flujos de trabajo de persistir en un marcador a la mitad de su flujo de trabajo.

Ahora detener la aplicación

Si te vuelvo a poner todo lo que se reanude la aplicación, es bien completa.

Pero, ¿qué ocurre si quiero cambiar la definición del flujo de trabajo después de que persisten las instancias en ejecución? la única manera de cargar los flujos de trabajo en ejecución (que yo era capaz de encontrar) es de la siguiente manera:

 WorkflowApplication wfapp = new WorkflowApplication(new WorkflowDefinition()); 
     wfapp.InstanceStore = new SqlWorkflowInstanceStore(connStr); 

     wfapp.Load(wfGuid); 

por lo que necesita la definición de flujo de trabajo, si ha cambiado durante la persistencia, las cosas van muy mal.

¿Cuál es la mejor manera de resolver esto?

+1

Por cierto, este escenario es el tema de algunos de los futuros de WF4. Vea esta presentación de MIX 10: http://channel9.msdn.com/Events/PDC/PDC10/FT08 – Will

Respuesta

3

Este escenario es un problema. No hay forma de migrar a una definición de flujo de trabajo anterior al nuevo formato. He realizado algunas pruebas limitadas y algunos escenarios con actividades de adición/eliminación que aún no se han ejecutado funcionaron bien. Pero también tengo escenarios que van mal, incluida la ejecución de una actividad ya finalizada.

Por lo que yo sé, no hay una buena manera de resolver el problema que no sea rastrear la versión del ensamblado XAML utilizado para crear el flujo de trabajo y verificar que cuando desee reiniciar un flujo de trabajo determine la versión del flujo de trabajo. utilizar.

1

No es tanto un problema con Windows Workflow como es el servicio de persistencia de SQL. Podría crear su propio servicio de persistencia que pueda manejar esta situación, ya sea apoyando la conversión del flujo de trabajo anterior al nuevo flujo de trabajo o algo más abstracto, como un servicio de persistencia serializado como XML/JSON, algo que podría soportar más fácilmente la deserialización de uno versión como otra versión.

2

Muchas versiones de un mismo flujo de trabajo tiene que coexistir. Quiero decir, las instancias antiguas tienen que terminar con la versión de flujo de trabajo anterior, y las nuevas tienen que comenzar con la nueva versión de flujo de trabajo. En mi caso, tenemos servicios de flujo de trabajo. Está en la configuración donde un enrutador describe el orden en que las instancias intentan ejecutarse. Si una instancia no puede comenzar a trabajar con una versión, se prueba la siguiente, y así sucesivamente.

Además, si su cambio no implica cambios en las variables de flujo de trabajo, contratos expuestos, etc ... las versiones de instancia de flujo de trabajo antiguas y nuevas pueden ejecutarse en la misma versión de flujo de trabajo. Lo sabrás, probándolo.

1

Es posible cargar la instancia de wf persistente después de cambiar la definición en WF4 - tiene que analizar y cambiar los archivos xml que almacena el motor de wf. Debe crear dos flujos de trabajo iguales: con la versión anterior y la nueva y compararlos para eliminar las diferencias. Esto se debe hacer para la definición xml y el XML de datos complejos que se usa para almacenar el estado del flujo de trabajo. Analizarlo con LinqToXML le ahorrará mucho tiempo y debe asegurarse de haber verificado todas las diferencias: si queda una diferencia, la wf no podrá cargar. Hay un elemento "ResumeData", que puede encontrar en el wf state xml, que es demasiado pesado para analizar, pero la buena noticia es que simplemente puede eliminarlo.