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 de moteurs de flux de travail et les bibliothèques/frameworks que vous avez utilisés si vous ne le faites pas vous-même. J'aimerais également savoir quand un moteur de workflow n'est 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é?
- Quand une simple machine à états/gestion des tâches telle qu'un système est-elle suffisante?
- Bonus: Comment avez-vous/faites-vous la distinction entre Gestion des tâches et Workflow Engine ?
Je cherche des expériences de première main.
Certaines des ressources que j'ai vérifiées:
Je suis également biaisé 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 de Fortune 500 et, plus récemment, le système scolaire public de Washington DC. Chaque fois que j'ai vu un «moteur de flux de travail» qui essayait d'être la référence principale pour les processus métier, j'ai vu une organisation se battre pour contourner l'outil. Cela s'explique peut-être par le fait que ces solutions ont toujours été axées sur les fournisseurs et les produits, puis se retrouvent avec une équipe tactique de "consultants" qui alimentent constamment l'application ... mais de ce fait, j'ai tendance à réagir négativement lorsque j'entends le message. 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 reproductibles».
Cela dit, j'aime beaucoup Ruote. Je suis ce projet depuis un certain temps et si j'ai besoin de ce type de solution, ce sera le prochain outil que je serai prêt à essayer. StonePath a un objectif très différent de ruote - où Ruote est utile à Ruby en général, StonePath s’adresse à Rails, le framework Web écrit en Ruby. Là où Ruote traite de processus métier à long terme et de leurs définitions associées, StonePath traite de la gestion des flux de travail et des tâches en fonction des états. Franchement, je pense que la distinction de l'extérieur peut être subtile - plusieurs fois, le même type de processus métier peut être représenté dans les deux sens - le modèle basé sur des tâches et des états tend à correspondre à mon modèle mental.
Permettez-moi de décrire les points forts d'un flux de travail basé sur des états. 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. Lorsque le document se déplace «autour du bureau», il se déplace d’un État à l’autre. Imaginez si vous êtes responsable du document et que votre supérieur hiérarchique vous demandait toutes les quelques heures une mise à jour de statut et souhaitait une réponse brève ... vous diriez des choses comme "C'est dans la saisie de données" ... "Nous vérifions les références du demandeur maintenant "..." nous attendons l'évaluation de la qualité "..." nous avons terminé "... et ainsi de suite. Ce sont les états d'un flux de travail basé sur les états. Nous passons d'un état à l'autre par des transitions - comme "approuver", "appliquer", "kickback" "," nier ", etc., ce sont en général des verbes d'action. Ce genre de logiciel est constamment modelé dans un logiciel comme une machine à états. .
La prochaine partie d'un workflow basé sur un état/une tâche 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 connecte un élément de travail (la demande de prêt ou le renouvellement du passeport, par exemple), à un utilisateur "dans la boîte". Les tâches peuvent se dérouler en parallèle ou séquentiellement, et nous pouvons créer des tâches automatiquement lorsque nous entrons dans des états, créer manuellement des tâches lorsque les personnes réalisent que leur travail doit être effectué et qu'elles nécessitent d'être terminées avant de pouvoir passer à un nouvel état. Tout ce type de comportement est facultatif et fait partie de la définition du flux de travail.
Le trou de lapin peut aller beaucoup plus loin que cela, et j'ai écrit un article à ce sujet dans le n ° 4 de PragPub, le magazine du programmateur pragmatique. Consultez le lien ci-dessus pour une mise à jour PDF de cet article.
En travaillant avec StonePath ces 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 parfaitement aux 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 à états rattachée à une ressource (document, commande, facture, livre, meuble).
variante 2) machine à états attachée à une ressource virtuelle nommée tâche
variante 3) moteur de workflow interprétant les définitions de workflow
Maintenant que votre question est étiquetée "BPM", nous pouvons être étendus à "Gestion des processus métier". Comment ce type de gestion se produit-il dans chacune des variantes?
Dans la variante 1, le processus technique (ou workflow) est dispersé dans l'application. La machine à états attachée à la ressource applique certains des 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 technique.
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 flux de travail est activé en interprétant une ressource appelée définition de flux de travail (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 flux de travail où les processus métiers constituent des ressources gérables?
La plupart des bibliothèques de machines à états ont 1 jeu d'états + transitions. Les moteurs de flux de travail sont, pour la plupart, des interpréteurs de définition de flux de travail et permettent l'exécution simultanée de plusieurs flux de travail différents.
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 dans lesquels un moteur de flux de travail modifie l'état de plusieurs ressources, dont certaines sont protégées par des machines d'état.
J'utilise également beaucoup la variante 3 + 2, pour les tâches manuelles: le moteur de workflow, lors de l'exécution d'une instance de processus, remet une tâche (élément de travail) à un participant humain (la tâche de ressource est créée et placée à l'état "prêt") .
Vous pouvez aller loin avec la variante 2 seule (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 où le ou les processus métier sont dispersés et/ou codés en dur dans l'application.
Vous pouvez poser beaucoup de questions, mais si vous ne prenez pas le temps de lire les réponses et ne prenez pas le temps d'essayer et d'expérimenter, vous n'irez pas très loin et n'acquerrez jamais le flair pour savoir quand utiliser tel ou tel outil.
Sur un projet précédent sur lequel je travaillais, j'ai ajouté des règles de type 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, il était prévu que d'autres formulaires soient remplis à une date ultérieure. Il y avait aussi des événements externes qui annulaient les formulaires programmés ou en programmaient de nouveaux.
Flux d'échantillon:
Patient admis -> Calendrier d'évaluation initiale -> Formulaire de révision trimestrielle -> Patient décédé -> Annuler la révision -> Formulaire d'évaluation du congé de sortie
De nombreuses autres règles étaient basées sur des facteurs tels que l'âge du patient, le lieu de son admission, etc.
Il s’agissait d’une application ASP.NET, les règles étant essentiellement une table dans la base de données. J'ai ajouté des scripts, de sorte qu'un script s'exécute à la fin du formulaire pour déterminer la prochaine étape. Cette conception était horrible et aurait été parfaite pour un moteur de flux de travail approprié.
Vérifiez Flux de travail Rails gem - Je pense que cela est proche de ce que vous recherchez.
Je suis l’un des auteurs de Cadence Workflow Engine que nous avons mis au point chez Uber. La différence entre Cadence et la majorité des moteurs de flux de travail existants réside dans le fait qu’il est axé sur les développeurs, extrêmement flexible et évolutif (jusqu'à des dizaines de milliers de mises à jour par seconde et 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 thread 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? La cadence est utilisée pour pratiquement toute application dorsale qui vit au-delà d’une seule réponse à une demande. Exemples d'utilisation:
- Emplois CRON distribués
- Gestion des pipelines ML/Data
- Réagir à des événements professionnels. Par exemple, les événements de voyage chez Uber. Le flux de travail peut accumuler l'état en fonction des événements reçus et exécuter des activités si nécessaire.
- Déploiement de services sur Mesos/Kubernetes
- Mise en œuvre du pipeline CI
- S'assurer que plusieurs appels de service se terminent lorsqu'une demande est reçue. Y compris SAGA implémentation du motif
- Gestion des tâches utilisateur (similaire à Amazon MTurk )
- Traitement des médias
- Routage des tickets du support 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 sur Cadence. Pratiquement tous les langages de spécification de flux de travaux de moteur existants peuvent être portés pour s'exécuter sur Cadence. Plusieurs systèmes Uber internes ont été portés. De cette manière, un seul service principal peut alimenter plusieurs systèmes de flux de travail spécifiques à un domaine.
Quelles bibliothèques/frameworks avez-vous utilisé?
Cadence est un service autonome écrit en Go avec les bibliothèques côté client Go et Java . La seule dépendance externe est le stockage. Les bases de données Cassandra et SQL sont prises en charge.
La cadence prend également en charge la réplication asynchrone entre régions (utilisant la terminologie AWS).
Quand une simple machine à états/gestion des tâches telle qu'un système est-elle suffisante?
Dans Uber, le service Cadence est géré par notre équipe. Par conséquent, la surcharge liée à la création de toute gestion de machine/tâche d'état personnalisée est toujours supérieure à l'utilisation de Cadence. En dehors de l'entreprise, le service et le stockage correspondant doivent être configurés. Si vous avez déjà une base de données SQL, le déploiement du service est simple grâce à une image de menu fixe. Le menu fixe est également utilisé pour exécuter un service Cadence local pour le développement sur un ordinateur personnel ou un ordinateur portable.
J'ai lancé mon propre moteur de workflow pour prendre en charge le traitement progressif des documents - catalogage, envoi pour traitement des images (nous travaillons avec redaction sw), envoi si nécessaire pour validation, puis validation et envoi final au client. Dans notre cas, nous avons un tas de documents à traiter, nous devons donc parfois exécuter chaque service séparément pour contrôler la livraison et l'utilisation des ressources. Concept simple mais haute performance et traitement distribué nécessaires, et nous n'avons trouvé aucun produit sur étagère qui corresponde à nos besoins.
Je suis l'un des auteurs de Imixs-Workflow . Imixs-Workflow est un moteur de flux de travail open source basé sur BPMN 2.0 et entièrement intégré à 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é les moteurs de workflow pour résoudre?
Lorsque j'ai commencé à réfléchir aux moteurs de flux de travail, mon objectif personnel était d'éviter de coder de manière irréversible la logique métier au sein de mon application. De nombreuses choses dans une application métier peuvent être réutilisées, il est donc logique de les garder configurables. Par exemple:
- l'envoi d'une notification
- voir les tâches ouvertes
- assigné une tâche à une personne
- décrivant la tâche en cours
Vous pouvez voir dans cette liste de fonctions que je parle de workflows centrés sur l'homme. En bref: un moteur de workflow centré sur l'humain répond aux questions suivantes: qui est responsable d'une tâche et qui doit être informé ensuite? Et ce sont les questions typiques des exigences de l'entreprise.
> Quelles bibliothèques/frameworks avez-vous utilisés?
Il y a 5 ans, nous avons commencé à réimplémenter le moteur Imixs-Workflow en nous concentrant sur BPMN 2. . BPMN est le standard commun pour la modélisation de processus. Et ce qui m'a le plus étonné, c'est que nous avons soudainement été en mesure de décrire des processus métier extrêmement complexes pouvant être visualisés et exécutés. Je recommande à tout le monde d'utiliser BPMN pour modéliser les processus métier.
> Quand une simple machine à états/gestion des tâches telle qu'un système a-t-elle suffi?
Une simple machine à états suffit si vous voulez juste suivre le statut d'un objet métier. C'est le cas lorsque vous commencez à introduire l'attribut 'status' dans votre modèle d'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/faites-vous la distinction entre la gestion des tâches et le moteur de workflow?
C’est précisément le point où diffèrent de nombreux moteurs de flux de travail mentionnés ici. Pour un flux de travail centré sur l'humain, vous avez généralement besoin d'une gestion de 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 déjà utilisé le moteur Activiti BPMN 2.0 pour gérer des processus de transfert de données hautes performances et à haut débit dans une infrastructure de nœuds de réseau. La tâche de base consistait à permettre la configuration et la surveillance de tels processus de transfert et à contrôler chaque nœud du réseau (c.-à-d. Demander au nœud 1 d'envoyer un fichier de données au nœud 2 via une couche de transport spécifique).
Il peut y avoir des milliers de processus exécutés à la fois et globalement des dizaines ou des centaines de milliers de processus par jour.
Il y avait un grand nombre 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. Ainsi, le principal cas d'utilisation du moteur BPM lui-même était d'être robuste, évolutif et de permettre la surveillance de chaque flux de processus.
En fin de compte, cela a fonctionné, mais nous avons appris de ce projet que la plate-forme BPMN, ou plutôt le moteur Activiti, n’était pas le meilleur choix pour un système aussi performant.
Les principaux défis étaient la hiérarchisation des tâches, le verrouillage de la base de données, les tentatives d'exécution pour en nommer quelques-unes concernant le MPM lui-même. Nous avons donc dû développer un traitement personnalisé de ceux-ci, par exemple:
- Traitement des tentatives dans le MPM pour les cas où un noeud n'avait pas de travailleur libre pour une tâche donnée ou quand le noeud n'était pas du tout en cours d'exécution.
- 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 à ce type de scénario, car BPMN est principalement destiné aux tâches métier de longue durée impliquant une interaction utilisateur où les performances ne sont probablement pas le même problème que dans notre cas.