Casos de uso del motor de flujo de trabajo

90

Me gustaría saber sobre problemas específicos que usted, el lector de SO, ha resuelto usando Workflow Engines y qué bibliotecas / frameworks usó si no creó el suyo. También me gustaría saber cuándo un motor de flujo de trabajo no fue la mejor opción y si eligió algo más simple, como una aplicación de tipo TaskList / WorkList / Task-Management usando máquinas de estado.

Preguntas:

  • ¿Qué problemas ha utilizado los motores de flujo de trabajo para resolver?
  • ¿Qué bibliotecas / frameworks usaste?
  • ¿Cuándo fue suficiente un sistema más simple de máquina de estados / administración de tareas?
  • Bonificación: ¿Cómo hizo / hizo la distinción entre Gestión de tareas y Motor de flujo de trabajo ?

Busco experiencias de primera mano.

Algunos de los recursos que he revisado:

Lance Pollard
fuente

Respuestas:

61

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 trataba de ser la única referencia maestra para los procesos de negocio, he visto una organización luchando por trabajar alrededor de la herramienta. Esto puede deberse al hecho de que estas soluciones siempre han sido impulsadas por el proveedor / producto, y luego terminan con un equipo táctico de 'consultores' que alimentan constantemente la aplicación ... pero debido a esto, tiendo a reaccionar negativamente cuando escucho el Beneficios de las herramientas basadas en procesos que prometen 'centralizar las definiciones del flujo de trabajo en un solo lugar y hacerlas 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 está dirigido a Rails, el marco web escrito en Ruby. Mientras que Ruote trata sobre procesos comerciales de larga duración y sus definiciones asociadas, StonePath trata sobre la gestión del flujo de trabajo y las tareas basadas en el estado. Francamente, creo que la distinción desde el exterior mirando hacia adentro podría ser sutil, muchas veces los mismos tipos de procesos comerciales se pueden representar de cualquier manera, sin embargo, el modelo basado en el estado y la tarea tiende a correlacionarse con mi modelo mental.

Permítanme describir los aspectos más destacados de un flujo de trabajo basado en estados. En resumen, imagine un flujo de trabajo que gira en torno al procesamiento de algo como un préstamo hipotecario o la renovación de un pasaporte. A medida que el documento se mueve "por la oficina", viaja de un estado a otro. Imagínese si usted es el responsable del documento y su jefe le pide cada pocas horas una actualización de estado y quiere una respuesta breve ... diría cosas como "Está en la entrada de datos" ... "Estamos comprobando las credenciales del solicitante ahora "..." estamos esperando una revisión de calidad "..." Hemos terminado "... y así sucesivamente. Estos son los estados en un flujo de trabajo basado en estados. Nos movemos de un estado a otro a través de transiciones, como "aprobar", "aplicar", contragolpe "," negar ", etc. Estos tienden a ser verbos de acción.

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 una fecha de vencimiento e instrucciones de manejo, que conecta un elemento de trabajo (la solicitud de préstamo o la renovación del pasaporte, por ejemplo), con un usuario "en la casilla". Las tareas pueden suceder en paralelo entre sí o en secuencia, 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 requerir que las tareas se completen antes de que podamos pasar a un nuevo estado. Todo este tipo de comportamiento es opcional y forma parte de la definición del flujo de trabajo.

La madriguera del conejo puede ser mucho más profunda que esto, y escribí un artículo al respecto para el número 4 de PragPub, la revista Pragmatic Programmer's Magazine. Consulte el enlace reo anterior para obtener un PDF actualizado de ese artículo.

Al trabajar con StonePath durante los últimos meses, descubrí que el modelo basado en el estado se asigna muy bien a las arquitecturas web tranquilas, en particular, las tareas y las transiciones de estado se asignan muy bien como recursos anidados. Espere ver futuros escritos míos sobre este tema.

bokmann
fuente
2
¡increíble! Estoy ansioso por aprender más sobre las sutiles diferencias entre los motores de flujo de trabajo como ruote y los motores de estado / tarea como Stonepath, porque al no haberlo pasado antes, es difícil ver con qué empezar. He leído todo lo que pude encontrar sobre stonepath y ruote y un millón de otros documentos técnicos sobre BPM y flujos de trabajo, por lo que un conocimiento de "experiencia de primera mano" como este REALMENTE disminuirá la curva de inicio. gracias de nuevo.
Lance Pollard
31

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 estado adjunta a un recurso virtual llamado tarea

variante 3) motor de flujo de trabajo que interpreta las definiciones de flujo de trabajo

Ahora que su pregunta tiene la etiqueta "BPM", podemos ampliarla 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 empresarial (o flujo de trabajo) está disperso en la aplicación. La máquina de estado adjunta al recurso aplica 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 empresarial.

En la variante 2, el flujo de trabajo se puede concentrar en torno al recurso de la tarea y representarlo mediante la máquina de estado en torno a ese recurso.

En la variante 3, el flujo de trabajo se promulga interpretando un recurso llamado definición de flujo de trabajo (o definición de proceso empresarial).

¿Qué sucede cuando cambia el proceso empresarial? ¿Vale la pena tener un motor de flujo de trabajo donde los procesos comerciales sean recursos manejables?

La mayoría de las bibliotecas de máquinas de estado tienen 1 conjunto de estados + transiciones. Los motores de flujo de trabajo son, la mayoría de ellos, intérpretes de definiciones de flujo de trabajo y permiten que varios flujos de trabajo diferentes se ejecuten juntos.

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

Las variantes no se excluyen mutuamente. He visto muchos ejemplos en los que un motor de flujo de trabajo cambia el estado de varios 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 puntos cuando se ejecuta una instancia de proceso, entrega una tarea (elemento de trabajo) 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 solo (la variante del administrador de tareas).

También podríamos mencionar la variante 0), donde no hay máquina de estado, ni 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 llegará muy lejos y nunca adquirirá el don de cuándo usar esta o aquella herramienta.

jmettraux
fuente
muchas gracias por esta respuesta, está aclarando bastante las cosas. no existen suficientes distinciones para que el recién llegado obtenga una comprensión decente del modelado de flujo de trabajo formal para comenzar a jugar con el código; Parece que son todos los documentos técnicos de Java de finales de los 90. usted y David de Stonepath están comenzando a romper esa barrera mucho. algún día puede ser tan fácil como aprender rieles. Voy a empezar a jugar con la variante del administrador de tareas en unos días. Gracias.
Lance Pollard
el enlace parece estar muerto?
rogerdpack
el proyecto ahora está muerto
Jeshan Babooa
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 de la atención médica.

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

Flujo de muestra:

Paciente admitido -> Programar formulario de evaluación inicial -> Programar formulario de revisión trimestral -> Paciente fallecido -> Cancelar revisión -> Programar formulario de evaluación del alta

Muchas otras reglas se basaron en cosas como la edad del paciente, dónde estaban ingresados, 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 se ejecutaría una secuencia de comandos al completar el formulario para determinar qué hacer a continuación. Este era un diseño horrible y hubiera sido perfecto para un motor de flujo de trabajo adecuado.

Ben Dempsey
fuente
3

Soy uno de los autores de Cadence Workflow Engine que desarrollamos en Uber. La diferencia entre Cadence y la mayoría de los motores de flujo de trabajo existentes es que está enfocado en el desarrollador y es extremadamente flexible y escalable (a decenas de miles de actualizaciones por segundo y hasta miles de millones de flujos de trabajo abiertos). Los flujos de trabajo se escriben como programas orientados a objetos y el motor garantiza que el estado de los objetos del flujo de trabajo, incluidas las pilas de subprocesos y las variables locales, se conserve completamente en caso de fallas del host.

¿Qué problemas ha utilizado los motores de flujo de trabajo para resolver? La cadencia se usa para prácticamente cualquier aplicación de backend que viva más allá de una sola respuesta de solicitud. Ejemplos de uso son:

  • Empleos de CRON distribuido
  • Gestión de canalizaciones de datos / ML
  • Reaccionar ante eventos empresariales. Por ejemplo, eventos de viaje en Uber. El flujo de trabajo puede acumular estados en función de los eventos recibidos y ejecutar actividades cuando sea necesario.
  • Implementación de servicios en Mesos / Kubernetes
  • Implementación de CI Pipeline
  • Asegurarse de que se completen varias llamadas de servicio cuando se recibe una solicitud. Incluyendo la implementación del patrón SAGA
  • Gestión de tareas de trabajadores humanos (similar a Amazon MTurk )
  • Procesamiento de medios
  • Enrutamiento de tickets de soporte al cliente
  • Procesando orden
  • Servicio de prueba similar a ChaosMonkey

y muchos otros

El otro conjunto de casos de uso se basa en la adaptación de los motores de flujo de trabajo existentes para que se ejecuten en Cadence. Prácticamente cualquier lenguaje de especificación de flujo de trabajo de motor existente se puede portar para ejecutarse en Cadence. Hay varios sistemas internos de Uber que fueron portados. De esta manera, un solo servicio de backend puede impulsar múltiples sistemas de flujo de trabajo específicos de dominio.

¿Qué bibliotecas / frameworks usaste?

Cadence es un servicio autónomo escrito en Go with Go y Java las bibliotecas del lado del cliente . La única dependencia externa es el almacenamiento. Se admiten las bases de datos Cassandra y SQL.

La cadencia también admite la replicación asincrónica entre regiones (utilizando la terminología de AWS).

¿Cuándo fue suficiente un sistema más simple de máquina de estados / administración de tareas?

Dentro de Uber, nuestro equipo gestiona el servicio Cadence. Por lo tanto, la sobrecarga de construir cualquier máquina de estado personalizada / administración de tareas es siempre mayor que usar Cadence. Fuera de la empresa es necesario configurar el servicio y el almacenamiento. Si ya tiene una base de datos SQL, la implementación del servicio es trivial a través de una imagen de Docker. La ventana acoplable también se utiliza para ejecutar un servicio de cadencia local para el desarrollo en una computadora personal o portátil.

Maxim Fateev
fuente
2

Soy uno de los autores de Imixs-Workflow . Imixs-Workflow es un motor de flujo de trabajo de código abierto basado en BPMN 2.0 y totalmente integrado en la pila de tecnología Java EE.
Yo mismo desarrollo motores de flujo de trabajo desde hace más de 10 años. Intentaré responder brevemente a tu pregunta:

> ¿Qué problemas ha utilizado los motores de flujo de trabajo para resolver?

Mi objetivo personal cuando comencé a pensar en motores de flujo de trabajo era evitar codificar la lógica empresarial dentro de mi aplicación. Muchos elementos de una aplicación empresarial se pueden reutilizar, por lo que tiene sentido mantenerlos configurables. Por ejemplo:

  • enviando una notificación
  • ver tareas abiertas
  • asignado una tarea a una persona
  • describiendo la tarea actual

En esta lista de funciones, puede ver que estoy hablando de flujos de trabajo centrados en las personas. En resumen: un motor de flujo de trabajo centrado en las personas responde a las preguntas: ¿Quién es responsable de una tarea y quién debe ser informado a continuación? Y estas son las preguntas típicas de los requisitos empresariales.

> ¿Qué bibliotecas / frameworks usaste?

Hace 5 años comenzamos a reimplementar el motor Imixs-Workflow enfocándonos en BPMN 2.0 . BPMN es el estándar común para el modelado de procesos. Y lo que me sorprendió fue que de repente pudimos describir incluso procesos comerciales muy complejos que podían visualizarse y ejecutarse. Recomiendo a todos que utilicen BPMN para modelar procesos comerciales.

> ¿Cuándo fue suficiente un sistema más simple de máquina de estados / administración de tareas?

Una simple máquina de estado es suficiente si solo desea rastrear el estado de un objeto comercial. Este es el caso cuando comienza a introducir el atributo 'estado' en su modelo de objetos. Pero en caso de que necesite procesos comerciales con responsabilidades, registro y control de flujo, una máquina de estado ya no es suficiente.

> Bonificación: ¿Cómo hizo / hizo la distinción entre Gestión de tareas y Motor de flujo de trabajo?

Este es exactamente el punto en el que difieren muchos motores de flujo de trabajo mencionados aquí. Para un flujo de trabajo centrado en las personas, normalmente necesita una gestión de tareas para distribuir las tareas entre los actores humanos. Para una automatización de procesos, este punto no es tan relevante. Es suficiente si el motor realiza determinadas tareas. La gestión de tareas y los motores de flujo de trabajo no se pueden comparar porque la gestión de tareas siempre es una función de un motor de flujo de trabajo.

Ralph
fuente
1

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 software de redacción), si es necesario enviarlo a validación, luego liberarlo y finalmente enviarlo de regreso 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 recursos. Sencillo en concepto pero de alto rendimiento y procesamiento distribuido necesario, y no pudimos encontrar ningún producto listo para usar que se ajustara a nuestras necesidades.

Otávio Décio
fuente
1

Tengo una experiencia con el uso de Activiti motor 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 el seguimiento de dichos procesos de transferencia y controlar cada nodo de la red (es decir, solicitar al nodo1 que envíe un archivo de datos al nodo2 a través de una capa de transporte específica).

Podría haber miles de procesos ejecutándose a la vez y, en general, decenas o cientos de miles de procesos por día.

Había un montón de definiciones de procesos diferentes, pero no era necesariamente necesario que un operador del sistema pudiera crear flujos de trabajo personalizados. Entonces, el caso de uso principal 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 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 la base de datos, 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 casos en los que un nodo no tenía trabajador libre para una 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 / fracaso).

No sé si otros motores BPMN serían más adecuados para tal 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 sea el mismo problema que en nuestro caso.

Adam Hošek
fuente