Neues Thema starten

Feature Request - Beim "Daten holen" in einem Spreadsheet wahlweise nur direkt abhängige Steps einbeziehen

Hallo Synesty-Team,


wenn ich in einem Spreadsheet Daten aus vorherigen Steps hole, ärgere ich mich immer wieder über die langen Ladezeiten. Die kommen m.E. daher, daß bei diesem Vorgang ALLE aktiven Steps vom Anfang des Flows bis zum gerade aufgerufenen Step durchgespielt werden, erst dann wird mir das Ergebnis angezeigt (korrigiert mich, wenn ich mich hier irren sollte). Wenn mir das zu bunt wird, gehe ich dann immer raus und deaktiviere erstmal alles, was vorher liegt, aber mit diesem Spreadsheet nichts zu tun hat - dann geht es deutlich schneller. Mein Vorschlag wäre, daß ihr eine Möglichkeit bietet, nur die mit dem gerade aufgerufenen Step in Zusamenhang stehenden Steps abzuarbeiten. Das würde das System ja auch entlasten und mir schneller zum gewünschten Ergebnis verhelfen. Was halte ihr davon?


Gruß Podolsky


Vielen Dank für die Anregung. Wir prüfen mal, was man machen kann. Wir hatten diese Thematik intern immer mal diskutiert. Leider gibt es viele Fälle, wo die Abhängigkeiten nicht zweifelsfrei erkannt werden können z.B. wenn man Step-Outputs nur in Freemarker Scripts verwendet und nicht direkt im Step verlinkt.


Evtl. kann man aber an der Stelle "Daten holen" eine optionale Liste anzeigen, welche Steps ausgeführt werden sollen. Da kann man dann ankreuzen, welche Steps man ausgeführt haben möchte. Evtl. macht man da einen "best guess" Vorschlag.


Wir nehmen es auf die interne TODO Liste mit auf, aber zeitnah wird das leider nichts, da gerade andere Themen Prio haben.

Was ja meistens auch hilft, ist wenn man für alle zeitaufwändigen Steps ein Limit von 1 setzt...


Das erste was ich in jedem Step mache ist deshalb, eine Limit-Variable anzulegen, und die mit allen (Input-)Steps zu verknüpfen wo dies möglich ist. Bevor ich dann "Daten hole", setze ich die immer auf 1, und so läuft das auch deutlich schneller dann. Nur: ab und zu vergesse ich auch, die wieder hoch zu setzen, was im Produktivbetrieb enorm schlecht ist :D


Vielleicht könnte man sowas wie einen Debug-Mode schaffen, der visuell klar angezeigt wird, und alle Limits auf 1 setzt. Und zum Daten-Holen wird der eben dann immer automatisch aktiviert. Das würde wahrscheinlich schon viel helfen und man müsste sich um die Abhängigkeiten nicht kümmern!


Vielleicht ne Idee wert?


Gruß Daniel

Der Tip von Daniel mit der Limit-Variable ist gut. Wir selbst legen uns auch immer so eine Limit Flow-Variable an, mit der wir das steuern können und beim Flow entwickeln ist diese immer so klein wie möglich.

Am Ende des Tages ist die Grundregel: Je weniger Daten, desto schneller. 


Auch die Idee von Daniel mit Debug/Edit Mode ist gut. Wir hatten auch intern schon grob solche Überlegungen. Problem war aber oft, wenn man viel mit SpreadsheetFiltern arbeitet: Da kann es dann zu dem Fall kommen, dass durch das kleine Limit bestimmte Datensätze gar nicht erst kommen, die man aber gern zum Test seines Filters braucht. 


Wir hatten intern mal die Idee, dass man sich für so einen Edit-Mode irgendwie ein festes Set an Testdaten anlegen kann. Wir hatten intern immer von "freeze" gesprochen. D.h. man kann an irgendeiner Stelle die Test-Daten "einfrieren" indem man sagt: "das sind die Daten mit denen ich jetzt testen und den Flow bauen will". Und diese Daten werden dann in einen Cache gepackt und sind immer schnell verfügbar. Aktuell werden die Daten quasi immer live geholt und das dauert natürlich, je nach API-Call und Datenmenge. 


Ein anderes Thema sind Flows die (zu) viele Dinge auf einmal machen. Also quasi mehrere Use-Cases in einem Flow abhandeln. Da wird es schwieriger. Unsere Denke ist immer, dass ein Flow genau eine Sache machen sollte. D.h. im Zweifel eine Quelle, ein Ziel und dazwischen passieren Dinge - fertig. 

Baut man nun größere Flows, wo mehrere Quellen und mehrere Ziele verwendet werden kommt man zu dem Problem von Herrn Podolsky, dass bei Mappern am Ende des Flows Steps davor ausgeführt werden, die nicht unbedingt notwendig sind. 

Die Frage wäre, ob man auch diese Problem mit dem obigen "Test Daten-Freeze" lösen könnte...


Es wäre schön, wenn wir dieses Problem hier gern noch etwas weiter brainstormen könnten. Vielleicht kommen wir ja so zu einem besseren Konzept. 




1 Person gefällt dies

Das mit dem Freeze ist eine hervorragende Idee! Ich habe das im Prinzip an manchen Stellen auch so gemacht, indem ich das bis dahin Aufgelaufene als Excel-Datei angelegt und per FTP auf einen Server hochgeladen habe. Dann habe ich diese Steps weitestgehend deaktiviert, die Excel-Datei vom Server geholt und dann diese als Datenquelle für alle weiteren Steps benutzt. damit geht alles dann wesentlich schneller. Es ist aber mühsam, weil man höllisch aufpassen muß, daß man an den richtigen Stellen die richtigen Datenquellen setzt, und wenn der Flow fertig ist, muß man das dann alles wieder zurückstellen. In sofern wäre der Freeze natürlich super, weil man sich das alles sparen könnte!

Kann mir bitte jemand die Sache mit der Limit-Variable veranschaulichen? Wo lege ich die an; unter "Variablen" im Kopf eiens Flows finde ich da nichts (nur Referenzvariable, Datei-Upload u.ä.)

@synesty-support:
Ja, das Problem das mit einem Limit die Bedingungen für die Filter nicht mehr erfüllt werden hab ich dann auch oft. Bei nicht-so-relevanten Dingen setz ich mir die gewünschten Werte einfach beim Artikel mit der niedrigesten ID (der kommt immer mit), aber das ist ziemlich unelegant :-/

Ein Freeze-Mode mit vordefinierten Werten wäre super!

@spawn:
Du legst im Flow einfach eine Text-Variable an - ich nenn die immer "limit" und geb der den Wert 1 oder 5, je nachdem...

Und dann gibts diverse zeitintensive Steps wie Api-Calls, Dynamische Exporte in Plenty, CSVWriter usw, die in den Einstellungen einen Wert fürs Limit haben. Da klickst du aufs Ketten-Symbol und verknüpfst deine Variable. Wenn du fertig bist, setzt du limit auf einen Wert der groß genug für "alles" ist. Je nachdem, bei Artikeln reicht bei uns 15000, bei Kunden müssens 200000 sein, Aufträge noch höher.

(btw @synesty: wenn mich nicht alles täuscht akzeptieren nicht alle Steps ein leeres Limit. Das wär egtl die beste Lösung für Produktivbetrieb. Oder inzwischen doch?)

Bei den Flows die zu viel auf einmal machen sind wir definitiv guilty-as-charged :D

Das ist n stückweit einfach ne Kostenfrage: wozu drei Aufgaben die alle gleich oft laufen müssen auf 3 Flows (mal der Anzahl der Runs) verteilen, wenns auch in einem Flow geht? Für die Kohle nehm ich doch lieber die Datenbankzeilen oder die Runs ;)

Da hilfts aber, mit dem Play/Pause-Symbol (einzeln) die kompletten Segmente die grade nicht relevant sind zu deaktivieren 

Wäre das Abrechnungsmodell nicht auf Basis von Flows & Runs würde ich das aber definitiv auch anders machen...

 

@Daniel:

Das mit dem Limits (leer = unendlich) müssen wir angehen. Das ist leider von unserer Seite aus bisher sehr inkonsistent gelöst. Wir versuchen das in den kommenden Wochen mal Stück für Stück an zu gehen und gerade zu ziehen. Ist halt leider sehr aufwändig, da wir jeden Step durchgehen müssen. 


@Freeze: 

Ok, schön, dass dazu eine Diskussion zustande kommt. Wir werden das Thema mal intern weiter voran treiben und ein Konzept erarbeiten. Wichtig ist, dass es vom UI her irgendwie verständlich ist, was jetzt gerade genau "gefreezed" ist. Aus technischer Sicht ist aber auch noch wichtig, dass die Datenmenge bei einem Freeze moderat gehalten wird, denn auch unser Server-Cache-RAM ist begrenzt ;)


1 Person gefällt dies

@Daniel: Danke für die Erläuterung! Ich habe teilweise Flows mit 160 Steps, da wird das Ganze leider zu unpraktisch, jedes Mal diese Variable zu aktivieren/wieder zu deaktivieren. Ich glaube, letztlich ist es effizienter, einen Teil des Flows bis zu einem bestimmten Punkt laufen zu lassen, an dem dann das Zwischenergebnis als Excel-Datei exportiert wird. Den ganzen Bereich deaktiviere ich dann im Anschluß und hole mir für die weitere Bearbeitung die Excel-Datei als Basis rein - so muß ich dann, wenn alles fertig ist, nur einmal die Datenquelle von der Datei weg und wieder auf den eigentlichen letzten Step legen, die Steps wieder aktivieren und fertig. 

An der Stelle vielleicht ein hilfreiches Feature:


Man kann in der Massenbearbeiten-Funktion für Steps durch Halten der Shift-Taste mehrere Steps auf einen Schlag aktivieren und deaktivieren.


image

image


image


Ablauf:

1. Klick auf den ersten Step den man pausieren will

2. Shift-Taste drücken und halten

3. Klick auf den letzten Step, den man pausieren will.

Alle Steps dazwischen sollten jetzt angehakt sein.












2 Personen gefällt dies
Anmelden um einen Kommentar zu veröffentlichen