Datenkonvertierung per Workflow: Ist meine Idee (so) per WWF umsetzbar?

Hallo zusammen,

ich überlege für die Arbeit ein Programm zu schreiben, was konvertierungen übernehmen soll. Als eingabe sollen verschiedene csv (oder txt) und Exceltabellen gelten. Ausgabe wird wieder eine txt in einen bestimmten Format. Dieses ist bereits realisiert, jedoch wird jede konvertierung umständlich per Hand programmiert.

Meine Idee war nun, das ich eine WPF basierende Oberfläche schaffe und die programmtechnische umsetzung der Programmierung in WWF auszulagen. Das Programm soll nach einen vorher gesetzten Schema dann die Workflows der reihe nach anstoßen und die Konvertierung Stück für Stück vornehmen (also Modular aufgebaut zwecks wiederverwertbarkeit). Das dieses geht, bin ich mir (fast) sicher, ich gehe zumindest davon aus, das Workflows vorher bereit gestellte Objekte manipulieren können, oder?

Wo ich mir nicht so sicher bin, ist die Dynamik. Ich würde gerne die WWF auslagen und dynamisch einbinden. Also ohne das der Programmierer später weiß, was wür ein Workflow eingebunden wird, sollte dieser (evtl mit bestimmten Vorgaben) seinen dienst machen. Insbesondere soll derjenige der den Workflow bastelt, nicht den Quellcode der Oberfläche manipulieren müssen. Also evtl eine auslagerung in dll´s oder externe dateien oder ähnliches. Ziel ist es, das system nur einmal Grundlegend zu programmieren und die einzelnen Abteiltungen (die teilweise selbst über scripter verfügen) die Workflows designen zu lassen und dies vollkommen unabhängig von dem Hauptprogramm. Das soll ermöglichen, das mehrere Programmierer das Programm unabhängig von einander nutzen können. Wichtig ist mir vor allem, das ein späterer Workflowprogrammierer nichts am Quellcode des Hauptprogrammes ändern muß, damit sein workflow funktioniert. Ich hoffe ich konnte vermitteln, was mir vorschwebt.

Jetzt ist die Frage, ist so etwas machbar? Ich wollte mich vor allem vorab informieren, da ich diese Idee die Tage beim Chef vorstellen will. Ich habe zwar noch Alternativen ohne Workflows in petto, aber Workflows sind in unseren Unternehmen gerade "In", da unserer Basisarbeitssystem diese vor kurzen eingeführt hat.

Die flexibelste Möglichkeit wäre wohl (wenn es nur um Konvertierungen geht) einfach Streams zwischen den einzelnen WF-Knoten hin und her zu schicken.

Dein WF-Host würde dann anhand einer Config auf einen Ordner pollen etc. und die Daten als Stream in den Workflow füttern wo sie so auch wieder rausfallen und in einer Datei/DB landen.

Kannst ja verschiedene Quellen uns Senken bauen die nachher im Host konfigurierbar sind.

Ich hatte daran gedacht eine Tabelle zu erstellen und diese dann je nach knoten zu befüllen. Aber hier geht es eher grundlegend darum, ob diese Idee umsetzbar ist.

Aber hier geht es eher grundlegend darum, ob diese Idee umsetzbar ist.

Ja 😃 Aber du hast das alles noch sehr vage beschrieben.

Also da Workflows ja auch nur Typen sind die in Assemblies liegen kannst du sie schon mal dynamisch laden, parametrisieren und starten. Du kannst ebenfalls Workflows dynamisch im Code erstellen (grob gesagt wie wenn du Controls auf ne Form packst nur das du eben Activities in einen Workflow stopfst).

Stellt sich halt noch die Frage wo du deine Daten herholen möchtest und wie die Konvertierungen gestrickt sein sollen.

Mein Vorschlag war das du ein Interface definierst welches die Datenquelle darstellt (mit einer Methode GetSorceStream()) und ein Interface für die Datensenke (mit Methode WriteSinkStream(Stream stream)). Von diesen Interfaces kann es dann verschiedene Implementierungen für Files, Datenbanken, RSS-Feeds etc. geben, gleiches gilt für die Senke.
Zwischen Quelle und Senke sind die Workflows angesiedelt und transferieren/transformieren die Daten auf dem Weg zur Senke.
Das einzige was der Entwickler der Workflows dazu kennen muss ist deine Schnittstelle.

Du kannst dann auch ein XML-Manifest bauen welches die benötigten Informationen über einen Workflow enthält (welcher Workflow, wo liegt er, welche Quelle/Senke ist zu benutzen, Abhängigkeiten, Schedules etc.). Dieses File bzw. die Infos daraus kannst du in einer Datenbank registrieren und dafür ein Verwaltungstool schreiben. Auch interessant ist wenn die Workflows diese Informationen selbst liefern können.

Hallo Taladan,

Aber du hast das alles noch sehr vage beschrieben.

wenn ich es richtig verstehe, gibt es zwei Berührungspunkte zwischen Workflow und dem restlichen Code: Einmal bei GUI -> Workflow und einmal bei Workflow -> Datenobjekte.

Weiterhin klingt es mir so, also solle der Code von GUI und Datenobjekten feststehend sein und nur der Code des Workflows geändert werden.

Alles richtig?

Und deine Frage ist, ob es möglich ist, ohne Änderungen am GUI-Code und am Code der Datenobjekte, den Codes des Workflows zu ändern?

herbivore

PS: Um Missverständnisse zu vermeiden: Ich frage nur; beantworten kann ich die Frage nicht. Da muss jemand anders ran.

Hallo,

richtig verstanden. Wobei die Datenobjekte nicht fest stehen, aber fest definiert werden, bevor der workflow loslegt und der Script der Workflows legt das Datenobjekt fest. Ok. eigendlich hast du rest, die Datenobjekt stehen fest und sind bekannt. Der Workflow soll lediglich folgende dinge tun.

1. Auslesen der herkunftstabellen (aus Dateien) und übergabe in eine einheitstabelle, nach schema f. Wenn möglich über Wfl, sonst über GUI. dieses übergibt dann das "datenobjekt"
2. manipulieren der Einheitstabelle und anreicherung der daten mit entsprechenden entscheidungen. beispiel nimm spalte 3 überprüfe damit per odbc connekt ob diese in tabelle g feld h bereits vohanden ist und wenn ja schreibe in spalte 1b ergebnis. Wobei hier für jede Aufgabe ein eigener Workflow laufen soll. Also durchaus auch mehrere. Paramter sollen dann eingabe und ausgabefelder angeben.
3. Zwischensicherung der einheitstabelle mit allen zwischenergebnissen (zur nachvollziehbarkeit).
4. Zusammenstellen der Daten nach schema I und export derselbigen, damit diese lesbar verarbeitet werden können.

PS: ich wiess das die GUI eigendlich keine daten verabreiten kann, ich meine damit das Hauptprogramm.

Hintergrund soll vor allem sein, das der Programmieraufwand später klein gehalten werden soll und für ein geänderten oder neuen importschema nur wenige klicks notwendig sind, diese zusammenzustellen (festlegen der workflows und parameter). Da unsere datenlieferanten sehr häufig die Datenschemen ändern.

Noch eine Frage eben nachgeschoben. Ich habe gerade ein Onlintext gelesen. Brauch das Workflowsystem tatsächlich eine Datenbank? Mein Plan war eigendlich, das ganze als reine Application laufen zu lassen und alle benötigte Daten vom Netzwerklaufwerk zu holen. Wenn doch, welche DB wird benötigt?

Noch eine Frage eben nachgeschoben. Ich habe gerade ein Onlintext gelesen. Brauch das Workflowsystem tatsächlich eine Datenbank? Mein Plan war eigendlich, das ganze als reine Application laufen zu lassen und alle benötigte Daten vom Netzwerklaufwerk zu holen. Wenn doch, welche DB wird benötigt?

Nein ein Workflow braucht keine Datenbank. Eine Datenbank wird erst benötigt, wenn man eine StateMaschine bauen möchte, die dann zwischenstände in eine Datenbank persistieren können muss.

Ansonsten ist die WF4 eine reine XAML deklaration, was dann einen direkten schnellen austausch der logik einfach macht.

Zumindest habe ich das bis dato so verstanden. Und WF würde sich durchaus zu deinem problem sehr gut anbieten.

Grüße Stephan

Danke, das wollte ich hören 😉.

Eventuell mal die SQL Server Integration Services anschauen bevor man anfängt die nachzubauen. Eventuell reichen die ja für deinen Fall auch schon aus (Für spezielle Sachen gibt es auch eine C#-Skript Komponente).

Die Pakete kann man auch aus einer C#-Client Anwendung aus aufrufen und die Pakete selbst können im FS oder auch in einer DB liegen.

Ich habe zwar noch Alternativen ohne Workflows in petto, aber Workflows sind in unseren Unternehmen gerade "In"

Da muss man immer ein bisschen aufpassen. Workflows werden oft gerne als der universelle Problemlöser verkauft der sie aber nicht sind. Gerade wenn man die Workflows durch Fachabteilungen erstellen lassen will kann einiges schief gehen.