Cas d'utilisation du moteur de flux de travail
j'aimerais connaître les problèmes spécifiques que vous - le lecteur - avez résolus en utilisant les moteurs de flux de travail et les bibliothèques/cadres que vous avez utilisés si vous ne roulez pas le vôtre. J'aimerais aussi savoir quand un moteur de flux de travail n'était pas le meilleur choix et si/comment vous avez choisi quelque chose de plus simple, comme une application de type Liste des tâches/Liste de travail/Gestion des tâches utilisant des machines d'état.
Questions:
- quels problèmes Avez-vous utilisé les moteurs de flux de travail pour résoudre?
- quelles bibliothèques / structures avez-vous utilisées?
- quand une gestion plus simple de la Machine D'état/des tâches comme le système a-t-elle suffi?
- Bonus: Comment faire la distinction entre gestion des tâches et moteur de flux de travail ?
je cherche des expériences de première main.
Certaines des ressources que j'ai vérifié:
6 réponses
je suis aussi biaisé que l'auteur principal de StonePath .
j'ai développé des applications de flux de travail pour le département D'état des États-Unis, le centre de Genève pour le déminage humanitaire, 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 a essayé d'être la référence principale pour les processus d'affaires, j'ai vu une organisation se battant pour travailler autour outil. Cela peut être dû au fait que ces solutions ont toujours été axées sur les fournisseurs/produits, et se retrouvent ensuite avec une équipe tactique de "consultants" alimentant constamment l'application... mais à cause de cela, j'ai tendance à réagir négativement quand j'entends les avantages des outils basés sur les processus qui promettent de "centraliser les définitions de flux de travail dans un endroit et les rendre reproductibles".
cela dit, j'aime beaucoup Ruote - j'ai suivi ce projet depuis un certain temps et 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é aux Rails, le cadre web écrit en Ruby. Où Ruote est sur les processus d'affaires de longue durée et leurs définitions associées, StonePath est sur la gestion de flux de travail basé sur L'état et la tâche. Franchement, je pense que la distinction de l'extérieur regardant dans pourrait être subtile - beaucoup de fois le même genre d'affaires les processus peuvent être représentés d'une manière ou d'une autre - 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 saillants 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. 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 patron vous demande toutes les quelques heures un statut mise à jour, et voulait une brève réponse... vous diriez des choses comme"c'est dans la saisie de données"... "Nous vérifions les références du candidat maintenant"... "nous attendons l'examen de la qualité"... "On a fini"... et ainsi de suite. Ce sont les états dans un flux de travail basé sur l'état. Nous passons de l'état à l'état, via des transitions comme "approuver", "appliquer", rebond", "refuser", et ainsi de suite. ceux-ci tendent à être des verbes d'action. Ce genre de choses sont modélisées tout le temps dans le Logiciel comme une machine d'état.
le suivant la création de tâches fait partie d'un workflow basé sur un État ou une tâche. 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 de renouvellement de passeport, par exemple), à un utilisateur "dans la boîte". Les tâches peuvent se produire en parallèle les uns avec les autres ou séquentiellement, et nous pouvons créer des tâches automatiquement lorsque nous entrons dans les États, créer des tâches manuellement que les gens se rendent compte des besoins de travail à faire, et exiger des tâches être complet avant que nous pouvons passer à une nouvelle état. Tout ce type de comportement est optionnel, et fait partie de la définition du flux de travail.
Le trou du lapin peut aller beaucoup plus profond que cela, et j'ai écrit un article à ce sujet dans le Numéro 4 de PragPub, la Pragmatique du Programmeur Magazine. Consultez le lien reo ci-dessus pour une mise à jour PDF de cet article.
en travaillant avec StonePath ces derniers mois, j'ai découvert 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 se présentent bien comme des ressources imbriquées. Attendez-vous à ce que je vous écrive 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 flux de travail interprétant les définitions de flux de travail
maintenant votre question est étiquetée "BPM" nous pouvons être élargis en " Business Processus de gestion". Comment ce type de gestion se produire dans chaque variante ?
Dans la variante 1, le processus d'affaires (ou de travail) est dispersé dans l'application. La machine d'état attachée à la ressource renforce certains aspects du workflow, mais seulement ceux liés à la ressource. Il peut y avoir d'autres ressources avec leur propre machine d'état suivant le même processus commercial.
dans la variante 2, le flux de travail 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 flux de travail est décrété en interprétant une ressource appelée définition du flux de travail (ou Définition des processus d'affaires).
Ce qui se passe lorsque le processus de gestion des changements ? Vaut-il la peine d'avoir un moteur de flux de travail où les processus d'affaires sont des ressources gérables ?
la plupart des bibliothèques de machines d'État ont 1 État + transitions. Les moteurs de flux de travail sont, la plupart d'entre eux, des interprètes de définition de flux de travail et ils permettent à plusieurs flux de travail différents de fonctionner 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 change l'état de plusieurs ressources dont certaines sont gardées par des machines d'état.
j'utilise aussi beaucoup la variante 3 + 2, pour les tâches humaines: le workflow moteur, à certains moments lors de l'exécution d'une instance de processus, passe une tâche (workitem) à un participant humain (la tâche de ressources est créée et placée dans l'état "prêt").
vous pouvez faire un long chemin avec la variante 2 seule (la variante de gestionnaire de tâches).
nous pourrions également mentionner la variante 0), où il n'y a pas de machine d'état, pas de moteur de flux de travail, et les processus d'affaires sont dispersés et/ou codés en dur dans l'application.
vous pouvez demander beaucoup des questions, mais si vous ne prenez pas le temps de lire les réponses et ne prennent pas le temps d'essayer et d'expérimenter, vous n'irez pas très loin, et ne sera jamais acquérir aucun talent pour l'utilisation de ce ou de l'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 l'industrie des soins de santé.
Formulaires ont besoin d'être remplis par l'utilisateur final , et selon certaines réponses, d'autres Formes ont été planifiées à pourvoir à une date ultérieure. Il y avait aussi des événements externes qui annulaient les formulaires prévus ou en établissaient de nouveaux.
Débit De Prélèvement:
Patient Admis - > Calendrier Formulaire D'Évaluation Initiale - > Annexe Formulaire D'Évaluation Trimestrielle - > Décès Du Patient - > Annulation De L'Évaluation -> Annexe Formulaire D'Évaluation Du Congé
beaucoup d'autres règles étaient basées sur des choses telles que l'âge du Patient, où ils étaient admis, etc.
C'était un ASP.NET app, les règles étaient essentiellement une table dans la base de données. J'ai ajouté le script, de sorte qu'un script s'exécuterait à la fin du formulaire pour déterminer ce qu'il faut faire ensuite. C'était une horrible conception, et aurait été parfait pour un bon moteur de flux de travail.
Vérifier rails_workflow gem - je pense que c'est proche de ce que vous chercher.
j'ai lancé mon propre moteur de flux de travail pour soutenir le traitement progressif des documents - catalogage, envoi pour le traitement d'image (nous travaillons avec redaction sw), si nécessaire l'envoi à la validation, puis la libération et enfin l'expédition de retour au client. Dans notre cas, nous avons un camion chargé de documents à traiter, donc parfois nous devons exécuter chaque service séparément pour contrôler la livraison et l'utilisation des ressources. Simple dans le concept, mais haute performance et le traitement distribué nécessaire, et nous ne pouvions pas trouver l'étagère des produits qui répondent à la loi pour nous.
j'ai une expérience avec l'utilisation de en Or BPMN 2.0 moteur pour le traitement à haut rendement et à haut débit de transfert de données de processus dans une infrastructure de réseau de nœuds. La tâche fondamentale était de permettre la configuration et le suivi de tels processus de transfert et de contrôler chaque nœud de réseau (c.-à-d.: demande node1 pour envoyer un fichier de données à node2 via spécifique de la couche de transport).
il pourrait y avoir des milliers de processus en cours à la fois et dans l'ensemble des dizaines ou des centaines de milliers de processus par jour.
il y avait plusieurs définitions de processus différentes, mais il n'était pas nécessaire qu'un opérateur du système puisse créer des workflows personnalisés. Ainsi, le cas d'utilisation principal du moteur BPM lui-même devait être robuste, évolutif et permettre la surveillance de chaque flux de processus.
en fin de compte, cela a essentiellement fonctionné, mais ce que nous avons appris de ce projet était qu'une plate-forme BPMN, ou plutôt les activités plus précisément, le moteur n'était pas le meilleur choix pour un système à haut rendement.
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 ne citer que quelques-uns, concernant le BPM lui-même. Nous avons donc dû développer la gestion sur mesure de ceux-ci, par exemple:
- manipulation des tentatives dans le BPM 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 en cours d'exécution du tout.
- Exécution de tâches de transfert en parallèle en un seul processus et synchronisation des résultats (succès/échec).
Je ne sais pas si d'autres moteurs BPMN seraient plus appropriés pour un tel scénario puisque BPMN est principalement destiné à des tâches d'affaires à long terme impliquant une interaction utilisateur où la performance n'est probablement pas la même question que dans notre cas.