ich steh da wohl irgendwie auf dem Schlauch mit meinem Problem.
In einem Mapper habe ich folgende Werte die als einfacher String in der Spalte ankommen
Wie man sieht ist der eine mit „Leerzeichen“ und der andere mit " " zwischen den Wörtern.
Im Browser sieht es bei beiden OK aus.
Aber wenn ich jetzt substring_word(TEXT, 65) anwenden möchte wird der untere Wert als EIN Wort erkannt und gibt 0 zurück wenn er kürzen muss
Versuche mit replace(’ ', ’ ’ ) das Problem zu lösen, schlug fehl.
Hat einer eine Idee wie ich dies Problem angehen kann?
du müsstest an der Stelle deinen Input bereinigen.
Die Idee mit dem Suchen und Ersetzen ist an der Stelle nicht falsch.
Versuch es mal mit ${substring_word(TEXT?replace(" ", " "), 65)}
vielen Dank, doch leider hat das nicht geklappt.
Dies hatte ich auch schon probiert nur Leider hab ich diesen Code HIER nicht als Code geschrieben.
Irgendwie erkennt das System nicht dies hier
>
Die Ursache konnte ich ermitteln. es ist diese Funktion
deduplicate(Titeltranslated!?split(" "))
die den falschen String erstellt beim entfernen von doppelten Wörtern. Den Fehler konnte ich beheben, aber die bereits erstellten Daten kann ich nicht korregieren.
Ja, ich bewege mich nur innerhalb von Synesty. Denn am Ende ist dort der Fehler vor PlentySetItemText.
Eigentlich klärt sich alles von selbst, ist ja kein Hexenwerk, aber bei mir klappt das nicht. Was aber klappen sollte.
Also wenn ich das jetzt richtig verstehe wird im Mapper als Wert ohne nbsp angezeigt, wenn du aber im Chrome per Inspect Element dir das anschaust, wird es mit nbsp angezeigt?
Das habe ich so noch nie gesehen und kann ich nicht reproduzieren.
Das Einzige was ich da noch einmal vorschlagen würde wäre, dass ich mir das einmal genauer anschaue (mit entsprechendem Zugang).
Ansonsten kann nur der Synesty Supper an der Stelle helfen
VG
Stefan
Kleiner Hinweis:
Versucht mal die Quelldaten als CSV-Datei zu exportieren. Nur dort steht die Wahrheit drin.
Verlasst euch nicht drauf, was der Browser oder Inspect Element anzeigt.
Weitere Frage @noIT-Service : Wo kommen die Quelldaten her? Kommen die evtl. schon so an?
Moin,
die Quelldaten kommen so aus Plenty ‚PlentyGetVariations‘.
Ich kann die ja dann gleich mal in eine CSV packen.
Nachtrag: In der CSV ist kein   drin, eine Step-Vorschau von PlentyGetVariations schon!!!
Als Ursache für dieses Verhalten, habe ich die Funktion deduplicate ausfindig machen können.
Wenn die Funktion arbeiten muss, also doppelte Werte entfernen, dann kam der komische String raus.
Allerdings hat ja @sHelme dies mit seinem Test widerlegt.
@sHelme Zugriff darf ich dir vom Kunden aus nicht gewähren.
Wir würden dem gern mal nachgehen, denn wir können nicht nachvollziehen, dass deduplicate() dazuerfindet.
${deduplicate(liste1)} gibt auch wieder eine List zurück, d.h. eigentlich müsste man ${deduplicate(liste1)?join(" ")} schreiben, wenn man das wieder mit Leerzeichen getrennt ohne eckige Klammern zusammenbauen will.
Kannst du bitte damit mal versuchen das Verhalten zu erzwingen? Also dort mal testweise deinen Inhalt der CSV Spalte reinpacken? Du sagst ja dass in der CSV noch keine drin ist. D.h. versuch mal bitte mit diesem Testflow das so hinzubekommen, dass da irgendwie ein drin steht.
Es scheint ein reines Anzeigeproblem der Stepvorschau-Tabelle zu sein. Die nbsp; sind nicht da.
Lokal auf unserem Entwicklungssystem hatten wir das Problem nicht gesehen, da es da in den letzten Tage vermutlich schon von einem Kollegen behoben wurde.
D.h. im Optimalfall wird der Fix auch heute oder morgen eingespielt.
Zusammenfassend:
Du kannst in dem Fall davon ausgehen, dass die nbsp; nicht existieren und das eigentlich Leerzeichen sind.
Wir behalten das im Auge und melden uns nochmal so bald der neue Stand live ist.
na ein Glück, dass ihr es nachvollziehen könnt.
Ich habe jetzt hier noch in den Test-Flow in der 2.Gruppe die Entstehung eingebaut.
Aber ihr habt es ja schon. bug2_FlowExport-Temporr-1-Click-Flow_181.json (9,9 KB)
In deinem Fall scheint es sich nicht um normale Leerzeichen zu handeln, sondern um unsichtbare Steuerzeichen, die nur aussehen wie Leerzeichen. Ein Texteditor oder Hexeditor könnte dir das zeigen.
Es war also alles nochmal ein Tick anders als gedacht
Aktuell scheint dieses Steuerzeichen durch „nbsp;“ ersetzt zu werden.
Der Fix, der kommt, macht diese Ersetzung nicht mehr. D.h. du siehst dann kein „nbsp;“ mehr.
ABER: Es ist immer noch ein unsichtbares Steuerzeichen welches kein Leerzeichen ist, sondern nur so aussieht. D.h. dein ?split(" ") wird auch weiterhin nicht funktionieren.
Du hast also quasi schon kaputte Daten, die du z.B. erstmal bereinigen müsstest - d.h. wieder echte Leerzeichen draus machen, damit dann Funktionen wie ?split(" ") auch wieder mit normalen Leerzeichen funktionieren.
Folgende RegEx könnte dafür funktionieren:
bei „Ersetzen durch“ muss ein normales Leerzeichen rein
Aber nach meinen Recherchen sind doch erst die Steuerzeichen durch die Funktion ‚deduplicate()‘ entstanden und dann in das PlentySystem übergeben worden?!
In meinem Falle habe ich jetzt die Funktion durch anderen Code ersetzt, die das erwünschte Ergebnis erstellt.
Ich werde es beobachten und bei nächsten Anwendungen im Auge behalten.
