Cas d'utilisation du moteur de workflow

J'aimerais connaître les problèmes spécifiques que vous - le lecteur SO - avez résolus à l'aide des moteurs de flux de travail et les bibliothèques / cadres que vous avez utilisés si vous ne lancez pas les vôtres. J'aimerais également savoir quand un moteur de workflow n'était pas le meilleur choix et si / comment vous avez choisi quelque chose de plus simple, comme une application de type TaskList / WorkList / Task-Management utilisant des machines à états.

Des questions:

• Quels problèmes avez-vous utilisé les moteurs de workflow pour résoudre?
• Quelles bibliothèques / frameworks avez-vous utilisés?
• Quand un système plus simple de State Machine / Task Management comme le système est-il suffisant?
• Bonus: Comment avez-vous fait / faites-vous la distinction entre la gestion des tâches et le moteur de workflow ?

Je recherche des expériences de première main.

Certaines des ressources que j'ai consultées:

• Ruote et State Machine! = Moteur de workflow
• StonePath et Docs
• Création et gestion de plans de tâches de réserve de travail avec Oracle
• Conception et mise en œuvre d'un moteur de workflow - Thèse
• Pour quoi utiliser Windows Workflow Foundation
• Documents JBoss jBPM

Je suis également partial, car je suis l'auteur principal de StonePath .

J'ai développé des applications de flux de travail pour le Département d'État américain, le Centre de déminage humanitaire de Genève, plusieurs clients Fortune 500 et, plus récemment, le Washington DC Public School System. Chaque fois que j'ai vu un «moteur de flux de travail» qui tentait d'être la seule référence principale pour les processus métier, j'ai vu une organisation se battre pour contourner l'outil. Cela peut être dû au fait que ces solutions ont toujours été axées sur les fournisseurs / produits, puis se retrouvent avec une équipe tactique de `` consultants '' alimentant constamment l'application ... mais à cause de cela, j'ai tendance à réagir négativement lorsque j'entends le avantages des outils basés sur les processus qui promettent de «centraliser les définitions de flux de travail en un seul endroit et de les rendre répétables».

Cela dit, j'aime beaucoup Ruote - je suis ce projet depuis un certain temps et si j'ai besoin de ce genre de solution, ce sera le prochain outil que je serai prêt à essayer. StonePath a un but très différent de ruote - où Ruote est utile à Ruby en général, StonePath est destiné à Rails, le framework web écrit en Ruby. Là où Ruote concerne les processus métier à longue durée de vie et leurs définitions associées, StonePath concerne la gestion des flux de travail et des tâches basés sur l'état. Franchement, je pense que la distinction avec le regard extérieur peut être subtile - souvent, les mêmes types de processus métier peuvent être représentés de toute façon - le modèle basé sur l'état et les tâches a tendance à correspondre à mon modèle mental.

Permettez-moi de décrire les points forts d'un flux de travail basé sur l'état. En bref, imaginez un flux de travail tournant autour du traitement de quelque chose comme un prêt hypothécaire ou un renouvellement de passeport. Au fur et à mesure que le document se déplace «dans le bureau», il voyage d'un État à l'autre. Imaginez si vous êtes responsable du document et que votre patron vous demande toutes les quelques heures une mise à jour du statut et veut une brève réponse ... vous diriez des choses comme "Il est dans la saisie de données" ... "Nous vérifions les informations d'identification du candidat maintenant "..." nous attendons un examen de la qualité "..." Nous avons terminé "... et ainsi de suite. Ce sont les états dans un workflow basé sur l'état. Nous passons d'un état à l'autre via des transitions - comme "approuver", "appliquer", rebondir "," refuser ", etc., ce sont généralement des verbes d'action.

La partie suivante d'un flux de travail basé sur l'état / les tâches est la création de tâches. Une tâche est une unité de travail, généralement avec une date d'échéance et des instructions de traitement, qui relie un élément de travail (la demande de prêt ou le renouvellement de passeport, par exemple), à ​​un utilisateur «en boîte». Les tâches peuvent se dérouler en parallèle les unes avec les autres ou de manière séquentielle, et nous pouvons créer des tâches automatiquement lorsque nous entrons dans des états, créer des tâches manuellement lorsque les gens réalisent que le travail doit être fait et exiger que les tâches soient terminées avant de pouvoir passer à un nouvel état. Tout ce type de comportement est facultatif et fait partie de la définition du workflow.

Le terrier du lapin peut aller beaucoup plus loin que cela, et j'ai écrit un article à ce sujet pour le numéro 4 de PragPub, le magazine du programmeur pragmatique. Consultez le lien reo ci-dessus pour un PDF mis à jour de cet article.

En travaillant avec StonePath au cours des derniers mois, j'ai constaté que le modèle basé sur l'état correspond très bien aux architectures Web reposantes - en particulier, les tâches et les transitions d'état correspondent bien en tant que ressources imbriquées. Attendez-vous à voir de futurs écrits de ma part sur ce sujet.

Je suis partial, je suis l'un des auteurs de ruote .

variante 1) machine d'état attachée à une ressource (document, commande, facture, livre, meuble).

variante 2) machine à états attachée à une ressource virtuelle nommée une tâche

variante 3) moteur de workflow interprétant les définitions de workflow

Maintenant, votre question est étiquetée "BPM", nous pouvons être étendue à "Gestion des processus d'affaires". Comment ce genre de gestion se produit-il dans chacune des variantes?

Dans la variante 1, le processus métier (ou workflow) est dispersé dans l'application. La machine à états attachée à la ressource applique certains aspects du flux de travail, mais uniquement ceux liés à la ressource. Il peut y avoir d'autres ressources avec leur propre machine d'état suivant le même processus métier.

Dans la variante 2, le workflow peut être concentré autour de la ressource de tâche et représenté par la machine à états autour de cette ressource.

Dans la variante 3, le workflow est exécuté en interprétant une ressource appelée définition de workflow (ou définition de processus métier).

Que se passe-t-il lorsque le processus métier change? Vaut-il la peine d'avoir un moteur de workflow où les processus métier sont des ressources gérables?

La plupart des bibliothèques de machines d'état ont 1 ensemble d'états + transitions. Les moteurs de workflow sont, pour la plupart, des interpréteurs de définition de workflow et ils permettent à plusieurs workflows différents de s'exécuter ensemble.

Quel sera le coût de la modification du flux de travail?

Les variantes ne sont pas mutuellement exclusives. J'ai vu de nombreux exemples où un moteur de flux de travail modifie l'état de plusieurs ressources dont certaines sont gardées par des machines à états.

J'utilise également beaucoup la variante 3 + 2, pour les tâches humaines: le moteur de flux de travail, à certains moments lors de l'exécution d'une instance de processus, confie une tâche (élément de travail) à un participant humain (la tâche de ressource est créée et placée dans l'état `` prêt '') .

Vous pouvez aller très loin avec la variante 2 seule (la variante du gestionnaire de tâches).

Nous pourrions également mentionner la variante 0), où il n'y a pas de machine à états, pas de moteur de workflow, et le ou les processus métier sont dispersés et / ou codés en dur dans l'application.

Vous pouvez poser de nombreuses questions, mais si vous ne prenez pas le temps de lire les réponses et que vous ne prenez pas le temps d'essayer et d'expérimenter, vous n'irez pas très loin et n'acquérirez jamais le flair pour quand utiliser tel ou tel outil.

Sur un projet précédent sur lequel je travaillais, j'ai ajouté des règles de type de flux de travail à un ensemble de formulaires gouvernementaux dans le secteur des soins de santé.

Les formulaires devaient être remplis par l'utilisateur final et, en fonction de certaines réponses, d'autres formulaires devaient être remplis à une date ultérieure. Il y avait aussi des événements externes qui annulaient les formulaires programmés ou en planifiaient de nouveaux.

Échantillon de flux:

Patient admis -> Planifier le programme d'évaluation initiale -> Planifier le formulaire d'examen trimestriel -> Patient décédé -> Annuler l'examen -> Planifier le formulaire d'évaluation du congé

De nombreuses autres règles étaient basées sur des éléments tels que l'âge du patient, l'endroit où il était admis, etc.

C'était une application ASP.NET, les règles étaient essentiellement une table dans la base de données. J'ai ajouté un script, donc un script s'exécuterait à la fin du formulaire pour déterminer ce qu'il fallait faire ensuite. C'était un design horrible, et aurait été parfait pour un moteur de workflow approprié.

Je suis l'un des auteurs de Cadence Workflow Engine que nous avons développé chez Uber. La différence entre Cadence et la majorité des moteurs de flux de travail existants est qu'il est axé sur les développeurs et extrêmement flexible et évolutif (jusqu'à des dizaines de milliers de mises à jour par seconde et jusqu'à des milliards de flux de travail ouverts). Les flux de travail sont écrits en tant que programmes orientés objet et le moteur garantit que l'état des objets de flux de travail, y compris les piles de threads et les variables locales, est entièrement préservé en cas de défaillance de l'hôte.

Quels problèmes avez-vous utilisé les moteurs de workflow pour résoudre? Cadence est utilisé pour pratiquement toutes les applications backend qui ne se limitent pas à une seule demande de réponse. Des exemples d'utilisation sont:

• Emplois CRON distribués
• Gestion des pipelines ML / Data
• Réagir aux événements commerciaux. Par exemple, les événements de voyage chez Uber. Le workflow peut accumuler des états en fonction des événements reçus et exécuter des activités si nécessaire.
• Déploiement de services sur Mesos / Kubernetes
• Implémentation CI Pipeline
• S'assurer que plusieurs appels de service se terminent lorsqu'une demande est reçue. Y compris la mise en œuvre du modèle SAGA
• Gestion des tâches des utilisateurs humains (similaire à Amazon MTurk )
• Traitement des médias
• Acheminement des tickets d'assistance client
• Commande en cours de traitement
• Service de test similaire à ChaosMonkey

et plein d'autres

L'autre ensemble de cas d'utilisation est basé sur le portage des moteurs de flux de travail existants pour qu'ils s'exécutent sur Cadence. Pratiquement n'importe quel langage de spécification de flux de travail de moteur existant peut être porté pour s'exécuter sur Cadence. Plusieurs systèmes Uber internes ont été portés. De cette façon, un seul service de backend peut alimenter plusieurs systèmes de flux de travail spécifiques à un domaine.

Quelles bibliothèques / frameworks avez-vous utilisés?

Cadence est un service autonome écrit dans les bibliothèques côté client Go with Go et Java . La seule dépendance externe est le stockage. Les bases de données Cassandra et SQL sont prises en charge.

Cadence prend également en charge la réplication interrégionale asynchrone (à l'aide de la terminologie AWS).

Quand un système plus simple de State Machine / Task Management comme le système est-il suffisant?

À l'intérieur d'Uber, le service Cadence est géré par notre équipe. Ainsi, les frais généraux liés à la création de toute machine à états personnalisée / gestion des tâches sont toujours plus élevés que l'utilisation de Cadence. En dehors de l'entreprise, le service et le stockage doivent être mis en place. Si vous disposez déjà d'une base de données SQL, le déploiement du service est simple via une image docker. Le docker est également utilisé pour exécuter un service Cadence local pour le développement sur un ordinateur personnel ou un ordinateur portable.

Vérifiez la gemme rails_workflow - Je pense que c'est proche de ce que vous recherchez.

Je suis l'un des auteurs d' Imixs-Workflow . Imixs-Workflow est un moteur de flux de travail open source basé sur BPMN 2.0 et entièrement intégré dans la pile technologique Java EE.
Je développe moi-même des moteurs de workflow depuis plus de 10 ans. Je vais essayer de répondre à votre question en bref:

> Quels problèmes avez-vous utilisé des moteurs de workflow pour résoudre?

Mon objectif personnel lorsque j'ai commencé à penser aux moteurs de workflow était d'éviter de coder en dur la logique métier dans mon application. De nombreux éléments d'une application métier peuvent être réutilisés, il est donc logique de les garder configurables. Par exemple:

• envoyer une notification
• afficher les tâches ouvertes
• assigné une tâche à une personne
• décrivant la tâche en cours

À partir de cette liste de fonctions, vous pouvez voir que je parle de flux de travail centrés sur l'humain. En bref: un moteur de flux de travail centré sur l'humain répond aux questions: qui est responsable d'une tâche et qui doit ensuite être informé? Et ce sont les questions typiques des exigences commerciales.

> Quelles bibliothèques / frameworks avez-vous utilisés?

Il y a 5 ans, nous avons commencé à réimplémenter le moteur Imixs-Workflow en se concentrant sur BPMN 2.0 . BPMN est la norme commune pour la modélisation de processus. Et la chose surprenante pour moi était que nous avons soudainement pu décrire des processus métier, même très complexes, qui pouvaient être visualisés et exécutés. Je recommande à tout le monde d'utiliser BPMN pour modéliser les processus métier.

> Quand est-ce qu'un système plus simple de State Machine / Task Management comme le système est suffisant?

Une simple machine à états suffit si vous souhaitez simplement suivre l'état d'un objet métier. C'est le cas lorsque vous commencez à introduire l'attribut 'status' dans votre modèle objet. Mais si vous avez besoin de processus métier avec des responsabilités, une journalisation et un contrôle de flux, une machine à états ne suffit plus.

> Bonus: Comment avez-vous fait / faites-vous la distinction entre la gestion des tâches et le moteur de workflow?

C'est exactement le point où de nombreux moteurs de flux de travail mentionnés ici diffèrent. Pour un flux de travail centré sur l'humain, vous avez généralement besoin d'une gestion des tâches pour répartir les tâches entre les acteurs humains. Pour une automatisation de processus, ce point n'est pas si pertinent. Il suffit que le moteur effectue certaines tâches. La gestion des tâches et les moteurs de workflow ne peuvent pas être comparés car la gestion des tâches est toujours une fonction d'un moteur de workflow.

J'ai mis en place mon propre moteur de workflow pour prendre en charge le traitement par étapes des documents - catalogage, envoi pour traitement d'image (nous travaillons avec rédaction sw), si nécessaire envoi à la validation, puis libération et enfin retour au client. Dans notre cas, nous avons un camion de documents à traiter, nous devons donc parfois exécuter chaque service séparément pour contrôler la livraison et l'utilisation des ressources. Un concept simple, mais des performances élevées et un traitement distribué sont nécessaires, et nous n'avons pas pu trouver de produit disponible dans le commerce qui nous convenait.

J'ai une expérience de l'utilisation du moteur Activiti BPMN 2.0 pour gérer des processus de transfert de données haute performance et haut débit dans une infrastructure de nœuds de réseau. La tâche de base était de permettre la configuration et la surveillance de ces processus de transfert et de contrôler chaque nœud du réseau (c'est-à-dire demander au nœud1 d'envoyer un fichier de données au nœud2 via une couche de transport spécifique).

Il peut y avoir des milliers de processus en cours d'exécution à la fois et des dizaines ou des centaines de milliers de processus par jour.

Il y avait un tas de définitions de processus différentes, mais il n'était pas nécessairement nécessaire qu'un opérateur du système puisse créer des flux de travail personnalisés. Le principal cas d'utilisation du moteur BPM lui-même était donc d'être robuste, évolutif et de permettre la surveillance de chaque flux de processus.

En fin de compte, cela a fonctionné, mais ce que nous avons appris de ce projet, c'est qu'une plate-forme BPMN, ou plutôt le moteur Activiti en particulier, n'était pas le meilleur pari pour un système aussi haut débit.

Les principaux défis étaient la priorisation de l'exécution des tâches, le verrouillage de la base de données, les tentatives d'exécution pour n'en nommer que quelques-unes concernant le BPM lui-même. Nous avons donc dû développer une gestion personnalisée de ceux-ci, par exemple:

• Gestion des tentatives dans le BPM pour les cas où un nœud n'avait pas de worker libre pour une tâche donnée, ou lorsque le nœud ne fonctionnait pas du tout.
• Exécution de tâches de transfert parallèles en un seul processus et synchronisation des résultats (succès / échec).

Je ne sais pas si d'autres moteurs BPMN conviendraient mieux à un tel scénario puisque BPMN est principalement destiné aux tâches commerciales de longue durée impliquant une interaction utilisateur où les performances ne sont probablement pas le même problème que dans notre cas.