Shopify, KeyValueSpreadsheet <> DatastoreWriter: "identifier must not be null or emtpy"

Fragen und Antworten
1

Hallöchen zusammen,

wir haben in unseren Flows zum Aktualisieren von Shopify-Artikeln ein Problem damit, die aktualisierten Artikel als „fertig“ zu markieren.

Da sich mehrere Stores, die über verschiedene Verbindungen laufen, an demselben Datastore bedienen, können wir nicht mit dem Processing Status arbeiten.
Wir behelfen uns daher mit einer Spalte „Shops2Update“ im Datastore, die mit einer kommagetrennten Liste von Shop-Kürzeln gefüllt wird, wenn ein Artikel in bestimmten Shops aktualisiert werden soll.
So werden nur diejenigen Artikel an Shopify geleitet, die das entsprechende Shop-Kürzeln hinterlegt haben.

Dieses Kürzel soll auf Basis des „successfullyUpdatedProductInformation“-Outputs des „shopifyUpdateProductInformation“-Steps am Ende des Flows entfernt werden.

Da der identifier im Datastore unsere interne Artikelnummer ist, nutzen wir ein KeyValueSpreadsheet, um die Zuordnung zur entsprechenden Shopify Product-ID vorzunehmen.
Das KeyValueSpreadsheet wird für alle „geeigneten“ Artikel des Shops angelegt (maximal ~13000).
Key ist die im Datastore hinterlegte Shopify-ID des entsprechenden Shops, Value ist unsere Artikelnummer.

Im DatastoreWriter wird die Artikelnummer aus dem KeyValueSpreadsheet herausgesucht und als identifier genutzt.

Hier kommt es nun häufiger vor, dass wir die Warnung
Error writing to datastore in row X (identifier: ): Identifier must not be null or empty.
erhalten.
Wenn diese Warnung auftritt, sind es immer genau 11 Errors. Welche 11 Artikel das sind, können wir aufgrund des „fehlenden“ identifiers leider nicht nachvollziehen.
Auch ist uns aufgefallen, dass in diesen Fällen weniger Artikel überschrieben werden, als ursprünglich aktualisiert worden sind.

Manche Flows laufen auch ohne die Warnung durch.

Da es einen StopFlowIf gibt, der greift, wenn es keine zu aktualisierenden Artikel mehr gibt, können wir nachvollziehen, dass scheinbar trotzdem alle Artikel ihr Update bekommen, da die Stopp-Bedingung irgendwann anspringt.

Lange Rede, kurzer Sinn: wo liegt der Fehler/das Problem, dass wir die o.g. Warnung erhalten? ODER ist es nur ein Darstellungsfehler/Bug beim Log des DatastoreWriter-Steps, da trotzdem alle Artikel den Marker entfernt bekommen?

Ich hoffe, man konnte die Erklärung einigermaßen nachvollziehen :smiley:

Liebe Grüße und danke für jede Hilfe!

2

Hallo @luchs,

als erstes würde ich einmal empfehlen dem Fehler mit den 11 Artikeln ohne identifier auf die Spur zu gehen.

Wie du das „relativ“ leicht debuggen könntest ist, vor dem Datastorewirter ein Mapper zunehmen mit der gleichen Konfiguration wie der DatastoreWrtier, also Mappingdefinition und Input.

Für die Mappingdefition vom DSWriter kannst du dir die einfach aus dem Json unterhalb der Definition kopieren.
image

Diese kannst du dann in den Mapper kopieren, wobei du vorher einmal die Konfiguration des Mappers geöffnet haben musst, dass es angezeigt wir und du es reinkopieren kannst.

Anschließend noch einen CSVWriter nach dem Mapper und einen StoreDebugFile und du kannst den Flow das nächste mal ausführen und im Eventlog kannst du dann man StoreDebugFile die CSV herunterladen, die auch im DSWriter geschrieben wurde mit den 11 Artikeln ohne identifier.

Ich hoffe das bringt dann schon mal Licht ins Dunkle.

Viele Grüße
Lukas

1 Like
3

Hi @synesty-Lukas,

danke für die schnelle Rückmeldung!

Wir haben die Zwischenschritte eingebaut und festgestellt, dass weitaus mehr als 11 Artikel einen scheinbar fehlenden identifier haben (bzw. der identifier nicht über das KeyValueSpreadsheet gefunden werden kann).

Da das KeyValueSpreadsheet sich aus dem Pool an „geeigneten“ Artikeln bedient, wird der Fehler wohl dadurch auftreten, dass diese Artikel, die über einen Filter-Step herausgesucht werden, nicht mehr als „geeignet“ gelten, wenn das KeyValueSpreadsheet den Filter aufruft.
Warum das so ist, müssen wir noch herausfinden…

Wir haben uns nun beholfen, indem wir bei dem Filter-Step den Cache-Modus für den positiven Output aktiviert haben.
Jetzt laufen alle Flow-Runs ohne die Warnung und durch.

Liebe Grüße!

4

Hallo @luchs,

freut mich, dass du den Fehler finden konntest. Tatsächlich wäre der Cashemode beim Filter mein nächster Vorschlag gewesen.
Kann man sich eigentlich gut merken, sobald zwei oder mehrere Steps auf ein und den gleichen Filter/Mapper zugreifen, empfehlen wir den Cashemode zu aktivieren.

Viele Grüße
Lukas

1 Like