Flow verliert tausende Zeilen, ohne dass ich filtern würde

Ich bin grad ratlos: mein Flow ruft ein paar zehntausend Artikel ab, und schiebt sie durch viele viele Steps.

Endsumme sollte egtl um die 24k Zeilen sein. Dann mach ich einen ColumnRemover, und auf einmal sind es nur noch sechs? :astonished:

Wie kann das sein? Ich dachte schon in einen Bug im ColumnRemover, aber ich kann zumindest sagen, dass ich keine Spalten entferne, die es nicht gibt. Ich entferne mit Wildcard *, das ja.

Aber so oder so: Spalten zu entfernen sollte nicht die Zeilen reduzieren?

Es greift hier ein Step in den nächsten, keine Sprünge oder Umwege:

2023-07-21 00_52_02-Step Configuration - Synesty Studio - https___apps.synesty.com_studio_jobControl

Habt ihr sowas schon mal gesehen? Der Flow läuft seit Monaten stabil. Ich hab ein paar Spalten zugefügt, davor, aber daran kanns doch schwer liegen?

Fatal: wenn ich mit VariantenID-Filter teste, klappt alles. Start-Artikel kommt am Ende an, wird geschrieben. Wenn ich mein Limit wieder auf 250000 hebe, passiert das. Natürlich kommt dann auch nichts an.

Ich schreib mir jetzt mal ne CSV vom makeNumber-Mapper, berichte morgen was raus kommt.

Danke, Daniel

Was kommt nach dem makeNumber Mapper? bzw. welcher Step konsumiert den?

Die processed rows: 6 deuten darauf hin, dass ein nachfolgender Step nur 6 Zeilen aus diesem Mapper „rauszieht“ und dann aufhört. Als Beispiel: das würde passieren, wenn du nach dem makeNumber einen CSVWriter mit Limit=6 machst.

Es könnte aber auch sein, dass ein voheriger Filter am Anfang der Kette (der schlussendich auch beim makeNumber landet) nur 6 Zeilen durchlässt, so dass beim makeNumber nicht mehr als 6 Zeilen „vorbeikommen“.

Könntest du bissl mehr vom Flow per Screenshot zeigen, so dass man davor und danach sieht?

Weiterer Gedanke:
Eventuell mal den „setDefaults Mapper“ cachen (cacheMode aktivieren). Könnte sein das der mehrfach „konsumiert“ wird und dadurch die processed rows so hoch ist. (Siehe auch).

Eigentlich nicht. Es sein denn irgendwas wurde umbenannt und ein Filter macht plötzlich irgendwas anders. Oder die Quelldaten sehen plötzlich anders aus als früher… (Rein hypotetisch: wenn ein Lieferant plötzlich seine Spalten umbenennt, dann greift natürlich plötzlich kein Filter mehr, weil früher Annahmen über Spaltennamen nicht mehr stimmen. )

Ja das ist eine gute Idee.

Ich kam jetzt heute zu (fast) nichts bzgl Prüfung, aber kann noch ein paar Details nachreichen. Es war schon sehr spät gestern:

Hab ich gemacht, es kommt nur genau ein Artikel überhaupt an: die Variante ID 1001.
Das ist der erste Artikel, der aus der API purzelt (die 1000 ist inaktiv). Alles danach wird verworfen :astonished:

Ich kann das Verschwinden auch schon per Vorschau eingrenzen:

  • der „Pflanzen gemischt Mapper“ gibt mir noch fünf Ergebnisse (vermute der Rest wurde vorab weggefiltert)
  • der darauf folgende „setDefaults Mapper“ hat dann plötzlich nur noch eine Zeile

Der setDefaults ist auch einer der Steps, die ich kürzlich überarbeitet habe. Spalten umbenannt, zugefügt, bisschen Freemarker-Skripting direkt im Wertfeld. Aber wie führt das dazu dass Zeilen verschwinden?

Hauptsächlich passiert darin sowas
<#assign default = "DEFAULT_" + _sourceTitle!>
<#assign old = "OLD_" + _sourceTitle!>
<#if (row[old]! == "" || row[old]! == "NOT_FOUND")>
  ${row[default]}<#else>${row[old]}
</#if>

Also ich habe drei Spalten

  • Foo
  • DEFAULT_Foo
  • OLD_Foo

Und befülle Foo mit dem Wert von OLD wenn vorhanden, und ansonsten mit dem DEFAULT.

Gleich zwei, jeweils in ner eigenen Gruppe:

  • ein Segment das prüft ob Foo (und ne handvoll andere) sich geändert hat im Vergleich zu OLD_Foo, und wenn ja geht das in einen PlentySetVariationProperties sowie PlentyUpdateVariations. Ende.
  • danach gehts mit der eigentlichen Verarbeitung weiter, ein paar Filter, viele Mapper. Danach weitere Gruppen. Aber hier ist ja schon leer.

Erster Step ist bei der ersten Gruppe ein Mapper, und bei der zweiten ein Filter, der auf leeren UVP prüft. Der sollt von ausreichend Varianten erfüllt werden.

Sehr komplexes Ding, ich versuchs mal:


Vor dieser Gruppe kommen nur „geschlossene“ Gruppen, die am Anfang was abrufen, und es am Ende in einen Datastore schreiben.

Du siehst: ich hab jetzt den makeNumber-Step auf Cache gesetzt, es ist definitv der der mehrfach konsumiert wird.

2023-07-21 16_06_23-Step Configuration - Synesty Studio - https___apps.synesty.com_studio_jobControl
Das ist der erste Konsument, abgeschlossene Gruppe

Hier geht dann der eigentliche Ablauf weiter.

Danach kommt eine Debug-Gruppe (schreibt CSV von was ich grade brauche), und zwei Gruppen die Eigenschaften bzw Preise setzen, jeweils noch mal mit nem Filter.


Ich hab jetzt auf jeden Fall mal:

  • eine CSV vom setDefaults geschrieben
  • den Cache im makeNumbers aktiviert.

Ich stoß das jetzt mal an, das dauert sicher einige Stunden, bis dahin bin ich afk, ich meld mich dann später/morgen/Montag wieder mit was ich raus gefunden habe.

Bis denn, Grüße & schönes WE
Daniel

Ist das eine der Überarbeitungen?

Evtl. mal in der Spalte die Textfunktion „Trimmen und Zeilenumbrüche“ prüfen. Weil die Leerzeichen und Zeilenumbrüche im Skript werden normal rausgeschrieben. D.h. wenn man dann einen Vergleiche anstellt, und nicht trimmt, dann könnte eine Bedingung schonmal fehlschlagen. Weisst du sicher, aber nur der Vollständigkeit halber.

Schau dir mal deine Debug CSV Dateien auch hinsichtlich Leerzeichen, Tabs und Zeilenumbrüchen (oder gar unsichtbarer Sonderzeichen). Manchmal kann einem ein unsichtbares durch Sonderzeichen (auch im Wert-Feld z.B. durch Copy-Paste ) das Leben schwer machen.

EDIT:

Sind das Quellspalten? Wenn ja , dann passt dein Script.

Oder benennst du die erst im gleichen Mapper so?
Weil dann müsstest du result[old] statt row[old] nehmen (Ergebnisspalten)

Bei Ergebnisspalten musst du auch drauf achten, dass diese erst rechts der Spalte bekannt sind (mit anderen Worten: man kann result['ergebnisspalte'] nur in einer Spalte rechts von ergebnisspalte machen). Da Foo in deiner Aufzählung als erstes kommt, könnte das ein Problem sein. Müsstest Foo ans Ende schieben.

Oh je, es war noch viel simpler :man_facepalming:

Ich hatte im betreffenden setDefaults-Mapper eine Gruppierung aktiv. Für eine Zeile die für alle Artikel den selben Wert enthält. Klar kommt dann nur noch eine Zeile raus :grimacing:

  1. gibt es für Gruppierung einen Shortcut den ich aus Versehen gedrückt haben könnte? Ich kann mir fast nicht vorstellen dass ich mich wirklich unbeabsichtigt bis an den Punkt durchgeklickt habe :sweat_smile: (Aber ausschließen mag ichs nicht. Wie gesagt: es war spät)

  2. es wäre vermutlich nett, wenn der Hinweis auf Gruppierung bereits links in der Step-Übersicht erscheinen würde (wie ein Filter oder Variable), und nicht nur rechts in den Step-Details. Also bei (1) statt bei (2)

Auf jeden Fall: Problem gelöst, ich war doof :smiley:
Grüße Daniel

1 „Gefällt mir“

Nein.

Das haben wir zusammen mit dem hier aufgenommen und planen es mit ein.

2 „Gefällt mir“

Ist ist jetzt eine Änderung live. Bei einem Mapper mit aktivier Gruppierung wird jetzt am Step so ein Badge angezeigt mit „G: Gruppierspalte“.

image

1 „Gefällt mir“