Flow "verliert" scheinbar Werte für Identifier, läuft durch, schreibt aber nichts ins System?

Fragen und Antworten
1

Hallo Synesty,

ich habe kürzlich den Flow checkMHD komplett auf REST umgestellt, und hab mir dabei scheinbar was zerhagelt?

Issn komplizierter Flow mit vielen Verzweigungen, aber mein Testcase ist simpel:

  • Steps 1 - 4 sind irrelevant
  • Step 5 ruft testweise nur ItemID 2 per PlentyGetVariations ab.
  • Was jetzt geschieht, ist dass der Artikel auf Basis von Freitextfeld2, das einen Timestamp enthält, durch die Filterkaskade läuft. Dessen Wert ist "01/2019":
  • Von Step 5 durch (ohne 13/14/15/16) bis 21.
  • Der Querverweis hier ergibt "good", so dass wir auch den Filter in 22 durchlaufen
  • über 25 zu 29
  • ab da läufts durch bis 34

Aus 34 speisen sich die folgenden drei REST-Steps, die Änderungen ins System schreiben (sollen) - und da scheitere ich!

Step 34 zeigt in der Vorschau keinerlei Probleme, aber Step 37 mit PlentyUpdateVariations, das direkt den Output von 34 verwendet, scheint dann seine ID-Spalten zu verlieren:

image

Und entsprechend kommt auch nichts in Plenty an, wenn ich den Flow durchlaufen lasse. Es wird aber weder Warning noch Error gemeldet, auch die Vorschau (Bild oben) meldet Success!

Um zu schauen ob das Problem an Step34 liegt, hab ich mir den auch nochmal per CSV schicken lassen (Step 57+58), und es kommt eine leere Datei dabei raus. Aber warum?

Das Verhalten tritt nur zur Laufzeit auf, und ich muss bis Step 20 zurück gehen, um Daten für meine Debug-CSV zu finden. Wenn ich auf Step 25 gehe bleibt die CSV leer, obwohl dort laut Log noch Daten ankommen sollten:

image

Auch die werden wohl bis weiter unten irgendwo "verloren". Ich bin echt ratlos :/

Danke, Daniel

2

Also irgendwie ist echt der Wurm drin!


Step 26 hat eine Spalte für die ItemID:

image


Ich kann die aber im DatastoreWriter Step 27 nicht als Identifier2 nutzen, wird nicht im Dropdown angeboten, und auch wenn ich es einfach eintrage landet es nicht im DS.

3

Ich hab mir den Flow aus meinen Backups wieder hergestellt, und alles was nicht (mehr) kompatibel ist deaktiviert, nennt sich checkMHD_OLD. Und *das* tut!

Nun war da der Input aber *auch* schon ein REST PlentyGetVariations, daran kanns also nicht gelegen haben. Vermutlich bekomm ich mein Problem also erst beim schreiben dann?

Mein Szenario bleibt das selbe: ItemID 2 läuft so durch die Filter, dass er bei newAbgelaufen endet. Konkret im Step 31 für checkMHD_OLD bzw in 34 für checkMHD_NEW. Sind identische Steps, die die Daten zum Import ordnen. Und wo ich früher drei dynamische Importe per SOAP gefahren hab, kommen jetzt PlentyUpdateItems, PlentySetItemTexts, PlentyUpdateVariations und PlentySetVariationsPrices sowie PlentySetVariationsCategories zum Einsatz. Und da scheitere ich -.-


4

Hallo Daniel,


so wie du es beschrieben hast ist vermutlich ein Mapping im DatastoreWriter (Step 27) hinterlegt, dass die Spalte ItemID nicht enthält. Das Mapping im DatastoreWriter verhält sich ähnlich wie ein 'normaler' SpreadsheetMapper vor dem DatastoreWriter. Alle Spalte die du nicht vorhanden sind werden nicht in den DS geschrieben und erscheinen auch nicht ich der Auswahl der identifier Spalten. Kannst du bitte im DatastoreWriter nochmal auf "Configure" klicken und die ItemID Spalte noch hinzufügen. Danach sollte sie auch in der Auswahl des identifier2 Spalte auftauchen.


VG Torsten



5

Hi Torsten,

der DatastoreWriter läuft jetzt, danke.!

Trotzdem scheitern meine schreibenden Calls in den Steps 35 ff. Laut Log hat Step 25 noch Daten, von dort gehts in den Filter 29, der geskippt wird, und dann verliert sich die Spur, Step 30 hat keine Daten mehr?

Ich verstehe auch nicht, warum die SpreadsheetMapper überhaupt so viele processed rows haben?

Gibt doch nur ein Item.


6

Heureka, ich habs zum laufen bekommen!

Es scheint (auch) am DatastoreWriter 27 zu liegen? Wenn ich den pausiere, verliert mein Ablauf seine Werte nicht mehr. Aber warum?

Um das nachvollziehbar zu lassen, hab ich den Flow jetzt in "checkMHD_kaputt" umbenannt ;-) Wenn du mir da vielleicht nen Tipp hättest, warum Step 27 verhindert dass die Informationen aus Step 25 über den Filter 29 weiter laufen?

Hats vielleicht auch was mit dem Filter 28 zu tun, der an dieser Stelle erstmal "nichts" tut, und erst sehr viel später (Step 41) wirklich abgerufen wird?

Irgendwo gibts side-effects die ich nicht auf derm Schirm hab...

7

Ich glaube sowas hattest du schon mal. Es liegt vermutlich daran, dass der DatastoreWriter Werte aktualisiert, die du dir in einem vorherigen SpreadsheetMapper per Querverweis holst. Kannst du bitte bei allen SpreadsheetMapper Steps (vor Step 27), die einen Querverweis auf diesen Datastore enthalten, die erweiterte Einstellung "cacheMode" aktivieren.

8

Ojeh! Ja, das hatte ich schon mal, du hast absolut recht -.-

Hat mit Cache jetzt funktioniert!


Ich hatte nachträglich im alten (funktionierenden) Flow den DatastoreWriter ausgeschalten, und dann hat der natürlich funktioniert! Ursprünglich war da auch der Cache ma gesetzt gewesen, wahrscheinlich auf deinen Hinweis.

Danke & schönes Wochenende!

9

Folgefrage:


Wär es sinnvoll für alle SpreadsheetMapper mit Querverweisen "präventiv" das Caching zu aktivieren, oder gibts dabei irgendwas zu beachten?


Gruß Daniel

10

Hallo Daniel,


das ist immer dann sinnvoll, wenn die Daten im Datastore durch eine DatastoreWriter innerhalb des Flows überschrieben werden. Zu beachten ist, dass die Parent - Variant bzw. Master - Child Relationen durch den aktivierten Cache Mode verloren gehen.


VG Torsten