Casos de uso del Motor de flujo de trabajo

Soy parcial, soy uno de los autores de ruote.

Variante 1) máquina de estado adjunta a un recurso (documento, pedido, factura, libro, mueble).

Variante 2) máquina de estados adjunta a un recurso virtual llamado tarea

Variante 3) motor de flujo de trabajo interpretación de definiciones de flujo de trabajo

Ahora su pregunta está etiquetada como "BPM", podemos expandirla a "Gestión de procesos de negocio". ¿Cómo ocurre 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 refuerza algunos de los aspectos del flujo de trabajo, pero solo los relacionados con el recurso. Puede haber otros recursos con su propia máquina de estado siguiendo el mismo proceso de negocio.

En la variante 2, el flujo de trabajo se puede concentrar alrededor del recurso de tarea y representar por la máquina de estados 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 el proceso de negocio cambia ? ¿Vale la pena tener un motor de flujo de trabajo donde los procesos de negocio sean recursos manejables ?

La mayoría de las bibliotecas de máquinas de estados tienen 1 estados establecidos + 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 diferentes se ejecuten juntos.

¿Cuál será el costo de cambiar el flujo de trabajo ?

Las variantes no son mutuamente excluyentes. He visto muchos ejemplos donde un motor de flujo de trabajo cambia el estado de múltiples recursos algunos de ellos custodiados por máquinas de estado.

También uso la variante 3 + 2 mucho, para tareas humanas : el motor de flujo de trabajo, en algunos puntos cuando se ejecuta 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 (el variante del administrador de tareas).

También podríamos mencionar la variante 0), donde no hay máquina de estado, no hay motor de flujo de trabajo y los procesos de negocio están dispersos y/o codificados en la aplicación.

Puede hacer muchas preguntas, pero si no se toma el tiempo para leer las respuestas y no se toma el tiempo para probar y experimentar, no irá muy lejos y nunca adquirirá ningún estilo para cuándo usar esta o aquella herramienta.

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 de la atención sanitaria.

Los formularios debían ser llenados por el usuario final , y dependiendo de algunas respuestas, otros Formularios estaban programados para ser llenados en una fecha posterior. También hubo eventos externos que cancelarían formularios programados o programarían otros nuevos.

Flujo de muestreo:

Paciente Ingresado - > Programar Formulario de Evaluación Inicial - > Programar Formulario de Revisión Trimestral -> Paciente Muerto -> Cancelar Revisión - > Programar el Alta Formulario de Evaluación

Muchas otras reglas se basaban en cosas como la edad del paciente, dónde estaban siendo ingresados, etc.

Esto fue un ASP.NET app, las reglas eran básicamente una tabla en la base de datos. Agregué scripting, por lo que un script se ejecutaría al completar el formulario para determinar qué hacer a continuación. Este fue un diseño horrible, y habría sido perfecto para un motor de flujo de trabajo adecuado.

Comprobar rails_workflow gema - Creo que esto es cerca de lo que busca.

Rodé mi propio motor de flujo de trabajo para soportar 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 un camión cargado de documentos que procesar, por lo que a veces necesitamos ejecutar cada servicio por separado para controlar la entrega y el uso de recursos. Simple en concepto pero alto rendimiento y procesamiento distribuido necesario, y no pudimos encontrar ninguno fuera de la producto de estante que se ajusta a la factura para nosotros.

Tengo experiencia con el uso del motor Activiti BPMN 2.0 para el manejo de 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 supervisión de tales procesos de transferencia y controlar cada nodo de red (es decir. solicitar node1 para enviar un archivo de datos al node2 a través de una capa de transporte específica).

Podría haber miles de procesos que se ejecutan a la vez y en general decenas o cientos de miles procesos por día.

Había muchas definiciones de procesos diferentes, pero no era necesario que un operador del sistema pudiera crear flujos de trabajo personalizados. Por lo tanto, el principal caso de uso para el motor BPM en sí 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 más bien el motor Activiti específicamente, no era la mejor apuesta para un rendimiento tan alto sistema.

Los principales desafíos fueron la priorización de la ejecución de tareas, el bloqueo de BD, los reintentos de ejecución, por nombrar algunos relacionados con el BPM en sí. 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 una tarea determinada, o cuando el nodo no se estaba ejecutando en absoluto.
• Ejecución de tareas de transferencia paralelas en un solo proceso y sincronización de los resultados (éxito/fracaso).

I no sé si otros motores BPMN serían más adecuados para este escenario, ya que BPMN está destinado principalmente a tareas comerciales de larga duración que involucran la interacción del usuario, donde el rendimiento probablemente no es el mismo problema que en nuestro caso.