Plenty-Abruf über dynamischen Export (SOAP) nur noch 3000 Zeilen

Fragen und Antworten
1

Hallo, ich rufe über PlentyGetDynamicExport Daten ab. Es werden aber nur 3000 Zeilen abgerufen, obwohl ich kein Limit gesetzt habe. Ich habe zur Sicherhheit denselben Export in plenty angestoßen und bekomme die standardmäßigen 6000 Zeilen exportiert.

Ich bin sicher, daß ihr nur 3000 Zeilen einlest, weil

.ich im Plenty-Step kein Limit gesetzt habe und

.ich in den Einstellungen des SpreadsheetMappers eine Zahl > 3000 für die Vorschau eingetragen habe und

.weil ich sicherheitshalber einen Filter als nächsten Step gesetzt habe, der mir einen Datensatz aus der Original-Plenty-Exportdatei jenseits der 3000. Zeile anzeigen soll - und der liefert ein leeres Ergebnis


Könnt ihr mal bitte schauen? Übrigens, mir ist schon klar, daß über kurz oder lang alles auf REST umgestellt werden muß, aber für kleiner m al-so-Zwischendurch-Sachen ist der dyn. Export wesentlich effizienter


Danke und Gruß, Micha


P.S. Ich habe euch als Benutzer angelegt. Der Flow heißt FS_LS_SKUCheck

2

Was passiert wenn du den Flow komplett ausführst? Da sollten > 3000 Zeilen kommen.


Das Limit mit den 3000 im Mapper (im Browser ... also Vorschau und SpreadsheetMapper Ansicht) ist so gewollt und wird auch nicht mehr hochgesetzt. Siehe hier. Die normale Flow-Ausführung sollte aber davon nicht betroffen sein.

3

Es wäre ja noch hinzunehmen, wenn man die wichtige Zeile, auf die es einem ankommt, nicht mehr in der Vorschau sehen könnte. Aber wenn ich explizit einen Filter nachsetze, um genau diese Zeile dann betrachten zu können, und der ein leeres Ergebnis erzeugt, wie soll ich denn dann etwaige Fehler finden können? Es geht mir ja darum, z.B. fehlerhafte Einträge in einer Spalte aufzuspüren und mir dann zu überlegen, wie ich diese ändere und dann die geänderten Daten nach Plenty hochlade. Wie soll das gehen, wenn ich diese Datensätze niemals zu Gesicht bekomme?

4

Hallo Micha,

bitte versuche mal folgendes:

Zieh dir den Export und lade Ihn als CSV auf nen FTP. Dann kannst du Ihn im Flow per SpreadsheetCSVReader laden.

Der CSVReader hat diese Begrenzung nicht.

5

Klar geht das, ist mir schon bewußt. Aber extrem nervig, daß ich dafür in Zukunft immer Extrasteps anlegen muß, um grundlegende Arbeiten im Flow ausführen zu können. Ich finde, da habt ihr einen echten Bock geschossen! Ich hoffe nur, daß diese Begrenzung auf SOAP beschränkt bleibt und ich dasselbe nicht demnächst auch bei Arbeiten in meinen Plenty-REST-Flows erleben werde - dann gute Nacht :-(


Sonst kommt von mir immer ein begeistertes ThumbsUp für Synesty - hier kommt zum ersten mal ein deutliches ThumbsDown!

6

Das Limit gilt generell mit Ausnahme SpreadsheetCSVReader und SearchDatastore.


Das Thema wird uns sicher noch etwas beschäftigen und wir sind auch zum Finetuning bereit, allerdings in Maßen.


Kurz zum Hintergrund:

Wir müssen unbedingt die Datenmenge, die im UI verarbeitet werden kann begrenzen. Deine Filter-Problematik zeigt einen Grenzfall, der technisch herausfordernd ist:


Beispiel:

Filter: articleID = "123"

Anzahl Artikel:


Wenn der von dir gesuchte Filter nur beim allerletzten Artikel zutrifft, muss vorher alles abgerufen werden. Das können nicht nur 3000 sondern auch mal 100000 Artikel sein. Je nach API-Geschwindigkeit blockiert das die Server, CPU und RAM. Das geht auf keinen Fall.


Deshalb haben wir entschieden das Limit auf 3000 Zeilen zu begrenzen. Diese Begrenzungen gibt es auch nicht erst seit heute, die gibt es schon immer. Nur nicht konsistent. Bei einigen Steps war es 25 bei einigen das was man eingestellt hat.

Warum 3000?

Im Thread kam der Vorschlag 1500. Wir haben mal intern unser Projektteam gefragt, wieviele Zeilen man so im Mapper braucht irgendwo zwischen 1000-3000 war so der Konsens. Das ist genug um die meisten Sachen zu machen.

Fakt ist: Wir brauchen eine Begrenzung. Wenn man im UI entwickelt, sollte man immer mit einem reduzierten Testdatensatz arbeiten.


Was wäre denn dein Vorschlag?



7

Ideal wäre es aus meiner Sicht, wenn man bereits vor dem eigentlichen Runterladen der Datensätze, also im Plenty-Get-Step selbst, Filter setzen könnte. So hätte ich im vorliegenden Fall z.B. einen Filter gesetzt "SKU?contains('error')". Gerade bei REST-Steps wäre das sowieso von großem Vorteil, denn dann müßte man auch generell bei viel weniger Daten herunterladen - man bekommt da ja teilweise gefühlte 100 Spalten, von denen man nur ein paar braucht. Wenn man da schon nicht festlegen kann, welche Spalten man überhaupt nur haben will, wäre zumindest ein Filter wie skizziert hilfreich. (Wenn man auch noch die Spalten wählen könnte, wäre es natürlich noch viel besser! :-) )

8

Ja, da sind wir bei dir. Leider ist das immer etwas von der verwendeten API abhängig. Wenn die API so einen contains-Filter hergeben würde, dann können wir diesen theoretisch auch nutzen. Sollte die API das nicht hergeben stehen wir wieder vorm gleichen Problem: Dann müsste der Step auch wieder alles herunterladen und im Code filtern. Das ist genauso wenig effektiv.


Wenn du uns mal ein paar konkrete Szenarien aufzeigst, können wir gern noch mal prüfen, ob es einige Calls zusätzliche Filter hergeben, die wir aktuell noch nicht nutzen.