it-swarm-eu.dev

Wann sollten Workflow-Engines verwendet werden?

Ich habe in der Vergangenheit als Programmierer an einigen Workflow-Engines gearbeitet, hatte aber nie eine klare Vorstellung davon, warum wir die Workflow-Engines überhaupt gewählt haben. Und als Programmierer weiß ich, dass es mindestens 100 Möglichkeiten gibt, etwas zu tun, wenn Sie Code schreiben, aber nur wenige der besten sind die besten!

Ich verstehe immer noch nicht, welche Anwendungsfälle am besten von Workflow-Engines (oder vielmehr deren Konzept) gelöst werden können, als eine gute DI-fähige Anwendung zu entwerfen. Ich suche nach allgemeinen Merkmalen domänenneutraler Anwendungsfälle, bei denen Workflow-Engines eine der besten Optionen sind.

Meine Frage lautet also: Was sind allgemeine Merkmale einer Anforderung, die als Signal für die Entscheidung für eine gute Workflow-Engine und deren Codierung dienen können?

43
A01_

Eine Workflow-Engine ist nützlich, wenn Sie von Anfang bis Ende wechseln müssen, aber es gibt viele verschiedene Pfade/Logik/Regeln, um dorthin zu gelangen.

Nehmen wir zum Beispiel an, ich schreibe ein Programm, das Inhalte veröffentlicht. In meinem Fall durchläuft die Veröffentlichung einen Überprüfungsprozess, eine rechtliche und dann eine endgültige Genehmigung. Ich schreibe das Programm auf, das meine Prozesslogik und Schritte implementiert. Jetzt funktioniert das großartig für mich und meine Firma. Also entscheide ich, dass andere mein Programm verwenden sollten.

Leider veröffentlicht nicht jeder Inhalt mit demselben Prozess. Anstatt separate Prozesse für jeden Fall zu schreiben, würden wir einen Workflow-Prozess implementieren, damit das Programm flexibel ist, um alle zu berücksichtigen. Unabhängig davon, wie viele Schritte, Regeln oder Logik zwischen diesen beiden Punkten liegen, ist das Ergebnis dasselbe.

Wenn Sie also Prozesse haben, die von Anfang bis Ende variabel sind, verwenden Sie einen Workflow. Wenn derselbe Prozess von allen verwendet werden kann, benötigen Sie keinen Workflow.

23
Jon Raynor

Ich weiß, dass Sie nach Anwendungsfällen gefragt haben, aber es ist einfacher, die Vorteile aufzulisten, als sich alle möglichen Anwendungsfälle vorzustellen. Die Vorteile hängen natürlich von der Engine und der Sprache ab, die Sie vergleichen, aber im Allgemeinen:

  1. Wenn Sie Regeln als Daten anstelle von Code beibehalten, müssen Sie sie nicht neu kompilieren, sodass Sie Änderungen schnell testen, zur Laufzeit ändern usw. Kein großer Vorteil, wenn Sie sie nicht erst neu kompilieren müssen.

  2. Es ist vernünftiger, dass Benutzer die Regeln bearbeiten. Sie können möglicherweise interaktiv mit ihnen auf eine Weise basteln, die nicht machbar ist, wenn ein Programmierer Code für sie schreibt.

  3. Durch das Beibehalten von Regeln als Daten können Tools geschrieben werden, um die Daten zu visualisieren und zu ändern.

  4. Das Beibehalten von Regeln als Daten ermöglicht eine einfachere Metaprogrammierung - Sie können Code schreiben, um die Daten zu analysieren und auf komplexe Weise mehr einzufügen, was für Code sehr schwierig wäre.

All diese Dinge können direkt mit Code ausgeführt werden (z. B. - Schreiben Sie einen C # -Parser, um alle Regeln eines bestimmten Typs zu finden und Code für weitere Regeln zu generieren, fügen Sie ihn dynamisch in eine Assembly ein, sodass das Entladen von Assemblys möglich ist, und schreiben Sie Tools für Benutzer können dies auch mit Ihrem Visualizer und Editor tun), können jedoch je nach Ihrer Sprache viel schwieriger sein (Programmierer, die ein LISP verwenden, bezeichnen die Punkte 1 bis 4 möglicherweise als "Programmierung").

19
psr

IMHO ist der einzige Fall, in dem Sie diese Art von Dingen verwenden sollten, wenn es von weniger wertvollen Benutzern konfiguriert werden kann. Wenn Sie Ihr Problem lösen können, indem Sie ihnen ein Werkzeug geben, arbeiten Sie wieder an etwas Wichtigerem als einem.

Wenn Sie es noch für sie einrichten müssen, können Sie sich vorstellen, dass Sie mit einem Ihnen vertrauten Tool auf 10 verschiedene Arten das gleiche Ergebnis erzielen können, und es wird viel einfacher zu unterstützen und anzupassen sein.

3
Bill

Dies sieht aus wie eine alte Frage, taucht aber in freier Wildbahn mehrfach auf. Ich stimme zu Jons Antwort . Ich habe festgestellt, dass Workflow-Engines in den folgenden Szenarien sehr produktiv sind:

  1. Es gibt einen zugrunde liegenden Geschäftsprozess, den Sie durch Ihre Software darstellen/implementieren möchten.
  2. Es gibt eine einzelne (möglicherweise zusammengesetzte) Geschäftseinheit, an der in allen oder einigen Phasen des Prozesses gearbeitet wird. In dem Beispiel, das Jon gegeben hat, wäre diese Entität oder dieses Workflow-Element Inhalt oder ein Artikel. Betrachten Sie die Fehlerverfolgung als ein weiteres Beispiel für einen Workflow. Ein Fehler wechselt zwischen verschiedenen Zuständen, basierend auf einer Aktion, die ein Benutzer ausführt.
  3. Verwenden Sie Workflows, um Ihre Prozesse nur dann zu modellieren, wenn Sie erwarten, dass sich der Geschäftsprozess ändert. Mit Änderung meine ich die Sequenz oder Aktion, die als Ergebnis einer Benutzeraktion oder eines Benutzerübergangs ausgeführt wird.

Seien Sie sehr vorsichtig und kritisch, um festzustellen, ob Ihre Problemdomäne/-anforderungen einen Geschäftsprozess aufweisen. Versuchen Sie nicht, ihn in einen Workflow zu "integrieren".

3
Akshay Singhal

Ich habe einige Richtlinien, die ich verwende, um Workflow-Engines vorzuschlagen.

1) Wenn die Geschäftsanalysten keinen Codierungshintergrund haben, aber Diagramme zeichnen können.

Moderne Workflow-Engines verwenden die Notation zur Modellierung von Geschäftsprozessen oder die weniger leistungsfähigen Versionen, die in SharePoint und ähnlichen Systemen verfügbar sind. Diese ermöglichen es technisch kompetenten, aber codierungsbehinderten Teammitgliedern, viele Arbeitsabläufe zu entwerfen und zu entwickeln.

2) Wenn Sie den Arbeitsfortschritt überwachen müssen, führen Sie Eskalationen durch und wechseln Sie zwischen computergesteuerten Prozessen und von Menschen gesteuerten Prozessen hin und her.

Überwachung und Selbstreferenz sind Markenzeichen moderner Workflow-Engines.

1
BobDalgleish