¿Al flujo de trabajo o no al flujo de trabajo?

122

Soy responsable de un equipo de desarrolladores que están a punto de comenzar a desarrollar un sistema de reclamos de seguros ligero. El sistema implica una gran cantidad de tareas manuales y flujos de trabajo empresariales y estamos analizando el uso de Windows Workflow (.NET 4.0).

Un ejemplo del dominio comercial es el siguiente: un titular de la póliza llama al centro de contacto para presentar un reclamo. Este "evento" dispara dos subtareas que se accionan manualmente en paralelo y puede tardar mucho tiempo en completarse;

  1. Verificar al cliente por fraude: un proceso manual mediante el cual un operador llama a varias compañías de crédito para verificar y evaluar el potencial de un cliente fraudulento. Desde aquí, la subtarea puede ingresar una serie de subestados (Verificación en curso, Verificación de referencia fallida, Verificación de referencia aprobada, etc.)
  2. Enviar artículo al centro de reparaciones: un proceso manual donde el artículo por el cual el titular de la póliza presentó el reclamo se envía al centro de reparaciones para su reparación. Desde aquí, la subtarea puede ingresar una serie de subestados (en espera de reparación, en curso, reparado, publicado, etc.). El reclamo solo puede continuar una vez que el estado de cada subtarea haya alcanzado un estado predefinido (basado en las reglas comerciales).

En la superficie, parece que Workflow es de hecho la mejor opción tecnológica; Sin embargo, tengo algunas preocupaciones al usar WF 4.0.

  1. Conjunto de habilidades: al observar el conjunto de habilidades de desarrollador promedio, no veo muchos desarrolladores que entiendan o conozcan el flujo de trabajo.
  2. Mantenimiento: parece haber poco apoyo dentro de la comunidad para los proyectos de WF 4.0 y esto, junto con la falta de habilidades, genera inquietudes en torno al mantenimiento.
  3. Barrera de entrada: tengo la sensación de que Windows Workflow tiene una curva de aprendizaje empinada y que no siempre es tan fácil de aprender.
  4. Nuevo producto: como Workflow se ha reescrito por completo para .NET 4.0, veo el producto como un producto de primera generación y es posible que no tenga la estabilidad necesaria.
  5. Reputación: las versiones anteriores de Workflow no fueron bien recibidas, se consideraron difíciles de desarrollar y dieron como resultado una mala aceptación del negocio.

Entonces, mi pregunta es ¿deberíamos usar Windows Workflow (WF) 4.0 para esta situación o hay una tecnología alternativa (por ejemplo, Simple State Machine , etc.) o incluso un mejor motor de flujo de trabajo para usar?

Kane
fuente
10
Varios votos a favor y sin respuestas ... Parece que todos estamos en el mismo barco ...;)
CJM
1
Jejeje ... tal vez la falta de respuestas es por el viernes-itis?
Kane
2
Para muchos recursos excelentes en WF4, visite endpoint.tv
Ron Jacobs el
44
No, decidí optar por WF4 y me alegro de haberlo hecho, simplemente no hay suficientes personas con conocimiento de WF4, además el negocio ha cambiado de opinión tantas veces que usar WF4 habría hecho que el sistema sea increíblemente difícil de mantener y soportar.
Kane
10
@Kane: omites un detalle jugoso: ¿qué terminaste haciendo en lugar de WF4? :)
Peter Lillevold el

Respuestas:

51

He realizado varios proyectos de WF4, así que veamos si puedo agregar información útil a las otras respuestas.

Según la descripción de su problema comercial, parece que WF4 es una buena combinación, por lo que no hay problemas.

Con respecto a sus preocupaciones tiene razón. Básicamente, WF4 es un producto nuevo y carece de algunas características importantes y tiene algunos bordes ásperos. Hay una curva de aprendizaje, tienes que hacer algunas cosas de manera diferente. El punto principal es la larga ejecución y la serialización, que es algo a lo que el desarrollador promedio no está acostumbrado y requiere pensar un poco para hacerlo bien, ya que escucho con demasiada frecuencia que las personas tienen problemas para serializar un contexto de datos de marco de entidades.

La mayoría de las veces, usar los servicios de flujo de trabajo alojados en IIS / WAS es la mejor ruta cuando se realizan estos tipos de flujos de trabajo de larga duración. Eso hace que la solución del problema de versiones no sea difícil tampoco, solo haga que el primer mensaje devuelva la versión del flujo de trabajo y que sea parte de cada mensaje posterior. A continuación, coloque el enrutador WCF en el medio que enruta el mensaje al punto final correcto según la versión. Lo básico es nunca cambiar un flujo de trabajo existente, siempre crear uno nuevo.

Entonces, ¿cuál es mi consejo para usted? No te arriesgues con una pieza de tecnología desconocida y no probada para ti. Haga una pequeña parte, no crítica, de la aplicación usando WF4. De esa manera, si funciona, puede expandirlo, pero si falla, puede extraerlo y reemplazarlo con un código .NET más tradicional. De esa forma, obtienes experiencia real con WF4 en lugar de tener que basar una decisión en información de segunda mano y aprendes una nueva y poderosa tecnología en el proceso. Si es posible, tome un curso sobre WF4 ya que eso le ahorrará mucho tiempo para ponerse al día (autoenchufe descarado aquí ).

Sobre la máquina de estado simple. No lo he usado, pero tenía la impresión de que era para máquinas de estado de corta duración, en memoria. Uno de los principales beneficios de WF4 son los aspectos de larga duración.

Maurice
fuente
2
Estoy de acuerdo, WF4 derritió completamente mi cerebro. Lamento la decisión (no mía) de usarlo en ese momento y deberíamos haber esperado .NET 4.5. Si comete un error en el flujo de trabajo y surgen errores, después de abordar el error en el diseño de WF, no puede correlacionar fácilmente con los flujos de trabajo persistentes de larga ejecución. Esencialmente tienes que comenzar de nuevo. 3.5 tenía DynamicUpdates, aunque lo dejaron fuera de 4.0. La actualización dinámica y las versiones de Side by Side en 4.5 son fundamentales para el éxito de una solución WF de Windows en mi experiencia. Sin embargo, eso es solo una pequeña parte de la imagen.
Stephen York
17

Llegué a este dilema un par de veces y decidí no usar la base Work Flow. Algunas de las consideraciones (similares a las suyas) fueron

  1. Los flujos de trabajo involucrados fueron mucho más simples (una combinación de máquina de estado y acciones secuenciales) y hacerlo en WF parece exagerar los esfuerzos involucrados.
  2. La curva de aprendizaje para que los desarrolladores entiendan y usen WF efectivamente se consideró alta. La tabla de transición de estado que describe las transiciones válidas y las acciones a tomar se utilizan para una flexibilidad adicional y los desarrolladores se sintieron cómodos con ella, entendiendo fácilmente el concepto y el propósito.
  3. Las posibilidades de cambios en los procesos de negocios eran escasas y los cambios rudimentarios eran fácilmente posibles con la ayuda de la tabla de transición. Un cambio en la transición significaría un script de base de datos, mientras que un cambio en las acciones daría como resultado una nueva versión / parche. Sin embargo, la probabilidad de tal ocurrencia se consideró baja.

Mirando hacia atrás después de 13-14 meses, sigo pensando que la decisión de no usar WF fue correcta. En mi opinión, WF tiene sentido donde hay una fuerte posibilidad de que el flujo de trabajo pueda cambiar y / o las reglas comerciales puedan cambiar. WF permite aislar el flujo de trabajo en un archivo separado y, por lo tanto, hacer que sea configurable por los usuarios será más simple.

VinayC
fuente
15

Hemos estado usando WF 4.0 los últimos meses. Tengo que decir que es desafiante pensar en el flujo de trabajo. Sin embargo, puedo decirte que vale la pena. Sabíamos muy poco cuando empezamos. Compramos un libro para principiantes y profesionales para WF 4.0 que ayudó. Yo mismo, vi muchos videos en línea y seguí a PDC 2009 por sus últimas noticias sobre WF 4.0 y cómo es diferente de las versiones anteriores algo desagradables. Una cosa importante para la que teníamos que proponer una solución es la forma en que podemos lidiar con In / Our Arguments en un flujo de trabajo sin limitar nuestras actividades personalizadas a ciertos tipos de datos y cómo pasar parámetros entre actividades. Se me ocurrió una buena solución para eso, y la experiencia de flujo de trabajo que tenemos hasta ahora no es mala en absoluto. Realmente, Tenemos una aplicación de flujo de trabajo cada vez más grande y realmente no puedo imaginarme resolviéndola en un entorno diferente. Me encanta el efecto visual que tiene: me mantiene alejado de los detalles de las construcciones if / else, etc. y hace que las reglas comerciales sean evidentes de una manera que no te obliga a sumergirte en líneas de código para saber qué está pasando o Cómo arreglar algunos errores. Por cierto, el proyecto en el que trabajamos es muy similar a lo que describiste y es un proyecto de tamaño mediano. Puede decir por mis palabras que me gusta y lo recomiendo, aunque incorpora algunos riesgos, ya que es una tecnología nueva y tiene que presentar algunas ideas innovadoras. me mantiene alejado de los detalles de las construcciones if / else, etc. y hace que las reglas comerciales sean evidentes de una manera que no te obliga a sumergirte en líneas de código para saber qué está sucediendo o cómo solucionar algún error. Por cierto, el proyecto en el que trabajamos es muy similar a lo que describiste y es un proyecto de tamaño mediano. Puede decir por mis palabras que me gusta y lo recomiendo, aunque incorpora algunos riesgos, ya que es una tecnología nueva y tiene que presentar algunas ideas innovadoras. me mantiene alejado de los detalles de las construcciones if / else, etc. y hace que las reglas comerciales sean evidentes de una manera que no te obliga a sumergirte en líneas de código para saber qué está sucediendo o cómo solucionar algún error. Por cierto, el proyecto en el que trabajamos es muy similar a lo que describiste y es un proyecto de tamaño mediano. Puede decir por mis palabras que me gusta y lo recomiendo, aunque incorpora algunos riesgos, ya que es una tecnología nueva y tiene que presentar algunas ideas innovadoras.

mis 2 centavos ...

Derar
fuente
2
Me interesaría saber acerca de su solución para manejar el paso de parámetros entre actividades. He estado jugando con WF de vez en cuando y esta es un área que me parece un poco arca, pero esa podría ser mi falta de comprensión.
Chris Taylor
Creo que es un lugar donde necesitan trabajar más. En cualquier caso, utilizamos un gran repositorio de "tabla global hash" donde agregamos variables escritas. La convención de nomenclatura para estas variables incorpora tanto su tipo, nombre como su actividad principal. Esto realmente nos ayudó en nuestra implementación. Me doy cuenta de que puede haber mejores formas de hacer esto, pero esto funciona muy bien y puede utilizarlo de diferentes maneras cuando diseña el flujo de trabajo. Por ejemplo, la actividad de GerCustomer podría tener un puñado de argumentos de entrada y 2 argumentos de salida: GetCustomer.str_customerID y GetCustomer.int_premium. Espero que esto ayude ...
Derar
9

Hice tres proyectos en WF 3.5 y tengo que decir que no es fácil. Te obliga a pensar de una manera completamente nueva, especialmente cuando se usa la persistencia. La actualización de la aplicación que contiene cientos de flujos de trabajo persistentes incompletos es un desafío. Un cambio único en la serialización los bloquea a todos. La introducción de múltiples versiones de la misma biblioteca para admitir flujos de trabajo en ejecución nuevos y antiguos es común. Fue un reto.

Todavía no he probado WF 4.0 pero, según la experiencia de BizTalk y WF 3.5, creo que será similar.

De todos modos, el mejor enfoque que puede tomar es hacer una Prueba de concepto. Tome un solo WF de sus requisitos e intente incorporarlo en WF 4.0. Pasará algún tiempo con él, pero probará si puede hacerlo en WF 4.0 y si hay algún beneficio visible.

Si decide usar WF 4.0, insisto en que verifique la posibilidad de ejecutar WF como servicio WCF alojado en Windows AppFabric. AppFabric proporciona algunas funciones listas para usar para alojar WF.

Ladislav Mrnka
fuente
44
Cuando pensaba usar WF para el motor de estado en mi aplicación, el problema de la persistencia siempre era molesto. La idea misma de WF serializable para cada caso abierto fue horrible por varias razones, incluidas las versiones. Entonces, mi esquema era que cada vez que ocurriera un disparador, recoja la entidad comercial, cree un flujo de trabajo nuevo y adjunte la entidad a ese flujo de trabajo y luego el flujo de trabajo haría el trabajo en función de la máquina de estado diseñada. Una vez completado, arroje el flujo de trabajo y guarde la entidad comercial sucia nuevamente en la base de datos. Pero, por supuesto, al final, decidí no usar WF en absoluto.
VinayC
2
Olvidé por completo el control de versiones, esto solo podría ser una razón suficiente para NO usarlo.
Kane
3
@ Kane, eso no es necesariamente cierto. Siempre puedes exteriorizar tu estado. Entonces, en lugar de "deserializar un flujo de trabajo y luego reanudarlo", creará una instancia de flujo de trabajo, adjuntará el estado externo y luego ejecutará el flujo de trabajo. Esto puede eliminar la necesidad de serializar y versionar el flujo de trabajo.
VinayC
Hola VinayC, ¿tienes una muestra simple de lo que estabas diciendo? "creará una instancia de flujo de trabajo, adjuntará el estado externo y luego ejecutará el flujo de trabajo", eso suena más o menos como algo que quiero PoC pero no sé realmente WF4 para probar una máquina de estado como esa, por favor.
Jportelas
9

Creo que hoy no tiene sentido hablar sobre Workflow en WF4 como una opción tecnológica para este tipo de problema. Lo que es realmente apropiado, como lo mencionó Ladislav Mrnka anteriormente, es WCF WF Services alojado en AppFabric.

Mi experiencia con esto es que paga grandes dividendos y es muy agradable, pero los problemas surgen al principio porque no se aprecia adecuadamente que para muchos programadores este es un cambio de metodología más que un cambio de tecnología. Por otro lado, los generalistas y aquellos con una mentalidad de resolución de problemas vieron WCF WF AppFabric como un conjunto de oportunidades emocionantes. Entonces, si la combinación de personas en el proyecto son desarrolladores de C # bastante conservadores unidos a su conjunto diario de OO y patrones, será difícil de introducir. Si el equipo es más innovador, la adopción será mucho más fácil porque el potencial y las nuevas puertas se multiplican con cada descubrimiento.

Dos problemas conceptuales principales que los programadores tuvieron al pasar a esta tecnología fueron: a) Correlación de mensajes y patrones de intercambio de mensajes b) Flujos de trabajo y pruebas unitarias En los sistemas estándar en C #, por ejemplo, un flujo de trabajo rara vez es explícito y, por lo tanto, rara vez se prueba unitariamente. El flujo de trabajo general se deja para probar por escenarios de aceptación o integración. Introduzca un WF explícito como un artefacto de software y, de repente, los desarrolladores estándar quieren probarlo y probarlo unitario, lo que generalmente no vale la pena.

El aspecto de correlación de mensajes es un cambio de mentalidad para aquellos que no están familiarizados con los patrones de intercambio de mensajes. La mayoría de los desarrolladores se han ocupado de llamadas en proceso y remotas, servicio web y SOAP, y generalmente se han centrado en uno o dos de ellos. Resumir sobre todo y trabajar con un sistema general basado en mensajes puede ser confuso al principio.

Sin embargo, en el lado positivo, el resultado final es algo que ahorra mucho tiempo y crea muchas oportunidades. Una cosa principal es que el worfklow, si es visualmente claro, es algo en lo que el usuario final, el desarrollador y el analista pueden trabajar juntos, eliminando pasos innecesarios en el ciclo de vida del desarrollo y enfocando a las partes en un artefacto. Además, desalienta las islas de funcionalidad en aplicaciones dedicadas, con capas de pegamento dedicadas, al alentar un conjunto de procesos empresariales en WF por dominio empresarial. Además, con AppFabric, la plomería para la persistencia, el registro y el despertar de las actividades programadas se hace por usted. El rendimiento de WF4 también es sobresaliente.

Mi recomendación sería encontrar al miembro del equipo más innovador o exploratorio que realice la exploración inicial para descubrir las partes difíciles, hacer que funcionen las funciones básicas y que esa persona inicial sea responsable de compartimentar el trabajo restante.

Centinela
fuente
5

Para hacer un sistema de reclamo de seguro de cualquier complejidad que implique roles y "subtareas", realmente necesita una solución BPM, no solo un flujo de trabajo. Workflow Foundation 4.0 es elegante, pero realmente no se acerca a las funcionalidades de un producto BPM.

Las soluciones BPM, como Metastorm BPM, Global360 y K2.NET, proporcionan flujo de trabajo centrado en el ser humano, tareas, roles e integración de sistemas que pueden modelar y agilizar los procesos comerciales como su sistema de reclamos de seguros. Use ASP.NET para construir la interfaz que se integra con el motor de flujo de trabajo BPM ya que sus diseñadores incorporados generalmente son limitados y lo obligan a usar su control web personalizado que generalmente no tiene todas las funciones que los controles web ASP.NET.

Stephen Cao
fuente
¿Qué pasa con el uso de WF 4.0 con actividades personalizadas?
John Saunders
3
Respetuosamente no estoy de acuerdo. K2 agrega una capa de funcionalidad (como autorización, bloqueo e informes) a WF, pero un equipo experimentado podría desarrollar esas características. WF 4 trae mucho a la mesa. Las soluciones BPM tienden a ser caras y "empresariales".
TrueWill
4

Vaya con la tecnología que su equipo conoce y con la que se siente cómodo. Workflow Foundation no es un producto que pueda usar de inmediato, es más bien un conjunto de piezas que puede incrustar en su aplicación para crear un sistema de flujo de trabajo. En mi humilde opinión, la lógica del flujo de trabajo es la pieza de tecnología menos importante, antes que nada debes concentrarte en la GUI porque los dueños de negocios no verán nada más que la GUI. Pero si su sistema es un éxito, entonces debe estar preparado para solicitudes de cambio interminables y nuevos requisitos, por lo que debe implementar su lógica comercial para que sea fácil de cambiar y dividir en procesos separados para satisfacer las diferentes necesidades de los usuarios (a veces contradictorio) . BPM ayuda en esta tarea porque le permite tener versiones separadas y múltiples de procesos comerciales que se adaptan a diversas necesidades comerciales. Usted no No necesito un motor BPM completo para eso, pero es útil codificar la lógica de su negocio para que pueda ser versionado y dividido en procesos comerciales individuales; lo peor es tener un blob de código no entrelazado e entrelazado que maneje 'todo' y que no Uno puede entender. Hay muchas ideas para eso: máquinas de estado, DSL (lenguajes específicos de dominio), scripts, etc., usted decide cuál debe ser la implementación. Pero siempre debe pensar en términos de procesos comerciales y organizar su lógica en consecuencia para que refleje estos procesos. Y prepárese para la coexistencia de muchas variantes de lógica empresarial y estructuras de datos: esta es la tarea de diseño más difícil en mi humilde opinión. Es útil para codificar su lógica de negocios para que pueda ser versionada y dividida en procesos de negocios individuales. Lo peor que tiene es un blob de código no entrelazado e entrelazado que maneja 'todo' y que nadie puede entender. Hay muchas ideas para eso: máquinas de estado, DSL (lenguajes específicos de dominio), scripts, etc., usted decide cuál debe ser la implementación. Pero siempre debe pensar en términos de procesos comerciales y organizar su lógica en consecuencia para que refleje estos procesos. Y prepárese para la coexistencia de muchas variantes de lógica empresarial y estructuras de datos: esta es la tarea de diseño más difícil en mi humilde opinión. Es útil para codificar su lógica de negocios para que pueda ser versionada y dividida en procesos de negocios individuales. Lo peor que tiene es un blob de código no entrelazado e entrelazado que maneja 'todo' y que nadie puede entender. Hay muchas ideas para eso: máquinas de estado, DSL (lenguajes específicos de dominio), scripts, etc., usted decide cuál debe ser la implementación. Pero siempre debe pensar en términos de procesos comerciales y organizar su lógica en consecuencia para que refleje estos procesos. Y prepárese para la coexistencia de muchas variantes de lógica empresarial y estructuras de datos: esta es la tarea de diseño más difícil en mi humilde opinión. DSL (lenguajes específicos de dominio), scripts, etc., usted decide cuál debe ser la implementación. Pero siempre debe pensar en términos de procesos comerciales y organizar su lógica en consecuencia para que refleje estos procesos. Y prepárese para la coexistencia de muchas variantes de lógica empresarial y estructuras de datos: esta es la tarea de diseño más difícil en mi humilde opinión. DSL (lenguajes específicos de dominio), scripts, etc., usted decide cuál debe ser la implementación. Pero siempre debe pensar en términos de procesos comerciales y organizar su lógica en consecuencia para que refleje estos procesos. Y prepárese para la coexistencia de muchas variantes de lógica empresarial y estructuras de datos: esta es la tarea de diseño más difícil en mi humilde opinión.

Vision nocturna
fuente
3

Estoy en una situación en la que tengo que usar 4.0 ya que .NET 4.5 aún no está acreditado para usar en nuestro entorno de producción. En general, me dolía mucho entender cómo lograr que los flujos de trabajo de larga duración se adaptaran a las necesidades de nuestro negocio, pero finalmente encontré una solución elegante. No es algo que cualquiera que llegue más tarde a apoyar pueda entender con facilidad porque hay mucho en qué pensar, pero sí creo en WF como una herramienta para administrar los estados de flujo de trabajo.

Sin embargo, una gran cosa que no estoy de acuerdo con WF 4.0 es el comentario de Maurice:

Lo básico es nunca cambiar un flujo de trabajo existente, siempre crear uno nuevo

Eso es genial si solo quieres una nueva versión, pero ¿qué pasa si tienes 50,000 flujos de trabajo persistentes y te das cuenta en algún momento de que hay un error en el flujo de trabajo? Debe poder actualizar el xamlx y aún estar acoplado a las instancias existentes. Intenté descomprimir las diversas columnas de metadatos en la tabla de instancias de SQL Server para encontrar algo que vincule la instancia con la definición del flujo de trabajo sin suerte.

Escribí una aplicación de sincronización para importar datos de un sistema antiguo a nuestro nuevo WF 4.0. Básicamente, cargamos los datos en el sistema, luego ejecutamos el proceso que lleva automáticamente a los pasos del flujo de trabajo y llama a los métodos de validación, esencialmente burlándose de la interacción del usuario. Esto realmente funcionó bien con nosotros debido a la arquitectura que implementamos para acceder al host del servicio de flujo de trabajo. Es excelente, ya que después de ejecutarlo puede realizar y realizar comprobaciones para garantizar la coherencia del proceso de migración de datos, pero tener que usar este enfoque para potencialmente cientos de miles de casos una vez que un sistema está activo no es realmente un enfoque que infunde confianza y sobrecarga el proceso de integración de correcciones de errores simples.

Mi recomendación es que evite WF 4.0 por completo y solo vaya directamente a 4.5 si su entorno lo admite. Las actualizaciones dinámicas y las versiones de lado a lado proporcionan soluciones para la corrección de errores y el control de versiones de WF de forma inmediata. Todavía tengo que investigar exactamente cómo 4.5 aún no está acreditado para su uso por parte de nuestro cliente, pero espero ansiosamente esta oportunidad.

Lo que espero desesperadamente es que nuestro cliente no solicite cambios en la política (y, por lo tanto, ajustes en el flujo de trabajo) y que los flujos de trabajo actuales se mantengan sin errores. Esta última es una esperanza vana y vacía, ya que los errores siempre aparecen.

Realmente no puedo entender lo que estaba pasando por las cabezas del equipo de desarrollo de WF para lanzar un sistema en el que no se pueden solucionar los errores fácilmente. Deberían haber desarrollado una técnica para volver a vincular una instancia al nuevo xamlx.

Stephen York
fuente