Hallo,
ich hab in einem Flow eine Bedingung verändern müssen, so dass ein PlentyUpdateVariations nun plötzlich enorm lange läuft: um die fünf Stunden 
Das Thema warum das überhaupt so ist (ich schreibe 24k Artikel, mit folgenden Feldern: IsVisibleInListIfNetStockIsPositive, IsInvisibleInListIfNetStockIsNotPositive, StockLimitation, IsVisibleIfNetStockIsPositive, IsInvisibleIfNetStockIsNotPositive, IsAvailableIfNetStockIsPositive, IsUnavailableIfNetStockIsNotPositive, MarketIDs, RemoveMarketIDs) wäre an anderer Stelle wahrscheinlich auch mal eine Betrachtung wert, denn wir liegen auf einer eigenen Datenbank mit erhöhten Limits für alle Calls, das sollte eigentlich in keinem Fall so lange dauern.
Aber konkret fliegt mir der Flow eh um die Ohren: direkt nach dem PlentyUpdateVariations kommt noch ein PlentyAddPropertyToItem das seine Daten aus dem selben Step (Filter) speist wie der Call zuvor. Und wirft dann direkt diesen Fehler:
09:37:49
Used limit: 1000000
09:37:50
Start fetching Properties from 1 page with 250 items each (total: 111)
09:37:50
Total number Properties received: 111
Fehler beim lesen der Datei: cachedSpreadsheetFilter.csv (Root Causes: NoSuchFileException: /ef892d1f-17b7-11ea-8551-901b0ea49fee-f706dc39-c738-11eb-a5a7-901b0ed5b6cc–4/cachedSpreadsheetFilter.csv)
Entsprechend dem Dateinamen hätt ich gedacht dass hier der Cache Probleme macht, aber weder der Filter noch irgend einer der Steps davor haben überhaupt den Cache aktiv.
Kann ich hier irgendwas tun damit der Step seinen Input nicht verliert, oder muss ich zwingend die Laufzeit auf normalere Werte bekommen?
Grüße Daniel
Hallo Daniel,
temporäre Dateien, die im Rahmen eines Flow-Durchlaufs entstehen werden nach 4h weggeräumt. D.h. es gibt folgende Möglichkeiten:
a) Flow Laufzeit reduzieren (wäre uns am liebsten 
) bzw. dafür sorgen dass der Step, der den cachedSpreadsheetFilter konsumiert, 4h nach dem Filter fertig ist. Evtl. könnte man es in 2 Flows auftrennen und irgendwie mit Datastores als Zwischenspeicher arbeiten.
b) evtl. könnte folgender Workaround helfen: Du packst nach dem ersten langen Step (PlentyUpdateVariations) noch einen Mapper oder Filter mit enableCache=true, welcher das Ergebnis des ersten Filters nimmt. Dadurch (enableCache) wird eine neue temp. Datei erzeugt. Das Ergebnis dieses davon gibts du dann in den PlentyAddPropertyToItem rein.
Wie genau sieht die Bedingung aus? Siehst du im Eventlog schon, wo die meisteZeit verbraucht wird? Ist das in den plentySteps? Wenn du im Filter den Cache aktiv hast, dann solltest du beim Filter-Step sehen, wie lang der läuft. Wenn das im Bereich von Sekunden / Minuten liegt, dann ist vermutlich nicht deine Bedingung schuld.
Optional kannst du dich auch per Support-Ticket mal an melden und wir schauen uns mal den Flow an, ob uns Optimierungspotential auffällt.
Ich bin jetzt heute noch nicht dazu gekommen effektiv am Flow was zu ändern, aber das mit dem gecachten Zwischenstep werde ich probieren 
Naja, ich hab am Ende eine Prüfung ob sich an den Artikeln irgendwas geändert hat. Da hab ich aus Versehen auf eine Zwischen-Variable geprüft anstatt auf die endgültige, seit dem das „richtig“ läuft, sind es einfach zu viele Daten 
Hintergrund ist ein neuer Marktplatz der dazu kam, und der jetzt eben für jeden Artikel ein „da hat sich was geändert“ ergibt. Ich versuch das jetzt mal in kleineren Stückelungen (10k) laufen zu lassen, in der Hoffnung das mein Gesamt-Ergebnis sich so bei jedem Durchlauf ein bisschen reduziert, bis ich wieder auf dem Stand bin dass das ganze in annehmbarer Zeit durchläuft.
Ich berichte 
Hallo @samenhaus-admin,
wir haben die 4h auf 6h erhöht. Ich hoffe das hilft dir weiter.
VG Torsten
1 „Gefällt mir“