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

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?

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.

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.

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 ...

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.

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.

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.

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.

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.