Cas d’utilisation du moteur de workflow

J’aimerais connaître les problèmes spécifiques que vous – le lecteur SO – avez résolus en utilisant Workflow Engines et les bibliothèques / frameworks que vous avez utilisés si vous ne les avez pas générés. Je voudrais aussi 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 d’état.

Des questions:

  • Quels problèmes avez-vous utilisés avec les moteurs de workflow pour résoudre?
  • Quelles bibliothèques / frameworks avez-vous utilisés?
  • Quand un système simple comme State Machine / Task Management a-t-il suffi?
  • Bonus: Comment faites-vous la distinction entre Task Management et Workflow Engine ?

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

Certaines des ressources que j’ai consultées:

  • Ruote and 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 implémentation d’un moteur de workflow – Thèse
  • Quoi utiliser Windows Workflow Foundation For
  • JBoss JBPM Docs

Je suis aussi partial que je suis l’auteur principal de StonePath .

J’ai développé des applications de workflow pour le département d’État américain, le centre de Genève pour le déminage humanitaire, plusieurs clients de la fortune 500 et, plus récemment, le système des écoles publiques de Washington DC. Chaque fois que j’ai vu un «moteur de workflow» qui essayait d’être la référence unique des processus métier, j’ai vu une organisation se battre pour contourner l’outil. Cela est peut-être dû au fait que ces solutions ont toujours été pilotées par le fournisseur / produit, puis à une équipe tactique de «consultants» alimentant constamment l’application… mais à cause de cela, j’ai tendance à réagir négativement les avantages des outils basés sur les processus qui promettent de «centraliser les définitions de workflow au même endroit et de les rendre reproductibles».

Cela dit, j’aime beaucoup Ruote – j’ai suivi ce projet pendant un certain temps et si j’avais besoin de ce type de solution, ce serait le prochain outil que je serais prêt à essayer. StonePath a un objective 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. Lorsque Ruote traite de processus métier à long terme et de leurs définitions associées, StonePath concerne la gestion des stream de travail et des tâches basés sur l’état. Franchement, je pense que la distinction de l’extérieur peut être subtile – plusieurs fois, les mêmes types de processus métier peuvent être représentés d’une manière ou d’une autre – le modèle basé sur l’état et la tâche a tendance à correspondre à mon modèle mental.

Permettez-moi de décrire les points forts d’un workflow basé sur l’état. En bref, imaginez un stream de travail axé sur le traitement de quelque chose comme un prêt hypothécaire ou un renouvellement de passeport. Lorsque le document se déplace «dans le bureau», il se déplace d’un état à l’autre. Imaginez que vous soyez responsable du document et que votre patron vous demande toutes les deux ou trois heures une mise à jour du statut et que vous souhaitiez une réponse brève … vous diriez des choses comme “Il est dans la saisie de données” … les lettres de créance du demandeur maintenant “…” nous attendons l’examen de la qualité “…” Nous avons terminé “… et ainsi de suite. Ce sont les états d’un workflow basé sur un état. Nous passons d’un état à l’autre via des transitions – comme “Approuver”, “Appliquer”, “Rétro”, “Refuser”, etc. Ce sont souvent des verbes d’action. .

La partie suivante d’un workflow basé sur l’état / 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 parallèlement ou séquentiellement, et nous pouvons créer des tâches automatiquement lorsque nous entrons dans des états, créer des tâches manuellement au fur et à mesure que les utilisateurs réalisent que les tâches doivent être accomplies avant de pouvoir passer à un nouvel état. Tout ce type de comportement est facultatif et fait partie de la définition du stream de travail.

Le terrier de 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 de Pragmatic Programmer. 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 mappe vraiment bien avec les architectures Web reposantes – en particulier, les transitions d’état et de tâches correspondent bien à des ressources nestedes. Attendez-vous à voir l’écriture future de moi 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 d’état 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 étendus dans “Business Process Management”. Comment se passe ce type de gestion dans chacune des variantes?

Dans la variante 1, le processus métier (ou workflow) est dispersé dans l’application. La machine d’état attachée à la ressource applique certains aspects du workflow, mais uniquement ceux liés à la ressource. Il peut y avoir d’autres ressources avec leur propre machine d’état après 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 d’état 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? Est-ce que cela vaut 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 à états comportent 1 états définis + transitions. Les moteurs de workflow sont pour la plupart des interpréteurs de définition de workflow et permettent à plusieurs stream de travail différents de fonctionner ensemble.

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

Les variantes ne s’excluent pas mutuellement. J’ai vu beaucoup d’exemples où un moteur de workflow modifie l’état de plusieurs ressources dont certaines sont protégées par des machines d’état.

J’utilise aussi beaucoup la variante 3 + 2 pour les tâches humaines: le moteur de workflow, à certains moments lors de l’exécution d’une instance de processus, confie une tâche (workitem) à un participant humain (la tâche de ressource est créée et prête) .

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

Nous pourrions également mentionner la variante 0), où il n’ya pas de machine à états, pas de moteur de workflow et où 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 que vous ne prenez pas le temps d’essayer et d’expérimenter, vous n’irez pas très loin et n’acquerrez jamais de 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 Workflow à 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 ultérieurement. Il y avait également des événements externes qui annulaient les formulaires planifiés ou en programmaient de nouveaux.

Flux d’échantillon:

Patient admis -> Planification initiale de l’évaluation FOrm -> Formulaire de révision sortingmessortingelle -> Patient décédé -> Annuler l’examen -> Formulaire d’évaluation de la libération

Beaucoup d’autres règles étaient basées sur des éléments tels que l’âge du patient, l’endroit où ils étaient admis, etc.

C’était une application ASP.NET, les règles étaient essentiellement une table dans la firebase database. J’ai ajouté des scripts, de sorte qu’un script s’exécute sur l’achèvement du formulaire pour déterminer ce qu’il faut faire ensuite. C’était un design horrible, et aurait été parfait pour un moteur de workflow approprié.

Vérifiez rails_workflow gem – je pense que c’est proche de ce que vous cherchez.

J’ai déployé mon propre moteur de workflow pour prendre en charge le traitement par étapes des documents – catalogage, envoi pour traitement d’image (nous travaillons avec redaction sw), si nécessaire, envoi à la validation, puis relâchement et enfin renvoi au client. Dans notre cas, nous avons un tas de documents à traiter, de sorte que nous devons parfois exécuter chaque service séparément pour contrôler la livraison et l’utilisation des ressources. Concept simple mais hautes performances et traitement dissortingbué nécessaire, et nous ne trouvions aucun produit disponible sur le marché pour nous.

J’ai une expérience de l’utilisation du moteur Activiti BPMN 2.0 pour gérer des processus de transfert de données à haut débit 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 de réseau (par exemple, demander à node1 d’envoyer un fichier de données au nœud2 via une couche de transport spécifique).

Il pourrait y avoir des milliers de processus exécutés à la fois et des dizaines ou des centaines de milliers de processus par jour.

Il y avait beaucoup de définitions de processus différentes, mais il n’était pas nécessairement nécessaire qu’un opérateur du système crée des stream de travail personnalisés. Le principal cas d’utilisation du moteur BPM était donc d’être robuste, évolutif et de surveiller chaque stream de processus.

Au bout du compte, cela a fonctionné, mais ce que nous avons appris de ce projet était qu’une plateforme BPMN, ou plutôt le moteur Activiti, n’était pas le meilleur choix pour un système aussi haut débit.

Les principaux défis étaient la hiérarchisation de l’exécution des tâches, le locking de la firebase database, les tentatives d’exécution pour nommer les quelques-unes concernant le MPM lui-même. Nous avons donc dû développer une gestion personnalisée de ceux-ci, par exemple:

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

Je ne sais pas si d’autres moteurs BPMN seraient plus adaptés à ce type de scénario, car BPMN est principalement destiné à des tâches professionnelles de longue durée impliquant une interaction de l’utilisateur lorsque les performances ne sont probablement pas les mêmes que dans notre cas.