Neufassung der Fett-Client-Anwendung als verteilter Arbeitsablauf

Question

Meine Firma bedient ihre Kunden derzeit mit einer Windows-basierten Fat-Client-App, in die Workflow-Verarbeitung eingebettet ist. Grundsätzlich fügt der Kunde eine Reihe von Dokumenten am Anfang des Workflows ein, die Dokumente werden über eine Reihe von Workflow-Schritten verarbeitet und nach einer gewissen Zeit wird die Ausgabe dem Kunden präsentiert. Wir erweitern derzeit die Größe für größere Kunden, indem wir die Anwendung auf anderen Rechnern installieren und den Cluster von Maschinen auf verschiedenen Dokumenten-Untergruppen arbeiten lassen. Nicht ideal, aber mit minimalen Änderungen an der Anwendung, erlaubte es uns, einfach auf unser aktuelles Niveau zu skalieren.

Das Problem, dem wir jetzt gegenüberstehen, ist, dass, da unsere Kunden uns größere Dokumentensätze zur Verfügung gestellt haben, wir mehr als erwartet für Maschinen, IT-Unterstützung usw. ausgeben. Also haben wir begonnen über die Re-Architecture nachzudenken Plattform, um es skalierbar zu machen. Ein Merkmal unserer Lösung ist, dass jedes Dokument unabhängig voneinander bearbeitet werden kann. Außerdem haben wir 10 Workflow-Schritte, von denen zwei der Schritte etwa 90% der Verarbeitungszeit beanspruchen.

Eine Idee, über die wir uns Gedanken machen, besteht darin, dem Dokumentenschema ein Workflowschrittfeld hinzuzufügen, um zu verfolgen, welcher Workflowschritt für das Dokument abgeschlossen wurde. Wir können dann den gesamten Cluster von Maschinen werfen, um an einem einzelnen Dokumentensatz zu arbeiten. Ein einzelner Computer wäre nicht für die sequenzielle Verarbeitung eines Dokuments über alle Arbeitsablaufschritte verantwortlich, sondern fragt die Datenbank für das nächste Dokument/Arbeitsablaufschrittpaar ab und führt diese Verarbeitung aus. Klingt das nach einem vernünftigen Ansatz? Irgendwelche Vorschläge?

Vielen Dank im Voraus.

Answer 1

Während ich nicht sicher bin, mit welcher spezifischen Entwicklungsumgebung Sie arbeiten, musste ich mich mit einigen ähnlichen Workflows befassen, in denen wir eine Vielzahl von Quelldokumenten, verschiedenen Schritten usw. mit unterschiedlichen Leistungsmerkmalen haben.

Angenommen, Sie haben eine Reihe von unabhängigen Schritten - d. H. Schritt Arbeitsprodukt ist die Eingabe für Schritt B, und Schritt B Produkt ist die Eingabe für Schritt C usw. Ich würde Message Queuing als eine mögliche Lösung betrachten.

Zum Beispiel werden alle neuen Dokumente in eine Warteschlange geworfen. Eine oder mehrere Listener-Apps treffen die Warteschlange und holen sich das nächste verfügbare Dokument, um Schritt A durchzuführen. Wenn Schritt A abgeschlossen ist, wird eine Verbindung zu dem Ausgabeprodukt und/oder relevanten Daten in eine andere Warteschlange geworfen. eine separate Listener-App zieht aus dieser zweiten Warteschlange in Schritt B usw., bis das endgültige Ausgabeprodukt erzeugt ist.

Auf diese Weise verwenden Sie eine Warteschlange für den Haltebereich zwischen jedem einzelnen Schritt und können jeden einzelnen Prozess zwischen den Warteschlangen vergrößern oder verkleinern.

Zum Beispiel verwenden wir dies, um von einigen Datentransformationen über einen Renderprozess zu einem Spooler zu gelangen. Die Daten sind schnell, die Renderings sind CPU-gebunden und das Drucken ist I/O-gebunden, aber jeder einzelne Schritt kann nach Bedarf skaliert werden.

Sie könnten (technisch) eine DB dafür verwenden - aber eine Nachrichtenwarteschlange und/oder ein Servicebus würden Ihnen wahrscheinlich besser dienen.

Hoffentlich weist Sie das in die richtige Richtung!