ich habe schon einiges gelesen, auch einen ähnlich gelagerten Thread, der aber offenbar zu keinem Ergebnis führte. jedenfalls: Ich muß eine PDF-Rechnung über die API an einen Marktplatz übermitteln. Der Call wird per POST übermittelt. Ich habe bereits in einem vorhergehenden Step für jede Zeile den jeweiligen payload zusammengestellt. Im folgenden SpreadsheetUrlDownload-Step steht dann im Body:
Die Response liest sich so, als ob keine Datei übermittelt wurde.
Entspricht dies wirklich einem Dateinamen, der in der Liste bei filesToUpload dabei ist?
Aus dem Bauch heraus, hätte ich jetzt dort noch ein .pdf am Ende erwartet. Aber kann auch sein, dass das schon in ${Document} drin steht. Das war in deinen Screenshots nicht ersichtlich.
schwer zu sagen woran es scheitert. Die Fehlermeldung kommt vom API Endpunkt und deutet darauf hin das die „multipart boundaries“ nicht vorhanden sind. Das bedeutet nicht, dass die Datei nicht gesendet wird.
Ich habe das gerade nochmal mit ähnlichen Testdaten probiert und konnte auf den ersten Blick kein Problem erkennen. Boundaries, Datei und request body sind vorhanden:
Eine Vermutung habe ich noch. Eventuell kann der gesamte request body nicht geparst werden, weil im JSON doppelte Anführungszeichen enthalten sind.
Kannst du bitte mal im requestBody probieren noch ein ?json_string an myjsonpayload hängen
Hallo Torsten, das klappt leider auch nicht. Können wir das mal vergleichen? Ich habe den Call über Postman erfolgreich absetzen können und grübele gerade über dessen Log und dem Run-DebugLog. Ich kaufe auch gerne Deine Dienstleistung ein, ich muß das jedenfalls umsetzen.
Ich sehe hier zwei ominöse Punkte: Es wird ja ein Mix aus xml im Body und dem pdf-File übermittelt. Wenn ich mir die Sektionen ansehe, fällt mir auf:
der Content-Type der einzelnen Teile in einem multipart request lässt sich im SpreadsheetUrlDownload leider (noch) nicht festlegen. Der BodyContentType bezieht sich im SpreadsheetUrlDownload auf den Content-Type im request header. Sobald eine Datei & ein Request Body vorhanden sind, wird es automatisch auf multipart/form-data gesetzt.
Kannst du im Postman den request bitte nochmal mit den Content-Types des SpreadsheetUrlDownload Steps ausprobieren? Erhälts du dann auch den Fehler?
Ich habe übrigens auch gecheckt, ob das Dokument wirklich hinterlegt wurde - das ist der Fall.
Außerdem: Ich habe in PM bei body content-Type statt application/xml mal multipart/form-data eingegeben - auch damit klappt es!! Das Problem muß woanders liegen. In PM kann ich leider nicht sehen, was da eigentlich genau mit dem pdf gemacht wird, anders als in eurem DebugLog. Ich stelle nur fest, daß PM einen boundary-Wert ausgibt:
Das Seltsame finde ich: Im DebugLog steht nichts von diesem ganzen Text drin (Failed to parse servlet…) außer dem 400 Bad Request. Ich kenne mich in dieser Tiefe aber nicht aus, habe aber den Eindruck, daß dieser Text nicht von der H24-API kam.
Es ist ziemlich frustrierend, daß das nicht funktioniert. Hast Du noch eine Idee, wo ihr ansetzen könntet?
das klingt sehr spannend. Die Steps sollten sich beim FileUpload nicht (wirklich) unterscheiden. Kannst du uns eventuell einen Flow Export mit den beiden Steps und deinen Einstellungen per Ticket schicken. Dann würden wir nochmal genau schauen, wo die Unterschiede liegen.
Zu:
Der Text „Failed to parse…“ stammt mit großer Sicherheit aus der Response (Antwort der API). Die Nachricht sollte auch im Debug Log zu finden sein, wenn sie im Eventlog ausgegeben wird.
wirklich einem Dateinamen, der in der Liste bei filesToUpload dabei ist?
