Schlagen Sie eine anhaltende Strategie für ein Workflow -System vor

Question

Ich bin dabei, ein UI -Konfigurationstool für mein PET -Projekt zu erstellen. Ein Aspekt dieses Tools ermöglicht dem Endbenutzer seine Orchestrierung. Ich muss diese Orchestrierungsdefinition dann in einer Datenbank speichern. Es wird eine ausführbare Version dieser Definition in einem laufenden System geben. Die ausführbare Version wird dynamisch On-Demand erstellt.

Idee ist, die zu trennen DEFINITION aus AUSFÜHRBAR Version, damit ich die Flexibilität habe, die Laufzeitversion zwischen BPMN oder JPDL oder einer Pojo -basierten Workflow -Lösung (Beanflow) auszuwählen.

Einschränkung: Ich kann die BPMN -Editoren, die mit Frameworks wie JBPM, Activiti usw. geliefert werden, nicht verwenden, da ich nicht meine eigene Benutzeroberfläche verwenden möchte, die spezifisch für meine Domain ist.

Ich brauche Vorschläge, wie die Definition bestehen kann.

1. Soll ich RDBMS -Tabellen verwenden? Wenn ja, gibt es ein DB -Schema, das ich ausleihen kann, das nahe an Orchestrierungskonzepten liegt?

2. Sollte ich meine Definition mit BPMN/JPDL XML -Instanzdokument serialisieren?

3. Gibt es andere einfache Formate, die ich verwenden kann?

Answer 1

Mit "Orchestrierung" gehe ich davon aus, dass du a meinst a endliche Zustandsmaschine. Wo der aktuelle Zustand bestimmt, welche Übergänge in andere Staaten verfolgt werden können. Die Darstellung von Zuständen und Übergängen als Kanten und Eckpunkte erzeugt häufig a Regie acyclische Graphen, Es gibt jedoch Zeiten, in denen der Diagramm zykliert (z. B. Entwurf -Einreichen zur Genehmigung -> bis zur Genehmigung -Ablehnung -> Entwurf).

In der Praxis erfordert die Trennung der Definition von der Ausführung ein Persistenzformat, das leicht an die Anpassung gerecht wird. Wenn sich Ihr System weiterentwickelt, finden Sie eine Reihe von unerwarteten Randfällen, deren Lösung kein Persistenzschema, sondern nur Code erfordern sollte. Dies impliziert XML oder eine NoSQL -Lösung - etwas, dessen Schema leicht verändert oder nicht existiert.

Nachdem ich meine eigene XML -Definition zu diesem Zweck geschrieben habe (aus uninteressanten Gründen, die ich ausschließen werde), wird mein Vorschlag JPDL (oder BPMN) verwendet. Grund ist, dass ihre Definitionen wahrscheinlich alles einbeziehen, was Sie jetzt in Betracht ziehen, in Zukunft und die Anpassung ermöglichen - z. B. hängende willkürliche Daten oder Verhalten an einem bestimmten Punkt. Sie erhalten auch den Vorteil der bereits erstellten Tools - nicht nur die Benutzeroberfläche - für den Umgang mit der Zykluserkennung und sicherzustellen, dass beispielsweise ein Weg zum Abschluss besteht.

Einige der interessanten Merkmale, von denen ich weiß, dass sie JPDL besitzt, sind die Fähigkeit, Gabelprozesse, zeitgesteuerte Aufgaben (einschließlich derjenigen, die regelmäßig wiederholen) und Einrichtungen zum Senden von Benachrichtigungen zu fördern. Dieser letzte Punkt - Benachrichtigung - trägt eine weitere Darstellung. Eines der Dinge, die ich mit meinem eigenen System gefunden habe, ist die Notwendigkeit, konfigurierbare E -Mails zu senden, deren Inhalt auf den Daten basiert. Diese vorhandenen Motoren machen dies relativ einfach, indem sie eine Möglichkeit bieten, Variablen beispielsweise in Text zu platzieren, der dann vor der Laufzeit dynamisch bewertet wird. Außerdem bieten sie Brücken zwischen der Engine und dem Benutzerspeicher, um Benachrichtigungen an Personengruppen zu senden, sie zu beauftragen und Sicherheitsrichtlinien durchzusetzen.

Abhängig vom Umfang Ihres Systems verwenden Sie schließlich wahrscheinlich auch eine Datenbank. Ich schlage vor, die XML- und Daten zu speichern, die in einem serialisierten Format in die Datenbank orchestriert werden. Wenn die Daten dann geändert werden, wenn sie durch die Ausführung bewegt werden, schreiben Sie Serialisierungen der Daten - und möglicherweise auch der Workflow, wenn sie auch geändert werden - in eine Geschichte/Audit -Protokolltabelle auf.

Answer 2

Ich würde keine RDBMS -Tabellen verwenden oder die Definitionen als Textblobs speichern. Der Versuch, Aufzeichnungen für die Definition zu machen, ist eine schlechte Idee, da es viel unflexibler und schwierig ist, Ihre Definition im Laufe der Zeit zu ändern. Viele Menschen würden unterschiedliche Ansätze verwenden, aber ich würde JSON oder YAML verwenden und XML vermeiden. Die Motivation dafür ist es, es so einfach wie möglich zu machen. Der Versuch, XML zu verwenden, insbesondere ein formalisiertes spezifisches Format von XML, wird dazu führen, dass Sie viel mehr Zeit damit verbringen, eine genaue Spezifikation zu erfüllen, die eigentlich nichts unternimmt, um das zu helfen, was Sie erreichen möchten. JSON und YAML sind beide sehr einfach aus einer Code -Sicht zu arbeiten. YAML ist für Menschen leichter lesbar und leichter zu bearbeiten und ist nicht so schwierig für die Interpunktion und entkommen wie JSON. JSON wird häufiger verwendet und ist kleiner als Yaml. JSON hat auch ein binäres Gegenstück, BSON, wenn die Dokumentgröße ein Problem darstellt.

Sobald Sie einen Importeur/Exporteur haben, der zu/von Ihren internen Objekten zu Ihrem Datenformat geht, ist es unkompliziert, mit RDBMs oder anderen Mechanismen zu bestehen. Sie könnten sogar CouchDB verwenden, was Ihrer Bewerbung andere Vorteile bieten und gut passt.

Answer 3

Sehr gute Frage! Hier sind meine zwei Cent:

1. RDBMS: Wenn Sie dies tun, können Sie die Workflow -Instanzen abfragen, beispielsweise welche Token am 'Knoten x' sind?
2. Speicherung Xml Als CLOB: Die Einfachheit ist die Wahrheit dieser Lösung, aber Sie können diese nicht wirklich abfragen
3. NoSql: Es gibt viele verschiedene Lösungen für verschiedene Probleme. MongoDb ist eine beliebte Lösung, die dokumentorientierte Persistenz bietet.

Answer 4

Wie wäre es mit einer einfachen Serialisierung der komponierten Benutzeroberfläche zum Beispiel mit Xstream und speichern Sie dann die serialisierten Bits in der Datenbank als Binärspalte. Wenn sich der Benutzer anmeldet, erhalten Sie dann die zugehörigen Daten, die Deserialisierung, initialisieren Sie bei Bedarf und Anzeige.