c# - tutorial - ¿Flujo de trabajo o no flujo de trabajo?

.net framework 4.5 tutorial (9)

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

Un ejemplo del dominio comercial es el siguiente: un titular de póliza llama al centro de contacto para presentar un reclamo. Este "evento" dispara dos tareas secundarias que se accionan manualmente en paralelo y pueden tomar un tiempo prolongado en completarse;

Verifique el fraude del cliente: 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 cantidad de sub-estados (Verificación en progreso, Verificación de referencia fallida, Verificación de referencia aprobada, etc.)
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 que se va a arreglar. Desde aquí, la subtarea puede ingresar una cantidad de sub-estados (En espera de reparación, en curso, reparado, publicado, etc.). El reclamo solo puede continuar una vez que el estado de cada subtaja ha alcanzado un estado predefinido (según las reglas comerciales).

Aparentemente, en apariencia, Workflow es la mejor opción tecnológica; sin embargo, tengo algunas preocupaciones al usar WF 4.0.

Conjunto de habilidades: mirando el conjunto de habilidades promedio del desarrollador, no veo muchos desarrolladores que entiendan o conozcan Workflow.
Mantenibilidad: parece haber poco apoyo dentro de la comunidad para los proyectos de WF 4.0 y esto, junto con la falta de conjunto de habilidades, aumentan las preocupaciones sobre la mantenibilidad.
Barrera de entrada: tengo la sensación de que Windows Workflow tiene una curva de aprendizaje abrupta y no siempre es tan fácil de aprender.
Nuevo producto: como Workflow ha sido completamente reescrito para .NET 4.0, veo el producto como un producto de primera generación y es posible que no tenga la estabilidad necesaria.
Reputación: las versiones anteriores de Workflow no fueron bien recibidas, se consideraron difíciles de desarrollar y dieron lugar a una escasa aceptación comercial.

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

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

Mi experiencia con esto es que ofrece grandes dividendos y es muy agradable, pero los problemas surgen al principio porque no se aprecia adecuadamente que para muchos programadores esto sea un cambio de metodología más que un cambio tecnológico. 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 vinculados a su conjunto diario de OO y patrones, será difícil de introducir. Si el equipo es más innovador, entonces la adopción será mucho más fácil porque el potencial y las nuevas puertas se multiplican con cada descubrimiento.

Dos principales problemas conceptuales 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 sistemas estándar en C #, por ejemplo, un flujo de trabajo rara vez es explícito y, por lo tanto, rara vez se prueba en unidades. El flujo de trabajo general se deja para la prueba 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, lo que generalmente no vale la pena.

El aspecto de la 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 enfocado en una o dos de ellas. Resumir todo lo anterior 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 de desarrollo y enfocando a las partes en un artefacto. Además, desalienta las islas de funcionalidad en aplicaciones dedicadas, con capas de pegamento dedicadas, fomentando un conjunto de procesos de negocios en WF por dominio comercial. Además, con AppFabric, la plomería para la persistencia, el inicio de sesión y el despertar de las actividades programadas están hechas para usted. El rendimiento de WF4 también es sobresaliente.

Mi recomendación sería encontrar al miembro del equipo más innovador o explorador en la búsqueda inicial para descubrir las partes difíciles, lograr que funcionen las funciones principales y hacer que esa persona inicial sea responsable de dividir en compartimentos el trabajo restante.

Estoy en una situación en la que tengo que usar 4.0 ya que .NET 4.5 aún no está acreditado para su uso en nuestro entorno de producción. Me dolió mucho entender que, en general, cómo hacer que los flujos de trabajo de larga duración se adapten a las necesidades de nuestra empresa, pero finalmente encontramos una solución elegante. No es algo que cualquier persona que venga a apoyar pueda simplemente retomar fácilmente porque hay mucho en qué pensar, pero sí creo en WF como una herramienta para administrar estados de flujo de trabajo.

Una gran cosa que tengo problema 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 ¿y 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 aun así 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 a la definición del flujo de trabajo sin suerte.

Escribí una aplicación de sincronización para importar datos desde un sistema antiguo a nuestro nuevo WF 4.0 impulsado. Básicamente, cargamos los datos en el sistema, luego ejecutamos el proceso que consiste en llamar automáticamente a los pasos del flujo de trabajo y llamar a los métodos de validación, esencialmente burlando la interacción del usuario. Esto solo funcionó muy bien con nosotros debido a la arquitectura que implementamos para acceder al host del servicio de flujo de trabajo. Es genial como único, donde después de ejecutar puede realizar comprobaciones para garantizar la coherencia del proceso de migración de datos, pero tener que utilizar este enfoque para potencialmente cientos de miles de casos una vez que el sistema está activo no es realmente un enfoque que infunde confianza y sobrecarga el proceso de integración de soluciones de errores simples.

Mi recomendación es que evites WF 4.0 por completo y solo vayas directamente a 4.5 si tu entorno lo admite. Las Actualizaciones dinámicas y las versiones paralelas que proporciona satisfacen la corrección de errores y las versiones de WF, todo listo de fábrica. Aún no he investigado exactamente cómo 4,5 aún no está acreditado para el uso de nuestro cliente, pero espera ansiosamente esta oportunidad.

Lo que estoy esperando 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, una vez instalado, no se pueden solucionar los errores fácilmente. Deberían haber desarrollado una técnica para volver a vincular una instancia a la nueva xamlx.

He llegado a este dilema un par de veces y había elegido no usar la base Work Flow. Algunas de las consideraciones (similares a la suya) fueron

Los flujos de trabajo involucrados fueron mucho más simples (una combinación de máquina de estados y acciones secuenciales) y hacerlo en WF parece exagerar en los esfuerzos involucrados.
La curva de aprendizaje para que los desarrolladores entiendan y usen WF de manera efectiva se consideró alta. La tabla de transición de estado que describe las transiciones y acciones válidas que deben tomarse se utilizan para brindar flexibilidad adicional y los desarrolladores se sienten cómodos con ella, entendiendo fácilmente el concepto y el propósito.
Las posibilidades de cambios en los procesos empresariales eran escasas y los cambios rudimentarios eran posibles con la ayuda de la tabla de transición. Un cambio en la transición significaría una secuencia de comandos de la base de datos, mientras que el cambio en las acciones daría lugar a 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. OMI, WF tiene sentido donde existe una gran probabilidad de que el flujo de trabajo pueda cambiar y / o las reglas de negocio puedan cambiar. WF permite aislar el flujo de trabajo en un archivo separado, por lo que será más sencillo configurarlo por los usuarios.

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

En cuanto a sus preocupaciones, tiene razón. Básicamente, WF4 es un producto nuevo y carece de algunas características importantes y tiene algunas asperezas. Hay una curva de aprendizaje, tienes que hacer algunas cosas de manera diferente. El punto principal es la ejecución prolongada 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 la gente tiene problemas para serializar el contexto de datos del marco de entidades.

La mayoría de las veces, el uso de servicios de flujo de trabajo alojados en IIS / WAS es la mejor ruta al realizar este tipo de flujos de trabajo de ejecución larga. Eso hace que tampoco sea difícil resolver el problema de las versiones, solo haga que el primer mensaje devuelva la versión del flujo de trabajo y la haga parte de cada mensaje subsiguiente. A continuación, coloque el enrutador WCF que enruta el mensaje al punto final correcto según la versión. Lo básico nunca es cambiar un flujo de trabajo existente, siempre crea uno nuevo.

Entonces, ¿cuál es mi consejo para ti? No se arriesgue demasiado con una tecnología desconocida y, para usted, no probada. Haga una pequeña porción de la aplicación que no sea crítica usando WF4. De esta forma, si funciona, puede ampliarlo pero, si falla, puede arrancarlo y reemplazarlo con un código .NET más tradicional. De esta forma, obtendrá experiencia real con WF4 en lugar de tener que basar su decisión en información de segunda mano y aprenderá una nueva y poderosa tecnología en el proceso. Si es posible, tome un curso en WF4, ya que le ahorrará mucho tiempo para ponerse al día (en este caso, descafeinado).

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

Hemos estado usando WF 4.0 en los últimos meses. Debo decir que es un reto pensar en el modo Workflow. Sin embargo, puedo decir que vale la pena. Sabíamos muy poco cuando comenzamos. Hemos comprado un libro para principiantes y profesional para WF 4.0 que ayudó. Yo mismo, miré muchos videos en línea y seguí PDC 2009 por sus últimas noticias sobre WF 4.0 y cómo es diferente de las versiones anteriores algo sucky. Una cosa importante a la que tuvimos que proponer una solución es la forma en que podemos tratar 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. He encontrado una buena solución para eso, y la experiencia de flujo de trabajo que tenemos hasta ahora no está nada mal. En realidad, tenemos una aplicación que hace un uso intensivo del flujo de trabajo que cada vez se hace más grande y realmente no me puedo imaginar a mí mismo resolviéndola en un entorno diferente. Me encanta el efecto visual que tiene: me aleja de los detalles de las construcciones if / else etc. y hace que las reglas de negocio aparezcan de una manera que no lo obligue a sumergirse en las líneas de código para saber qué está pasando o cómo arreglar un 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 nueva tecnología y tiene que aportar algunas ideas innovadoras.

mis 2 centavos ...

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

Aún 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 solo WF de sus requisitos e intente implementarlo en WF 4.0. Pasarás un tiempo con él, pero probarás si puedes hacerlo en WF 4.0 y si hay algún beneficio visible.

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

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

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

Parece que tu equipo está centrado en c #, por lo que quizás mis pensamientos no se apliquen. Dirijo una empresa de tecnología con bastantes empleados y nos encontramos con la misma necesidad. A diferencia de muchos otros negocios, teníamos muchos desarrolladores a nuestra disposición, por lo que una solución de flujo de trabajo basada en código era ideal.

El problema es que no tenemos muchos recursos para la configuración / mantenimiento del sistema y los costos de licencia, a menos que sea bastante importante para nuestro negocio. El flujo de trabajo de Azure / Window estaba fuera de discusión. También probamos bastantes de las grandes suites de BPM que existen y tuvimos más problemas: te ofrecen una experiencia de programación visual bastante frívola. La programación simplemente no se puede completar en un entorno visual. Puede ver la lista de software que no es BPM que realmente nos interesaba. Herramientas como Decisions.com e IFTTT son geniales. De hecho, las decisiones pueden ser una buena opción para usted, ya que se integra con los productos de Microsoft tal como lo entiendo.

El final de la historia es que lanzamos nuestro propio software como una aventura empresarial, y para uso interno. Los flujos de trabajo pueden escribirse e integrarse con cualquier API, así como también procesos humanos directamente con formularios. Por ejemplo, estamos integrando flujos de trabajo para incorporar nuevos desarrolladores que extraen / actualizan muchos otros programas. Es bastante verde pero extremadamente potente en escenarios de flujo de trabajo. Puedes pagar con Nebri aquí. Dado que el enfoque basado en reglas dispara a los eventos, la arquitectura es bastante diferente. Reduce la cantidad de código que tiene que escribir y tiene una compensación de velocidad. Pero puede manejar cosas como el complex-event-processing fácilmente ya que Python está a su disposición.

Vaya con la tecnología que su equipo conoce y con la que se siente cómodo. Workflow Foundation no es un producto que puede usar de inmediato, sino más bien un conjunto de piezas que puede incorporar en su aplicación para construir un sistema de flujo de trabajo. En mi humilde opinión, la lógica del flujo de trabajo es la parte menos importante de la tecnología, antes que nada hay que concentrarse en la GUI porque los dueños de negocios no verán nada más que la GUI. Pero si su sistema es exitoso, 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 fácil de dividir en procesos separados para satisfacer las diferentes necesidades del usuario (a veces contradictorias) . BPM ayuda en esta tarea porque le permite tener distintas versiones de procesos comerciales que satisfacen varias necesidades comerciales. No es necesario un motor BPM completo para eso, pero es útil codificar la lógica de su negocio para que pueda ser versionada y dividida en procesos de negocios individuales; lo peor es un bloque de código intangible e interconectado que maneja ''todo'' y que nadie puede entender Hay muchas ideas para eso: máquinas de estado, DSL (idiomas específicos del 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.