bpm - Casos de uso del motor de flujo de trabajo
state-machines task-management (6)
Me gustaría saber sobre problemas específicos que usted, el lector de SO, ha resuelto utilizando los motores de flujo de trabajo y las bibliotecas / marcos que utilizó si no hubiera hecho los suyos propios. También me gustaría saber cuándo un Workflow Engine no era la mejor opción y si / cómo elegiste algo más simple, como una aplicación de tipo TaskList / WorkList / Task-Management que utiliza máquinas de estado.
Preguntas:
- ¿Qué problemas ha usado para resolver los motores de flujo de trabajo?
- ¿Qué bibliotecas / frameworks usaste?
- ¿Cuándo fue suficiente un sistema más simple de State Machine / Task Management?
- Bono: ¿Cómo hizo / hace la distinción entre Administración de tareas y Motor de flujo de trabajo ?
Estoy buscando experiencias de primera mano.
Algunos de los recursos que he comprobado:
Compruebe la gema rails_workflow : creo que esto es rails_workflow a lo que está buscando.
En un proyecto anterior en el que estaba trabajando, agregué algunas reglas de tipo de flujo de trabajo a un conjunto de formularios gubernamentales en la industria Healhcare.
Los formularios deben ser completados por el usuario final, y dependiendo de algunas respuestas, se programó que se completen otros formularios en una fecha posterior. También hubo eventos externos que cancelarían Formularios programados o programarían otros nuevos.
Flujo de muestra:
Admitido por el paciente -> Formulario de evaluación inicial del cronograma -> Formulario de revisión trimestral del cronograma -> Paciente fallecido -> Cancelar revisión -> Programar formulario de evaluación de alta
Muchas otras reglas se basaban en cosas como la edad del paciente, en el que estaban siendo admitidas, etc.
Esta era una aplicación ASP.NET, las reglas eran básicamente una tabla en la base de datos. Agregué secuencias de comandos, por lo que una secuencia de comandos se ejecutará en la finalización del formulario para determinar qué hacer a continuación. Este fue un diseño horrible, y hubiera sido perfecto para un motor de flujo de trabajo adecuado.
Lancé mi propio motor de flujo de trabajo para admitir el procesamiento por fases de documentos: catalogación, envío para procesamiento de imágenes (trabajamos con redaction sw), si es necesario, envío a validación, luego lanzamiento y finalmente envío al cliente. En nuestro caso, tenemos una gran cantidad de documentos para procesar, por lo que a veces necesitamos ejecutar cada servicio por separado para controlar la entrega y el uso de los recursos. Sencillo en concepto, pero se necesita un alto rendimiento y un procesamiento distribuido, y no pudimos encontrar ningún producto estándar que se adecue a nosotros.
Soy parcial, soy uno de los autores de ruote .
variante 1) máquina de estado conectada a un recurso (documento, orden, factura, libro, mueble).
variante 2) máquina de estado conectada a un recurso virtual llamado tarea
variante 3) motor de flujo de trabajo que interpreta las definiciones del flujo de trabajo
Ahora que su pregunta está etiquetada como "BPM", podemos ampliarla a "Gestión de procesos comerciales". ¿Cómo se produce ese tipo de gestión en cada una de las variantes?
En la variante 1, el proceso de negocio (o flujo de trabajo) está disperso en la aplicación. La máquina de estados adjunta al recurso impone algunos de los aspectos del flujo de trabajo, pero solo aquellos relacionados con el recurso. Puede haber otros recursos con su propia máquina de estado siguiendo el mismo proceso comercial.
En la variante 2, el flujo de trabajo puede concentrarse alrededor del recurso de la tarea y representarse por la máquina de estado alrededor de ese recurso.
En la variante 3, el flujo de trabajo se implementa interpretando un recurso llamado definición de flujo de trabajo (o definición de proceso de negocio).
¿Qué sucede cuando cambia el proceso comercial? ¿Vale la pena tener un motor de flujo de trabajo donde los procesos de negocios son recursos manejables?
La mayoría de las bibliotecas de máquinas estatales tienen 1 conjunto de estados + transiciones. Los motores de flujo de trabajo son, la mayoría de ellos, intérpretes de definición de flujo de trabajo y permiten que múltiples flujos de trabajo se ejecuten juntos.
¿Cuál será el costo de cambiar el flujo de trabajo?
Las variantes no son mutuamente excluyentes. He visto muchos ejemplos en los que un motor de flujo de trabajo cambia el estado de múltiples recursos, algunos de ellos protegidos por máquinas de estado.
También utilizo mucho la variante 3 + 2 para tareas humanas: el motor de flujo de trabajo, en algunos momentos al ejecutar una instancia de proceso, entrega una tarea (workitem) a un participante humano (la tarea de recursos se crea y se coloca en estado ''listo'') .
Puede recorrer un largo camino con la variante 2 sola (la variante del administrador de tareas).
También podríamos mencionar la variante 0), donde no hay máquina de estado, motor de flujo de trabajo, y los procesos de negocios están dispersos y / o codificados en la aplicación.
Puedes hacer muchas preguntas, pero si no te tomas el tiempo para leer las respuestas y no te tomas el tiempo para probar y experimentar, no llegarás muy lejos, y nunca adquirirás ningún estilo para cuándo usarlas. esta o aquella herramienta.
También soy parcial, ya que soy el autor principal de StonePath .
He desarrollado aplicaciones de flujo de trabajo para el Departamento de Estado de EE. UU., El Centro de Desminado Humanitario de Ginebra, varios clientes de Fortune 500 y, más recientemente, el Sistema de Escuelas Públicas de Washington DC. Cada vez que he visto un ''motor de flujo de trabajo'' que intentó ser la referencia maestra para los procesos de negocios, he visto a una organización pelearse por sí misma para trabajar con la herramienta. Esto puede deberse al hecho de que estas soluciones siempre han sido dirigidas por proveedores / productos, y luego terminan con un equipo táctico de ''consultores'' que constantemente alimentan la aplicación ... pero debido a esto, tiendo a reaccionar negativamente cuando escucho el los beneficios de las herramientas basadas en procesos que prometen ''centralizar las definiciones del flujo de trabajo en un solo lugar y hacer que sean repetibles''.
Dicho esto, me gusta mucho Ruote: he estado siguiendo ese proyecto durante algún tiempo y si necesito ese tipo de solución, será la próxima herramienta que estaré dispuesto a probar. StonePath tiene un propósito muy diferente al de ruote, donde Ruote es útil para Ruby en general, StonePath apunta a Rails, el marco web escrito en Ruby. En los casos en que Ruote se trata de procesos comerciales de larga duración y sus definiciones asociadas, StonePath trata sobre la administración del flujo de trabajo y la tarea basados en el estado. Francamente, creo que la distinción desde el punto de vista externo podría ser sutil: muchas veces los mismos tipos de procesos de negocios pueden representarse de cualquier manera; sin embargo, el modelo basado en el estado y la tarea tiende a corresponder a mi modelo mental.
Permítanme describir los aspectos más destacados de un flujo de trabajo basado en estado. En resumen, imagine un flujo de trabajo que gira en torno al procesamiento de algo así como un préstamo hipotecario o una renovación de pasaporte. A medida que el documento se mueve ''alrededor de la oficina'', viaja de estado a estado. Imagínese si usted es responsable del documento, y su jefe le preguntó cada pocas horas por una actualización de estado, y quería una respuesta breve ... diría cosas como "Está en la entrada de datos" ... "Estamos comprobando las credenciales del solicitante ahora "..." estamos a la espera de una revisión de calidad "..." Hemos terminado "... y así sucesivamente. Estos son los estados en un flujo de trabajo basado en estado. Nos movemos de estado a estado a través de transiciones, como "aprobar", "aplicar", "retroceder", "denegar", etc., que tienden a ser verbos de acción. Cosas como esta se modelan todo el tiempo en software como máquina de estados .
La siguiente parte de un flujo de trabajo basado en estado / tarea es la creación de tareas. Una tarea es una unidad de trabajo, por lo general con una fecha de vencimiento y las instrucciones de manejo, que conecta un elemento de trabajo (la solicitud de préstamo o renovación de pasaporte, por ejemplo), a los usuarios "en la casilla". Las tareas pueden realizarse de forma paralela o secuencialmente, y podemos crear tareas automáticamente cuando ingresamos a los estados, crear tareas manualmente a medida que las personas se dan cuenta de que el trabajo debe realizarse y requieren que las tareas se completen antes de que podamos pasar a un nuevo estado. Todo este tipo de comportamiento es opcional y parte de la definición del flujo de trabajo.
El agujero del conejo puede ser mucho más profundo que esto, y escribí un artículo sobre el Issue # 4 de PragPub, la Pragmatic Programmer''s Magazine. Consulte el enlace de nuevo para obtener un PDF actualizado de ese artículo.
Al trabajar con StonePath en los últimos meses, he descubierto que el modelo basado en el estado se adapta muy bien a las arquitecturas web relajantes; en particular, las tareas y las transiciones de estado se relacionan muy bien como recursos anidados. Espere ver futuros escritos míos sobre este tema.
Tengo una experiencia con el uso del motor Activiti BPMN 2.0 para manejar procesos de transferencia de datos de alto rendimiento y alto rendimiento en una infraestructura de nodos de red. La tarea básica era permitir la configuración y la supervisión de dichos procesos de transferencia y controlar cada nodo de la red (es decir, solicitar al nodo 1 que envíe un archivo de datos al nodo 2 a través de una capa de transporte específica).
Podría haber miles de procesos en ejecución a la vez y en general decenas o cientos de miles de procesos por día.
Había muchas definiciones de procesos diferentes, pero no era necesariamente necesario que un operador del sistema pudiera crear flujos de trabajo personalizados. Por lo tanto, el principal caso de uso para el motor de BPM era ser robusto, escalable y permitir el monitoreo de cada flujo de proceso.
Al final, básicamente funcionó, pero lo que aprendimos de ese proyecto fue que una plataforma BPMN, o mejor dicho, el motor Activiti específicamente, no era la mejor opción para un sistema de tan alto rendimiento.
Los principales desafíos fueron la priorización de la ejecución de tareas, el bloqueo de DB, los reintentos de ejecución para nombrar unos pocos sobre el propio BPM. Así que tuvimos que desarrollar un manejo personalizado de estos, por ejemplo:
- Manejo de reintentos en el BPM para los casos en que un nodo no tenía un trabajador libre para la tarea determinada, o cuando el nodo no se estaba ejecutando en absoluto.
- Ejecución de tareas de transferencia paralela en un solo proceso y sincronización de los resultados (éxito / falla).
No sé si otros motores BPMN serían más adecuados para ese escenario, ya que BPMN está principalmente destinado a tareas comerciales de larga duración que involucran la interacción del usuario, donde el rendimiento probablemente no sea el mismo que en nuestro caso.