Question

J'utilise WWF depuis un certain temps dans le cadre d'une application de centre d'appels interne (ASP.NET), et tout en apprenant, c'était une bonne pratique pour comprendre comment un système de flux de travail basé sur une machine à états devrait travail, je ne suis définitivement pas amoureux du WWF lui-même.A mon avis c'est :

  1. Trop complexe, en particulier pour une utilisation dans des applications Web (tout ce truc d'exécution threadé)
  2. Immature (avez-vous déjà travaillé avec cet horrible designer ?)
  3. Anémique dans son ensemble de fonctionnalités actuel

Quelqu'un a-t-il une suggestion pour un meilleur cadre de workflow basé sur .NET ?Plus précisément, je recherche les fonctionnalités suivantes :

  1. Basé sur une machine à états (mapping des états aux actions disponibles)
  2. Un accent sur les autorisations des utilisateurs (contrôler qui a accès à quelles actions)
  3. La possibilité d'exécuter des flux de travail sous forme de tâches en arrière-plan chronométrées (par exemple, pour envoyer des rappels pour des éléments qui sont restés dans un certain état pendant x jours)

C'est vraiment tout ce dont j'ai besoin.Je n'ai pas besoin de pouvoir « glisser-déposer » des activités ou de concevoir visuellement le flux.Je suis parfaitement à l'aise pour écrire du code réel une fois qu'une action particulière est déclenchée.

Était-ce utile?

La solution

Tu pourrais essayer Machine à états simple.Vous devrez mettre en œuvre vous-même le contrôle d’accès et les minuteries d’arrière-plan, mais cela ne devrait pas être un gros problème.SSM a également été construit à partir de la frustration suscitée par WF. Il existe d'autres implémentations de machines à états sur Codeplex aussi.Si l'un d'entre eux ne correspond pas à sa facture, ils sont open source et devraient vous rapprocher suffisamment.

Je suis entièrement d'accord avec vous à propos des machines à états dans WF - elles ne sont pas testables, sont trop compliquées, le modèle de thread est particulier et difficile à suivre, et je ne suis pas sûr qu'un concepteur visuel aurait pu être plus mal conçu pour concevoir des machines à états. graphiquement.Je pense que cela peut être dû au fait que le concept de machine à états semble lié au runtime WF, qui a été conçu pour les machines à états séquentielles, ce avec quoi WF fait un bien meilleur travail, à mon avis.Le problème est que les machines à états ne sont vraiment pas le même animal qu'un flux de travail séquentiel, et auraient dû bénéficier d'une implémentation de première classe, car la déformation de WF pour lui donner l'impression de les prendre en charge s'est avérée plus ou moins insupportable, voire inutilisable.

Autres conseils

Je resterais à l'écart de Drools.Net puisque son dernier commit SVN remonte à septembre 2007.Cela a l'air sympa, mais cela semble un peu trop risqué d'intégrer une si grande bibliothèque à votre projet quand vous savez qu'elle ne retient plus l'attention.

Essayez Drools.NET

Jettes un coup d'oeil à Moteur de flux de travail.Il s'agit d'un framework de workflow léger pour les solutions .NET et Java.Il dispose d'un concepteur visuel HTML5, d'un contrôle de version, d'une interface utilisateur décente et prend en charge un large éventail de bases de données.

Avez-vous la possibilité d’envisager BizTalk Server ?

J'ai beaucoup aimé travailler avec Oracle BPEL Process Manager.Cela fait partie de JDeveloper.

http://www.oracle.com/technology/bpel/index.html http://gemsres.com/story/dec06/313602/jellema-fig1.jpg

Vous voudrez peut-être jeter un oeil à Jazz - http://jazz.codeplex.com/

Essayez WF4.5.Il a été entièrement repensé depuis .NET4.0.

Tout d’abord, vous devez rechercher un moteur prenant en charge BPMN.BPMN est une norme en matière de gestion des flux de travail et des processus et est bien pris en charge par de nombreux projets.Deuxièmement, vous devriez réfléchir aux exigences d'un moteur.Lorsque vous recherchez un moteur BPMN, il existe deux approches différentes :

Orienté vers les tâches

Ces moteurs (par ex. JBoss BPM-jbpm) sont conçus pour traiter des données d'entrée par un modèle de processus bien défini.Chaque tâche du modèle donne le contrôle à un morceau de code - soit une implémentation standard ou individuelle.Le processus se termine lorsque le jeton de processus atteint la fin du modèle de processus (End-Event).Ce type de traitement prend quelques millisecondes.Le moteur peut être utilisé pour des tâches par lots ou pour traiter des données avec un flux orienté processus complexe.

Piloté par les événements

Les moteurs de workflow centrés sur l'humain sont pilotés par des événements (par ex. Imixs-Workflow).Il s’agit d’une sorte de machine à états mais offre généralement beaucoup plus de fonctionnalités.Vous pouvez démarrer une nouvelle instance de processus en attribuant à votre objet métier la tâche initiale (définie par l'événement de démarrage).Ensuite le moteur de workflow vous permet de déclencher des événements attribués à chaque tâche, définie dans votre modèle.Chaque événement (Intermediate CatchEvent) déclenche le moteur de workflow pour transférer l'instance de processus en cours d'exécution vers la tâche (état) suivante.Jusqu'à ce qu'aucun nouvel événement ne soit déclenché, l'instance de processus « attend » dans la tâche (état) en cours.Un processus d’approbation est un exemple typique de ce type de flux de travail centré sur l’humain.

Vous pouvez trouver une liste de moteurs ici.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top