Neues Thema starten

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


2 Personen gefällt dies

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. 

txt
(370 Bytes)

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. 




1 Person gefällt dies

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. 


1 Person gefällt dies
Anmelden um einen Kommentar zu veröffentlichen