Dank dir. Das ist wirklich seltsam.
Wir versuchen dem auf die Spur zu kommen.
Kannst du bitte nochmal den Requestbin-Ansatz probieren:
1. gehe auf http://requestbin.net/ und erstelle ein Bin (entferne die checkbox). Das ist wichtig, damit du uns dann die URL schicken kannst, damit wir das untersuchen können. Gern per Ticket.
2. Dadurch kommst du auf eine Seite die dir eine URL zeigt.
An diese URL schickst du deinen Request. Den Browser lässt du auf dieser Seite geöffnet.
a) Request per POSTMan
b) und per Synesty (dazu diese URL bei Host eintragen)
3. Im Browser klickst du dann mal Neu Laden, und dadurch solltest du dann die Requests sehen, die per PostMan und Synesty geschickt wurden.
4. Nach dem du das gemacht hast schickst du uns per Ticket die URL die URL in deinem Browser 
Dadurch können wir dann auch sehen, was du dort hingeschickt hast.
Vorteil davon ist, dass wir durch Requestbin eine verlässliche Source-of-Truth, und sehen was auf der Gegenseite ankommt. Die ganzen Logfiles sind zwar auch ok, aber die zeigen eben nicht die Gegenseite sondern nur aus Perpektive der sendenden Partei.
Hallo Micha,
ich habe gerade nochmal den Postman Log mit dem HTTP Log von uns verglichen. Mir ist noch aufgefallen, dass PM den Parameter offenbar noch die Leerzeichen durch + ersetzt ( URL encoded). Im HTTP Log von uns sind die Leerzeichen vorhanden, da es nicht automatisch url encoded wird.
PM Log :
Flow HTTP Log:
Kannst du eventuell nochmal versuchen um den aktuellen "load" Wert noch die Template Funktion urlEncode zu packen. Das sollte dann in etwa so aussehen:
${urlEncode(encodeBase64(xmlData, "UTF-8"))}
Danke für die Rückmeldung. Vielleicht wars das von Anfang an.... Wir schauen uns auch noch mal an, dass wir auch bodyContentType=application/x-www-form-urlencoded mit Key-Value Paaren unterstützen und dass diese dann automatisch URLEncoded werden. Müssen nochmal in die Spec. schauen.
Kann es sein, dass du evtl. bei jedem Call immer wieder den gleichen Datensatz erwischt und diesen immer wieder überschreibst? Dadurch sieht es evtl. so aus, als klappt es nur beim letzten.
Wir reden auch vom SpreadsheetURLDownload (SSUD), richtig? weil nexturl() gibt es da gar nicht. nexturl() gibt es nur beim APICall.
Beim SSUD musst du ggf. auch auf den host (also die URL) achten. Ggf. muss dort auch noch ein Wert aus einer Spalte rein.
- Wie genau sieht denn dein RequestBody aus? und wie ist deine batchSize eingestellt?
Diese Doku-Seite beschreibt das nochmal. Vielleicht kannst du anhand der dort erwähnten Vorlage mal ein Beispiel bauen und gegen Requestbin schicken.
Es ist schwer nachzuvollziehen. Kannst du Screenshots oder ähnliches schicken?
"wenn die Logik nicht im Body, sondern im Headers steht"
Wenn du sowas schreibst: kannst du den Feldinhalt der beiden Felder hier schicken?
Das sind erstmal 2 getrennte Felder, die nichts mit einander zu tun haben. Die werden so wie sie sind übermittelt.
Hallo Micha,
wir können dir leider gerade nicht wirklich folgen. Im SpreadsheetUrlDownload Step entspricht die Anzahl der Calls immer der Zeilenanzahl deines Input Spreadsheets (bei batchSize = 1). Eine extra Logik für die Ausführung gibt es im Gegensatz zum API Call Step nicht.
So wie es in deinem Request Body angeben ist, wird pro Call jeweils der Wert aus der Spalte "base64_Neu" für dem "load" Parameter verwendet. Wir haben das auch gerade nochmal für POST und multipart/form-data getestet und es hat funktioniert.
Den Request Body solltest du auch schon in der Vorschau des SpreadsheetUrlDownload Step sehen. Der Wert für "load" sollte sich in der Spalte requestBody in den einzelnen Zeilen unterscheiden.
Viele Grüße
Torsten
