Frage

Ich verwende WWF seit einiger Zeit als Teil einer internen Callcenter-Anwendung (ASP.NET) und während ich lernte, war es eine gute Übung, um zu verstehen, wie ein auf Zustandsautomaten basierendes Workflow-System funktioniert sollen Arbeit, ich bin definitiv nicht in den WWF selbst verliebt.Meiner Meinung nach ist es:

  1. Übermäßig komplex, insbesondere für die Verwendung in Web-Apps (all dieser Thread-Laufzeitkram)
  2. Unreif (haben Sie jemals mit diesem schrecklichen Designer zusammengearbeitet?)
  3. Anämisch in seinem aktuellen Funktionsumfang

Hat jemand einen Vorschlag für ein besseres .NET-basiertes Workflow-Framework?Konkret suche ich nach folgenden Funktionen:

  1. Zustandsmaschinenbasiert (Zuordnung von Zuständen zu verfügbaren Aktionen)
  2. Ein Fokus auf Benutzerberechtigungen (Kontrolle, wer Zugriff auf welche Aktionen hat)
  3. Die Möglichkeit, Workflows als zeitgesteuerte Hintergrundaufgaben auszuführen (z. B. um Erinnerungen für Elemente zu versenden, die sich seit x Tagen in einem bestimmten Status befinden)

Das ist wirklich alles, was ich brauche.Ich muss nicht in der Lage sein, Aktivitäten per Drag-and-Drop zu verschieben oder den Ablauf visuell zu gestalten.Ich fühle mich vollkommen wohl dabei, tatsächlichen Code zu schreiben, sobald eine bestimmte Aktion ausgelöst wird.

War es hilfreich?

Lösung

Du könntest es versuchen Einfache Zustandsmaschine.Sie müssten die Zugriffskontrolle und Hintergrund-Timer selbst implementieren, aber das sollte keine große Sache sein.SSM wurde auch aus Frustration über WF entwickelt. Es gibt einige andere Zustandsmaschinenimplementierungen auf Codeplex sowie.Wenn einer von ihnen nicht sofort zur Rechnung passt, sind sie Open Source und sollten Ihnen nahe genug kommen.

Ich stimme Ihnen in Bezug auf Zustandsautomaten in WF voll und ganz zu – sie sind nicht testbar, zu kompliziert, das Threading-Modell ist eigenartig und schwer zu befolgen, und ich bin mir nicht sicher, ob ein visueller Designer für den Entwurf von Zustandsautomaten schlechter hätte konzipiert sein können grafisch.Ich denke, das liegt möglicherweise daran, dass das Konzept der Zustandsmaschine an die WF-Laufzeit angelehnt zu sein scheint, die für sequentielle Zustandsmaschinen entwickelt wurde, womit WF meiner Meinung nach viel besser zurechtkommt.Das Problem besteht darin, dass Zustandsautomaten eigentlich nicht mit einem sequentiellen Arbeitsablauf identisch sind und eine eigene erstklassige Implementierung hätten erhalten sollen, da sich herausstellte, dass die Verzerrung von WF, um den Anschein zu erwecken, sie zu unterstützen, mehr oder weniger zutrifft unhaltbar, wenn nicht sogar unbrauchbar.

Andere Tipps

Ich würde mich von Drools.Net fernhalten, da das letzte SVN-Commit im September 2007 erfolgte.Sieht gut aus, aber es scheint etwas zu riskant, eine so große Bibliothek in Ihr Projekt einzubeziehen, wenn Sie wissen, dass sie keine Aufmerksamkeit mehr erhält.

Probieren Sie Drools.NET aus

Schauen Sie mal vorbei Workflow-Engine.Es handelt sich um ein leichtes Workflow-Framework für .NET- und Java-Lösungen.Es verfügt über einen visuellen HTML5-Designer, Versionskontrolle, eine anständige Benutzeroberfläche und unterstützt eine breite Palette von Datenbanken.

Haben Sie die Möglichkeit, BizTalk Server in Betracht zu ziehen?

Die Arbeit mit Oracle BPEL Process Manager hat mir sehr viel Spaß gemacht.Es ist Teil von JDeveloper.

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

Vielleicht möchten Sie einen Blick auf Jazz werfen - http://jazz.codeplex.com/

Versuchen Sie WF4.5.Es wurde seit .NET4.0 komplett neu gestaltet.

Zunächst sollten Sie nach einer Engine suchen, die BPMN unterstützt.BPMN ist ein Standard im Workflow- und Prozessmanagement und wird von vielen Projekten gut unterstützt.Zweitens sollten Sie über die Anforderungen an einen Motor nachdenken.Wenn Sie nach einer BPMN-Engine suchen, gibt es zwei verschiedene Ansätze:

Aufgabenorientiert

Diese Motoren (z.B. JBoss BPM - jbpm) sind darauf ausgelegt, Eingabedaten durch ein genau definiertes Prozessmodell zu verarbeiten.Jede Aufgabe im Modell gibt die Kontrolle über einen Codeabschnitt – entweder eine Standard- oder eine individuelle Implementierung.Der Prozess endet, wenn das Prozess-Token das Ende des Prozessmodells erreicht (End-Event).Diese Art der Verarbeitung dauert Millisekunden.Die Engine kann für Batch-Jobs oder die Verarbeitung von Daten mit einem komplexen prozessorientierten Ablauf verwendet werden.

Ereignisgesteuert

Human-Centric-Workflow-Engines sind ereignisgesteuert (z. B. Imixs-Workflow).Dabei handelt es sich um eine Art Zustandsmaschine, die jedoch in der Regel weitaus mehr Funktionalität bietet.Sie können eine neue Prozessinstanz starten, indem Sie Ihrem Geschäftsobjekt die anfängliche Aufgabe (definiert durch das Startereignis) zuweisen.Mit der Workflow-Engine können Sie dann Ereignisse auslösen, die jeder in Ihrem Modell definierten Aufgabe zugewiesen sind.Jedes Ereignis (Intermediate CatchEvent) veranlasst die Workflow-Engine, die laufende Prozessinstanz an die nächste Aufgabe (den nächsten Status) zu übertragen.Bis kein neues Ereignis mehr ausgelöst wird, „wartet“ die Prozessinstanz im aktuellen Task (Status).Ein Genehmigungsprozess ist ein typisches Beispiel für einen solchen menschenzentrierten Workflow.

Eine Liste der Motoren finden Sie hier Hier.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top