die VariationProperties werden im Output des PlentyGetVariations Step als Key-Value Werte zurückgegeben. Die Limitierung von max. 1000 Zeichen pro Value stellt uns dabei vor Probleme, da wir Texteigenschaften mit weit über 1000 Zeichen verwenden.
Behelfsmäßig denke ich nun darüber nach, die entsprechende(n) Eigenschaft(en) als eigene Spalten mit Spaltentyp SINGLE zu führen um die Limitierung zu umgehen und richtig mit den eigentlichen Key-Value Spalten arbeiten zu können. Folgende Fragen stellen sich mir:
1. Wie benenne ich im Import die jeweiligen Keys um speziell nur diese in separate Spalten zu schreiben
2. Wie trage ich dafür Sorge, dass diese Keys und deren jeweiligen Werte NICHT in meinen Key-Value Spalten vom Typ MAP landen?
Oder hättet Ihr noch einen anderen Workaround als Idee? Ein weiterer Datastore?
wir nutzen seit gestern eine neue VariationProperty vom Typ Text. Nun haben wir aufgrunddessen in zwei Flows, zu sehen in den Flow-Runs 82de5f9a-e1d0-11ea-8719-901b0ed5b6cc & b18ccb80-e17c-11ea-8719-901b0ed5b6cc , Warnungen im Mapper, dass der Map-Key auf 255 Zeichen limitiert ist. Das wundert mich, da der Key "Lieferumfang" wesentlich kürzer ist. Und der Value hat weit weniger als 10.000 Zeichen.
Ich habe den Thread wieder ausgegraben, da es in die gleiche Kerbe schlägt.
Hallo Marc, wir schauen uns das an. Wir vermuten es liegt daran, dass evtl. in einer Eigenschaft ein langer Text mit HTML drin ist und dieser die Map "durcheinander" bringt...
vielen Dank für dein Beispiel. Wie schon geschrieben sitzt die Ursache für das Problem recht tief, sodass wir vermutlich länger für einen Fix benötigen werden.
Als Workarround kannst du folgende Freemarker Anweisung im Wert Feld verwenden:
<#assign res = result['Beispiel']?matches("685=(.+?)(?=;\\d+=|$)")><#list res as m>${m?groups[1]}</#list>
Das result['Beispiel'] kannst du mit deinem Spaltennamen ersetzen und die 685 durch die entsprechende ID für die du den Wert erhalten willst.
vielen Dank für dein Beispiel. Wie schon geschrieben sitzt die Ursache für das Problem recht tief, sodass wir vermutlich länger für einen Fix benötigen werden.
Als Workarround kannst du folgende Freemarker Anweisung im Wert Feld verwenden:
<#assign res = result['Beispiel']?matches("685=(.+?)(?=;\\d+=|$)")><#list res as m>${m?groups[1]}</#list>
Das result['Beispiel'] kannst du mit deinem Spaltennamen ersetzen und die 685 durch die entsprechende ID für die du den Wert erhalten willst.
Danke für die Rückmeldung. Wir haben jetzt auch einen ersten internen Entwurf für einen Fix. Diesen testen wir in den nächsten Tagen.
Wenn alles glatt geht, dann wird es so sein, dass vermutlich eine neue Spalte VariationPropertiesJSON aus dem Plenty-Step herauskommen wird. Bei dieser Spalte wird dann die MAP intern anders behandelt, so dass diese auch bei komplexen HTML-Strukturen nicht kaputt geht. Damit sollten dann VariationPropertiesJSON.at("meinAttribut") immer klappen.
Die bisherige Spalte VariationProperties können wir leider nicht mehr retten. Die bleibt so erhalten, aber ist - bei komplexem HTML-Inhalt - kaputt. Aber die ist ja bei vielen Kunden im Einsatz, und bei wem jetzt mit simplen Key-Value-Paaren funktioniert, der kann es auch weiterhin nutzen.
Wir melden uns hier mit einem Update in den nächsten Tagen.
seit heute sind die beiden neuen Spalten für die Varianten-Eigenschaften im JSON Format verfügbar (VariationPropertyIDsJSON und VariationPropertiesJSON). Wie schon weiter oben beschrieben könnt ihr auf einzelne Werte über
Wir haben uns dazu entschieden vorerst nur für die Varianten-Eigenschaften neue Spalten im JSON Format zur Verfügung zu stellen. Solltet ihr Probleme mit anderen MAP Spalten haben, könnt ihr euch gerne bei uns melden.
ich muss leider nochmal auf das Thema zurück kommen. Wir haben gestern die Quellen der Datastore-Spalten entsprechend angepasst, um die neuen Felder zu nutzen, siehe Bild.
In der Schema-Validierung erhalte ich nun aber auch Fehler aufgrund eines zu großen Map-Keys bei diversen Varianten:
Möchte ich auf diese Key-Value-Paare per
${VariationPropertyIDs.at("517")!}
zugreifen, wird ebenfalls wieder die Warning geschossen, das der Map-Key auf 255 characters limitiert ist, siehe Eventlog zu RunID
Nachtrag: Die genannte RunID ist falsch weil noch vor dem Update der Felder im Datastore gelaufen. Diese hier ist von heute morgen NACH Update des Datastores: