Casos de uso del motor de flujo de trabajo

Question

Me gustaría saber sobre problemas específicos que usted, el lector de SO, resolvió utilizando los motores de flujo de trabajo y qué bibliotecas/marcos utilizó si no imprimiera 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 se han utilizado motores de flujo de trabajo para resolver?
• ¿Qué bibliotecas/frameworks usó?
• ¿Cuándo fue suficiente un sistema de gestión de tarea/máquina de estado más simple?
• Bonificación: ¿Cómo hizo/hace la distinción entre Task Management y Workflow Engine?

Estoy buscando experiencias de primera mano.

Algunos de los recursos que he comprobado a cabo:

• Ruote y State Machine != Workflow Engine
• StonePath y Docs
• Creating and Managing Worklist Task Plans with Oracle
• Design and Implementation of a Workflow Engine - Thesis
• What to use Windows Workflow Foundation For
• JBoss jBPM Docs

Answer 1

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 los beneficios de las herramientas basadas en procesos que prometen 'centralizar las definiciones del flujo de trabajo en un 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, generalmente con fecha de vencimiento e instrucciones de manejo, que conecta un elemento de trabajo (la solicitud de préstamo o el pasaporte). renovación, por ejemplo), a los usuarios "en la caja". Las tareas pueden suceder en paralelo o de forma secuencial, y podemos crear tareas automáticamente cuando ingresamos estados, crear tareas manualmente a medida que las personas se dan cuenta de que el trabajo debe realizarse y requieren las tareas se completan 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 al respecto para el número 4 de PragPub, la revista del programador pragmático. Consulte el enlace de nuevo para obtener un PDF actualizado de ese artículo.

Al trabajar con StonePath en los últimos meses, he encontrado que el modelo basado en estado se corresponde muy bien con arquitecturas web relajadas; 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.

Answer 2

Implementé 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, liberación 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.

Answer 3

Soy imparcial, soy uno de los autores de ruote.

variante 1) máquina de estado conectada a un recurso (documento, orden, factura, libro, mueble).

variante de la máquina 2) estado unida a un recurso virtual denominado una tarea

variante 3) motor de flujo de trabajo de interpretación de las definiciones de flujo de trabajo

Ahora la pregunta es etiquetada "BPM" que se puede expandir en "Gestión de Procesos de Negocio ". ¿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 se puede concentrar alrededor del recurso de la tarea y representado 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 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 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 uso la variante 3 + 2 mucho, para tareas humanas: el motor de flujo de trabajo, en algunos puntos cuando ejecuta una instancia de proceso, entrega una tarea (elemento de trabajo) a un participante humano (la tarea de recursos se crea y 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 estados, ni motor de flujo de trabajo, y los procesos comerciales están dispersos y/o codificados en la aplicación.

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

Answer 4

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.

Muestra de flujo:

pacientes ingresados ​​-> Programación formulario de evaluación inicial - Murió> Paciente - -> Programación Trimestral Formato de Revisión> Cancelar revisión -> Programación de descarga Formulario de Evaluación

Muchas otras normas se basaron en las cosas como la edad del paciente, donde estaban siendo admitidos, 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.

Answer 5

Verificar rails_workflow joya - Creo que esto es parecido a lo que está buscando.

Answer 6

Tengo una experiencia con el uso del motor BPMN 2.0 Activiti 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).

Puede haber miles de procesos ejecutándose a la vez y decenas o cientos de miles de procesos por día.

Había muchas definiciones de proceso diferentes, pero no era necesario necesariamente 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 funcionó básicamente, 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 encargo de éstos, por ejemplo:

• Manejo de reintentos en el BPM para los casos cuando un nodo tenía ningún trabajador libre para determinada tarea, o cuando el nodo no estaba funcionando 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 este tipo de escenario ya que BPMN está destinado principalmente a tareas comerciales de larga duración que implican interacción del usuario donde el rendimiento probablemente no es el mismo problema que en nuestro caso.