Verschieden und doch gleich - wie Ihr mit einer Datenstandardisierung eure Prozessabläufe zentralisiert und optimiert.

In den letzten Jahren haben wir viele unterschiedlichste Kundenprojekte bei Synesty

umgesetzt. Darunter auch eine Vielzahl von Projekten die sich mit der Standardisierung von Lieferantendaten beschäftigt haben. Während die Daten, Anforderungen und Erwartungen in großen Teilen voneinander abweichen, gibt es jedoch einige wiederkehrende Problemstellungen die es zu lösen gilt. Mit wachsender Erfahrung haben wir in den letzten Jahren viele Anpassungen an der Art & Weise vorgenommen, wie wir Prozesse in Flows abbilden - einige fest verankerte Features in Synesty Studio sind sogar nur deswegen entstanden.

Im folgenden möchte ich mit euch - in mundgerechter Form - ein entsprechendes Szenario näher beleuchten. Ziel dieses Beitrages soll es sein, euch zwei Herangehensweisen für die Prozessautomatisierung an die Hand zu geben, von welcher ihr ggf. bei eurem nächsten Projekt Gebrauch machen könnt. Am Ende des Beitrages vergleichen wir beide Ansätze noch einmal miteinander und arbeiten die Vor- & Nachteile heraus.

Das Szenario

Ein Kunde hat unterschiedliche Lieferanten welche jeweils Daten für ihre Produkte zur Verfügung stellen. Diese Produktdaten sollen nun automatisiert abgerufen und daraufhin im Webshop des Kunden angelegt werden. Der Einfachheit halber gehen wir hier nur von zwei Lieferanten aus (A und B) und nehmen an, dass es hier nur um Einzelartikel gehen soll - die Vorgehensweise ist jedoch 1:1 auf Variantenartikel adaptierbar.

Das Ausgangsproblem

Meist sind Lieferantendaten - sofern kein Standard wie Veloconnect etc. genutzt wird - ein buntes Potpourri. Nutzt Lieferant A eine CSV-Datei mit deutschen Titeln, stellt Lieferant B seine Daten als Excel-Datei mit englischen Spaltenbezeichnungen zur Verfügung. Lieferant C wiederum schwört auf eine eigens kreierte XML-Datei und Lieferant D liefert seine Daten sogar per API-Call in einer JSON-Struktur aus.

All diese unterschiedlichen Daten müssen also individuell auf das gewählte Zielsystem hin gemappt (umgewandelt) werden bevor Sie als Artikel im Webshop landen können.

I - Dezentralisierter Ansatz

Die erste Herangehensweise stellt die "alte" Methode dar, wie wir diese Aufgabe angegangen sind und unter Umständen bietet sich diese Art & Weise auch heute noch an (siehe spätere Gegenüberstellung der beiden Ansätze).

Bei diesem Ansatz erstellt man pro Lieferant einen Flow welcher folgende Aufgaben abarbeitet:

Daten vom Lieferanten exportieren (z.B. per FTP-Download, URL-Download, E-Mail-Anhang etc.)
Daten auf das Zielformat mappen
Aufbereitete Daten an einen Step weiterreichen, welcher die Artikel im Shopsystem anlegt

Somit sehen unsere beiden Flows abstrahiert also in etwa so aus:

Nach der Einrichtung und Test der Flows stellt man noch pro Flow einen Zeitplan ein um das Ganze zu automatisieren - fertig.

II - Dezentralisierter Ansatz

Nun kommen wir zum "neuen" Weg, wie wir bei Synesty mittlerweile ein solches Szenario angehen. Da wir diesen Ansatz auf Grundlage I aufgebaut haben, bleiben wir Anfangs einmal noch direkt bei selbigen und schauen uns die beiden Flows noch einmal genauer an.

Stellt man beide Flows gegenüber und untersucht einmal detailliert die Aufgabenstellungen der einzelnen Steps, erkennt man das es variable und identische Parts zwischen beiden Flows gibt:

Die in der Abbildung blau markierten Steps sind pro Lieferant in aller Regel unterschiedlich und müssen entsprechend auch genau auf die jeweilige Gegebenheit angepasst werden. So liefern, wie in der Einleitung angedeutet - die Lieferanten auf unterschiedlichen Wegen die Daten zu euch und außerdem sind die Dateien grundverschieden.

Schauen wir uns nun aber den grün markierten Step an, ist zu erkennen das diese beiden Steps identisch sind, doch warum?

Dadurch das in den blauen Part die Daten auf ein einheitliches Format (= Format des Zielsystems) umwandelt, also die Daten standardisiert, besteht ab diesem Zeitpunkt kein strukturmäßiger Unterschied mehr zwischen den Daten. So sind natürlich die unterschiedlichen Artikel der jeweiligen Hersteller immer noch vorhanden, alle Daten wie Titel, Beschreibung, Preis etc. sind nun aber in einer einheitlichen Datenstruktur.

Wir wissen nun also das die grünen Steps redundant sind - dies sollten wir wenn möglich aus folgendem Grund vermeiden:

Sollte in Zukunft etwas an dem Zielformat angepasst werden - z.B. eine neue Spalte kommt hinzu - müssen diese Änderungen überall vorgenommen werden.

Ist dies in unserem Beispiel mit zwei Lieferanten noch halbwegs überschaubar, steigert sich dieses Problem mit jedem zusätzlichen Lieferanten welchen Sie angebunden haben.

Schön und gut, doch wie können wir das nun in unseren Flows vermeiden? Der Schlüssel zur Lösung dieses Problems ist der FlowExecuting Step.

Zusammengefasst bietet uns dieser Step folgende Funktionalität:

In einem Flow (="Aufrufer") einen anderen Flow ausführen (="Arbeiter")
Der Aufrufer wartet immer bis der Arbeiter fertig ist und geht erst danach zum nächsten Step über
Der Arbeiter kann an den Aufrufer Daten weitergeben (z.B. das Ergebnis eines SpreadsheetMappers)

Flows der Lieferanten zu Arbeitern machen:

Wir machen nun also unsere in Ansatz I gebauten Flows zu "Arbeitern", diese werden also künftig von einem Aufrufer-Flow aus gestartet. Damit ist es aber noch nicht getan, wir wollen ja schließlich den grünen Part (= Redundanz) entfernen, also löschen wir diesen Part aus den Arbeitern heraus. Übrig bleiben also nur noch die blauen Steps - welche pro Lieferant unterschiedlich sind. Am Ende jedes Flows geben wir die aufgearbeiteten Daten jeweils in eine Output-Variable - diese bewirkt, dass die gemappten Daten der Arbeiter an unseren Aufrufer-Flow überreicht werden.

Aufrufer-Flow erstellen:

Die Arbeiter-Flows sind entsprechend angepasst, starten wir nun also mit der Erstellung des Aufrufers. Am Ende wird dieser wie folgt aussehen:

Die beiden orangen FlowExecuting-Steps rufen jeweils die vorab erstellten Arbeiter-Flows pro Lieferanten auf.

Da wir die aufbereiteten Daten als Output-Variable in den Arbeitern definiert haben, können wir auf diese in unserem Aufrufer zugreifen und fassen diese Daten mittels eines SpreadsheetAppend Steps zusammen. Danach speichern wir die Daten in einem Datastore und rufen diese Daten danach wieder ab und spielen diese - genau wie ursprünglich in Herangehensweise I auch - in das Shopsystem ein.

Warum speichern wir die Daten erst in einem Datastore ab und rufen diese dann danach direkt wieder ab?

Eine berechtigte Frage und tatsächlich sieht das auf den ersten Blick eher nach unnützen Aufwand aus. Das ganze ist komplett optional und die Artikelanlage würde auch funktionieren, wenn wir die Daten nach dem Zusammenfassen einfach in den Step zur Artikelanlage geben würden! Der Grund warum wir euch diesen Weg zeigen ist der, dass ihr nach dem speichern der Daten in einem Datastore ohne weitere Logiken:

Nur neue Daten (=Artikel)
Nur bestehende Artikel bei denen sich ein Wert geändert hat
Nur Artikel, welche gerade nicht enthalten waren

aus dem Datastore exportieren könnt.

D.h. ihr wie in unserem ganz konkreten Fall die Möglichkeit, nur die Daten nutzen welche auch neu im Datastore angelegt wurden (= neue, noch nicht angelegte Artikel). Zukünftig habt ihr so außerdem ohne weitere Anpassungen/Logiken die Option, Steps oder Flows zu bauen die z.B. gezielt geupdatete Lieferantenartikel im Shopsystem aktualisiert oder nicht mehr vorhandene Lieferanten-Artikel im Webshop löscht. Hierzu gehen wir auch am Ende der Story noch einmal kurz ein.

Vergleich beider Herangehensweisen

Stellen wir am Ende nun noch einmal beiden Methoden gegenüber und schauen uns die Vor- & Nachteile an.

Dezentralisierter Ansatz - I

[themify_col grid="2-1 first"]

Vorteile

Relativ einfach ohne weitere Vorüberlegungen umsetzbar

[/themify_col] [themify_col grid="2-1"]

Nachteile

Alle Anpassungen müssen in jedem einzelnen Flow vorgenommen werden
- Spaltenanpassung im Zielformat (Neue Spalte, Spalte löschen, Spaltendaten anpassen)
- Artikelupdate
- Artikel löschen
- Zeitpunkt der gesamten Artikelanlage soll geändert werden
Jeder einzelne Flow benötigt eine eigene Zeitplanung
Redundante Steps

[/themify_col]

Zentralisierter Ansatz - II

[themify_col grid="2-1 first"]

Vorteile

Jede Anpassung am Zielformat muss nur an einer zentralen Stelle vorgenommen werden
Nur der Aufrufer muss automatisiert werden (eine zentrale Stelle für alle Automatisierungsoptionen)
Einzelne Lieferanten können ganz einfach via Pausieren oder Löschen des ExecutingSteps gesteuert werden
Für sich logisch abgegrenzte Aufgaben sind autark in einzelnen Arbeiter-Flows gekapselt
Kann bei Bedarf in Zukunft entsprechend um Löschen, Updaten ... von Produkten angepasst werden

[/themify_col] [themify_col grid="2-1"]**Nachteile**

Es müssen detaillierte Vorabüberlegungen angestellt werden
- Wie genau sieht mein gewünschtes, standardisiertes Zielformat aus
- Was passiert wenn bei einigen Herstellern bestimmte Felder nicht geliefert werden (= z.B. Mapping Set(s) für Felder erstellen)

[/themify_col]

Zusammenfassend kann man erkennen, dass beide Ansätze ihre Daseinsberechtigung haben. Wenn wir es auf eine Faustformel herunter brechen müssten, wäre es folgende:

Wenn abzusehen ist, dass in naher Zukunft für gleiche Aufgaben mit mehreren Datenquellen zu erledigen sind, sollte zum zentralisierten Ansatz (II) gegriffen werden, ansonsten kann ein dezentraler Ansatz (I) gefahren werden.

Unserer Meinung nach überwiegen die künftigen Vorteile welche man durch Ansatz II hat in jedem Fall den anfänglichen Mehraufwand, denn somit werden künftige Anpassungen an den Prozessen stark vereinfacht.

Bonus: Wie könnte eine noch aufwändigere Integration mit Update und Löschen aussehen?

Wir haben es ja schon vorhin erwähnt, aber das hier gezeigte Beispiel ist natürlich der Einfachheit halber sehr stark reduziert dargestellt und in der Realität ist es meist mit dem bloßem Anlegen von Produkten nicht getan. Meist müssen noch bereits vorhandene Artikel geupdated und vom Lieferanten nicht mehr mitgelieferte Produkte im Shopsystem gelöscht bzw. gekennzeichnet werden.

Diese Prozesse können natürlich genauso wie die Steps zur Artikelanlage einfach in den Aufrufer-Flow ans Ende gebaut werden, allerdings geht mit weiteren und ggf. komplexeren Aufgaben die Wart- und Übersichtlichkeit in dem Flow verloren. Daher würden wir bei einem Kundenprojekt dann - genau wie die Datenaufbereitung selbst - die einzelnen Aufgaben (Artikelanlage, Artikelupdate, Artikel löschen) in einzelne Arbeiter-Flows auszulagern, da hier natürlich wiederum alle Vorteile des Ansatz II gelten.

Und da dies ein Bonus-Kapitel ist und dies schon aus Prinzip fordernder als der ganze Rest sein muss, nutzen wir wie bei den bisher beschriebenen Arbeiter-Flows nicht nur die Output-Variablen, sondern ebenfalls die Flow-Variablen um Daten aus dem Aufrufer an unsere Arbeiter zu übergeben. Denn genau wie die Arbeiter Daten nach außen geben, können diese auch Daten von außen erhalten um diese weiter zu bearbeiten.

Wir nutzen hierfür die Output-Daten des DatastoreWriter Steps, also jenem Step der die Artikeldaten in den Datastore abspeichert. Wie schon im obigen Part zur Methode II gezeigt, bekommen wir hier neue, geupdatete und "alte" Daten aus dem Datastore geliefert. Diese lesen wir mittels der neu erstellten Aufrufer-Flows einfach ein und können dann damit die entsprechenden Aufgaben erledigen. Als Resultat sieht unser Aufrufer-Flow dann so aus:

Wir haben also bis auf die Speicherung und anschließende Weitergabe der Daten keinerlei Logik mehr in dem Aufrufer-Flow, alle entsprechenden operativen Funktionen übernehmen fortan unsere Arbeiter.