Zeichenbeschränkung für MAP-Spaltenschema

Hallo zusammen,


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?

Vorab vielen Dank für hilfreiches Feedback!


Gruß,

Marc

Hallo Marc,


kannst du uns sagen wie viele Zeichen der größte Wert in etwa hat ?


VG Torsten

Guten Morgen Torsten,


einer der größten Werte hat 5.723 Zeichen.


Gruß,

Marc

Hallo Marc,


wir haben das nochmal besprochen und das Limit auf 10.000 erhöht.


Viele Grüße

Torsten

Mega!


Vielen Dank für den ausgezeichneten Support. Mit einem solch hohen Limit können wir die VariationProperties nun in einem ganz anderen Ausmaß nutzen.


Gruß,

Marc

Guten Morgen Team,


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.


Gruß,

Marc

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...


Alles klar, schon einmal danke fürs prüfen!


Gruß,

Marc

Hi Team,


konntet Ihr hier schon einen Grund für das Verhalten rausfinden?


VG,

Marc

Sorry für die späte Antwort.


Leider können wir aktuell nur einen Workaround mit RegEx anbieten.

Das Problem sitzt leider sehr tief und wir haben leider noch keine Lösung.


Kannst du uns ggf. mal einen Beispielwert einer solchen Eigenschaft vom Typ TEXT schicken? Vielleicht können wir dann bei der RegEx assistieren.


Guten Morgen,


im Anhang als Fallbeispiel einer der problemhaften Einträge.

Hallo Marc,


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.



Hallo Marc,


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, der Workaround funktioniert bei uns einwandfrei.


VG,

Marc

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.

Die Lösung per JSON erscheint mir super, schön dass die so schnell kommen soll.


Bis dahin Ergänzung zum Workaround oben: der matcht nicht nur auf "685=", sondern auch auf "1685=" u.ä. (bei mir konkret: auf 13 statt 3).


Ich habe selbst nur begrenzt Ahnung von RegEx, aber Stack Overflow sei dank trotzdem eine Lösung ;-)


(?:^|;) matcht für "entweder Start des Strings, oder Semikolon", so dass mit

<#assign res = result['Beispiel']?matches("(?:^|;)685=(.+?)(?=;\\d+=|$)")><#list res as m>${m?groups[1]}</#list>

tatsächlich nur Property 685 ausgegeben wird, und keine Verkettung von allen IDs die auf 685 enden.


Gruß & schönes WE,

Daniel

Hallo zusammen,


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


${VariationPropertyIDsJSON.at("ID Eigenschaft")} 


bzw.


${ VariationPropertiesJSON.at("Backendname Eigenschaft")}


zugreifen.


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.


Viele Grüße

Torsten

Guten Morgen,


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.


image


In der Schema-Validierung erhalte ich nun aber auch Fehler aufgrund eines zu großen Map-Keys bei diversen Varianten:


image


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


0b574e42-f39c-11ea-a408-901b0ed5b6cc

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:


498c5eef-f3f3-11ea-95d4-901b0ea49fee

Die Einstellung im Datastore haben wir vergessen zu erwähnen:


Schau mal, dass du die Spalte im Schema auf Art des Inhalts=JSON umstellst.


Wir reichen das auch noch im Handbuch nach.