Regex-Problem

Hallo, ich möchte per FileFindAndReplace ein paar Zeichen aus einer Datei löschen. Egal wie ich's anstelle, am Ende macht der Parser es leider immer falsch. Hier ein Teilstring:


es/461296"}]}}],[{"id":


Es geht um die eine schließende und die nächste öffnende eckige Klammer. Egal was ich probiere, es geht nicht. In Notepad++ habe ich vier korrekte Ersetzungswege gefunden, die alle klappen. Nur euer Parser macht was er will ;-)


Der vermutlich sauberste und komplizierteste Ansatz von mir wäre:


Suchen: (.*)([\]]+)(,+)([\[]+)(.*)

Ersetzen: $1$3$5

Ergebnis in NP++: es/461296"}]}},{"id"


In NP++ klappt das auch, wenn ich die maskierten Klammern nicht extra noch in eckige Klammerpaare packe - da schreit euer Parse "Fehler", aber egal. Wenn ich es ihm so gebe wie geschrieben, ist im ausgegebenen File zu sehen:


es/461296"}]}}]
[{"id":


Er läßt also die eckigen Klammern drin und ersetzt stattdessen das Komma durch nichts.Außerdem haut er noch einen Line Feed rein:



Ich komme leider nicht weiter...


Gruß Micha




Guten Morgen Micha,


ich habe Dein Problem mit den angegebenen Werten im Studio nachgestellt. Mit Datei und dem Teilstring sowie den StringToFile Step kommt jeweils das von das erwartete Ergebnis heraus.


Datei mit dem Inhalt: es/461296"}]}}],[{"id":

wird zu: es/461296"}]}},{"id":


Ist möglicherweise ein falschen Encoding ausgewält (Default ist UTF8)?!



Viele Grüße,


Rocco

Hallo Rocco,

irgendwas ist schief. Ich habe mir das Ganze eben nochmal angesehen, BEVOR der FindAndReplace-Step zum Einsatz kommen soll. Kurzer Hintergrund: Der String kommt aus einem APICall-Step. Wenn ich den in der Vorschau ansehe, sieht es so aus:

image


Als Nächstes kommt der StringToFile-Step, der dann die Basis für den FileAndReplace-Step ist: Wenn ich mir dieses File aber mit einem SendMail-Step zusenden lassen will, ist es leer. Das habe ich nochmal überprüft, indem ich bei diesem Step die Option gewählt habe, daß er die Mail nicht senden soll, wenn der Anhang leer ist. Das ist das Ergebnis des Runs an der Stelle:


image


Die Datei IST aber nicht leer, wenn ich sie mir vorher in der Vorschau des StringToFile-Steps ansehe:


image

Wenn ich die runterlade, sieht sie so aus:


image


Ich glaube also, daß der Fehler hier nicht beim FindAndReplace-Step liegt, sondern schon vorher.


Könnt ihr das so bearbeiten, oder braucht ihr ggf. Zugang zum Account?


Gruß Micha

Die responses sind nur in der Vorschau sichtbar (siehe Output Beschreibung) und nur zum Debugging. Deshalb ist die bei einer echten Ausführung leer.

Im APICall muss du deine Response in ein Spreadsheet umwandeln (siehe Beispiel-parsingTemplate) und dann weiterverarbeiten.


Von dem Teil der in deinem Screenshot erkennbar ist könnte folgendes ParsingTemplate ein Startpunkt sein:


<#assign row = target.addRow()>

<#list json as order>
 <#assign row = target.addRow()>
    ${addColumns(row, order)}
</#list>


Im ersten Screenshot sieht man doppelte eckige Klammern (also Array im Array). Kann es sein, dass du damit Schwierigkeiten hast, die zu parsen?


Probier es mal hiermit:


<#assign row = target.addRow()>

<#list json[0] as order>
 <#assign row = target.addRow()>
    ${addColumns(row, order)}
</#list>



Der Unterschied zum Vorherigen ist das json[0]

Damit nimmst du dir das erste Element des ersten Arrays. Danach sollte die Weiterverarbeitung klappen wie mit addColumns beim JSON2Spreadsheet.


Oder schick mal deine komplette Response (sensitive Daten bitte entfernen). Dann können wir dir vielleicht einen Tip geben, wie die zu verarbeiten ist.

Danke für die Hilfe! Ich habe es jetzt mit Hilfe des Steps "StringFindAndReplace" gemacht. Es war ganz schön zermürbend, aber letztlich erfolgreich. Auch das Thema mit der doppelten eckigen Klammer war ein Stolperstein - hatte ich dann irgendwann selbst entdeckt; ich hätte mal zwischendurch meine Mails lesen sollen, dann hätte ich DeinenTip mitbekommen ;-) Jetzt ist jedenfalls alles rund, besten Dank nochmal!


Gruß Micha

Hallo Micha,

wir vermuten dass sich dieses Problem auf https://synesty.freshdesk.com/support/discussions/topics/11000025946 bezieht.


Nur der nett-gemeinte Hinweis: Versuch bitte nicht mit dem Responses-Output aus dem APICall Step zu arbeiten und irgendwas mit RegEx zu machen. StringFindAndReplace und RegEx klingt fast immer nach einem Hack.


Die doppelten eckigen Klammern sind nur ein Phantomproblem und eigentlich gar nicht da. Sie kommen nur durch die Debugging Ausgabe von uns zu Stande. D.h. es ist eine reine Anzeige-Sache bei der Step-Vorschau. Die Responses zeigen wir nur bei der Step-Vorschau an, damit man mal eine Vorstellung bekommt, was vom Server als Antwort kommt und man weiss, was man im parsingTemplate machen muss. Die doppelte eckige Klammer kommt nur zustande, weil wir die Einzel-Responses vom Server in ein List-Objekt packen und dann ausgeben. Durch die Ausgabe der Liste erzeugt aussen herum noch mal eine eckicke Klammer. Aber wie gesagt, dass ist eine reine Anzeige-Sache.

Bei der echten Flow-Ausführung ist der Output responses leer.


Schick gern noch mal eine Beispiel-Response und wir versuchen, dass wir dir ein sauberes Grundgerüst zeigen, das du beim parsingTemplate im APICall nutzen kannst und ein ordentliches Spreadsheet erhältst. Die Response sieht nach Auftragsdaten aus. D.h. vermutlich ist es zweistufig (Order und OrderItems). Für sowas ist der APICall gedacht und wir haben sowas schon oft gesehen.