# Problem beim übertragen von Dateien via http POST **URL:** \ **Category:** enaio®\ **Tags:** howto, coding\ **Created:** [4. Dezember 2023 um 10:40 UTC](https://ecm.community/t/problem-beim-uebertragen-von-dateien-via-http-post/501 "2023-12-04T10:40:55Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![fb](https://ecm.community/user_avatar/ecm.community/fb/32/209_2.png) [@fb](https://ecm.community/u/fb)\ **Post date:** [4. Dezember 2023 um 10:40 UTC](https://ecm.community/t/problem-beim-uebertragen-von-dateien-via-http-post/501/1 "2023-12-04T10:40:55Z")
Hallo zusammen, ich habe ein HTML-Formular erstellt das neben Indexdaten auch eine oder mehrere Dateien übertragen kann. _Meine Herausforderung ist die, das ich vom Formular nicht direkt an enaio übertragen möchte, sondern eine „Middleware“ ansteure._ Ich habe mir eine **nodered** Instanz aufgebaut die ich zukünftig als Middleware betreiben möchte, um interne Onlineanträge mit Attachments (die aus den verschiedensten Quellen stammen können _(z.B.: Intranet, Formularserver, …)_ mit etwas Pfiff verarbeiten zu können. Ziel ist mit dieser Middleware die enaio Zugriffe und das Handling nicht auf die „Zulieferer“ abwälzen zu müssen 🙂 Nun mein Problem: Wenn das Formular seine Dateien direkt an enaio sendet, kommen diese auch an 🙂 . Teste ich das Ganze mit **Postman** kommen diese ebenso an. Wenn ich aber nun aus meiner Verarbeitungskette des **nodered** meinen POST abschicke … kommt leider die Datei nicht an. Ich führe einen POST mit einem Multipart-Formdata aus, Fundstelle und Indexdaten kommen an, das mitgelieferte File leider nicht oder zumindest nichts was der ursprünglichen Datei entspricht. Anbei meine beispielhafte Übertragung: > --------------------------514311687129174916106222 > Content-Disposition: form-data; name=„data“ > > { > „cabinet“: „Akte“, > „objectTypeId“: „262148“, > „mainTypeId“: „4“, > „fields“: { > „BETREFF“: { > „internalName“: „BETREFF“, > „value“: „Anlagee 1/1 | Profilbild.jpg“}, > „DOKUMENTART“: { > „internalName“: „DOKUMENTART“, > „value“: „Anlagee“}, > „DOKUMENTDATUM“: { > „internalName“: „DOKUMENTDATUM“, > „value“: „03.12.2023“}, > „BEARBEITUNGSSTATUS“: { > „internalName“: „BEARBEITUNGSSTATUS“, > „value“: „freigegeben“}, > }}, > --------------------------514311687129174916106222 > Content-Disposition: form-data; name=„file“; filename=„/var/local/Profilbild.jpg“ > Content-Type: application/octet-stream > Content-Transfer-Encoding: base64 Die Datei kommt im nodered als Buffer an. Ich habe versucht diesen Buffer 1:1 zu übertragen oder ihn auch als Base64 kodiert zu übertragen … kein Erfolg. Die Datei kann nicht geöffnet werden, die Dateigröße entspricht auch nicht dem des Originals - also muss es an der Übertragung liegen. Beim **Content-Type** und **Content-Transfer-Encoding** habe ich schon „rumgespielt“ . _Ich habe schon den Tipp bekommen das Ganze als **Blob** zu übertragen, leider ist nodered hierzu nicht nativ in der Lage._ Hat jemand von euch einen Tipp für mich? Hattet Ihr so etwas ähnliches schonmal? Im Voraus vielen Dank und Viele Grüße Flo ---
**Author:** ![uw](https://ecm.community/user_avatar/ecm.community/uw/32/695_2.png) [@uw](https://ecm.community/u/uw)\ **Post date:** [4. Dezember 2023 um 11:52 UTC](https://ecm.community/t/problem-beim-uebertragen-von-dateien-via-http-post/501/2 "2023-12-04T11:52:58Z")
Hallo @fb, ich vermute du verwendest hier den [Insert Endpunkt](https://help.optimal-systems.com/enaio_develop/pages/viewpage.action?pageId=1867855#DocumentService(/documents)/-/osrest/api/documents/insert/%5BlocationId%5D) des enaio AppConnector, oder? Ich meine mich zu erinnern, dass der AppConnector hier etwas streng ist und Postman diesen Header per Default setzt. Hast du schon gestestet, ob das setzten des `Content-Type: application/json;charset=UTF-` `8` für den Data Parameter hilft? Bekommst du einen 500 Fehler von AppConnector? In dem Fall kann es helfen das log unter `"appconnector\configuration\logs\osrest.log"` nach Fehlermeldungen zu prüfen. Alternativ gibt es auch den [insert](https://help.optimal-systems.com/enaio_develop/pages/viewpage.action?pageId=891296)-Endpunkt des DMS Services. Dieser Endpunkt ist etwas speziell, da du hier Objekte erstellen kannst. Dafür musst du im Data Bereich unter `contentStreams.cid` eine eindeutige ID angeben, und die Datei als separates Multipart Element mit der CID als Name mitsenden. Grüsse Uli Nachtrag: Es scheint nicht so zu sein. Der Default schickt der Postman auch kein Content-Type mit: ```plaintext POST /osrest/api/documents/insert/412 HTTP/1.1 Authorization: Basic xxx User-Agent: PostmanRuntime/7.35.0 Accept: */* Postman-Token: 5f01e7fe-0282-4e59-88e2-c1a3063c3d83 Host: devel-uw-2023.ecmind Accept-Encoding: gzip, deflate, br Connection: keep-alive Content-Type: multipart/form-data; boundary=--------------------------469944898896943075608125 Cookie: JSESSIONID=F75ECB1C3FFA2CC881FAF66D56CBF9D4 Content-Length: 1442403 ----------------------------469944898896943075608125 Content-Disposition: form-data; name="data" { "cabinet": "Akte", "name": "Farbbild", "fields": { "Text0": { "internalName": "Text0", "value": "test" } } } ----------------------------469944898896943075608125 Content-Disposition: form-data; name="file"; filename="suche.gif" ----------------------------469944898896943075608125-- ``` Der AppConnector erzeugt aber folgende nicht fatale Meldung: ```auto 2023-12-04 13:24:01,605 [http-nio-8060-exec-10] WARN com.os.osrest.services.util.ServiceUtils - Encoding of multipart/form-data part 'data' is not declared nor could it be detected. Please specify the encoding within the content-type header. By default the AppConnector sets the encoding to UTF-8, which may cause errors. ``` Man kann den Wert aber entsprechend definieren: ![grafik](https://ecm.community/uploads/default/original/1X/06210422b7cdd79c21ed7819f4e46355fc82c0ba.png) ```plaintext POST /osrest/api/documents/insert/412 HTTP/1.1 Authorization: Basic xxx User-Agent: PostmanRuntime/7.35.0 Accept: */* Postman-Token: 56a98fc6-3f00-4f02-9d92-d38cc6684a79 Host: devel-uw-2023.ecmind Accept-Encoding: gzip, deflate, br Connection: keep-alive Content-Type: multipart/form-data; boundary=--------------------------139623109559666484303029 Cookie: JSESSIONID=F75ECB1C3FFA2CC881FAF66D56CBF9D4 Content-Length: 1442449 ----------------------------139623109559666484303029 Content-Disposition: form-data; name="data" Content-Type: application/json;charset=UTF-8 { "cabinet": "Akte", "name": "Farbbild", "fields": { "Text0": { "internalName": "Text0", "value": "test" } } } ----------------------------139623109559666484303029 Content-Disposition: form-data; name="file"; filename="suche.gif" ----------------------------139623109559666484303029-- ``` In sofern ist das leider nicht die Lösung. ---
**Author:** ![fb](https://ecm.community/user_avatar/ecm.community/fb/32/209_2.png) [@fb](https://ecm.community/u/fb)\ **Post date:** [4. Dezember 2023 um 13:53 UTC](https://ecm.community/t/problem-beim-uebertragen-von-dateien-via-http-post/501/3 "2023-12-04T13:53:13Z")
Hallo Uli, vielen Dank für die superschnelle Antwort 🙂 Ja ich gehe über den AppConnector. Dein Hinweis zum `Content-Type: application/json;charset=UTF-` `8` hat auf jeden Fall die WARN `Encoding of multipart/form-data part 'data' is not declared nor could it be detected` eliminiert (_ein Fehler zu dem ich mich auch noch gemeldet hätte 😉 )_ → mega gut !!! Ich hatte auch vor der Änderung (und die WARNING ignorierend) immer einen **Status 200** bekommen, die Fundstelle wurde sauber angelegt. Das File kommt aber „korrupt“ in der Akte an: ![image](https://ecm.community/uploads/default/original/1X/1e1a55cd4331f58ea4936c6923ffaa210a24527e.png) Der Mimetype passt, aber die Dateigröße zeigt das etwas schief gelaufen ist, das Original hat 66KB. Habt Ihr hierzu eine Idee? LG Flo ---
**Author:** ![uw](https://ecm.community/user_avatar/ecm.community/uw/32/695_2.png) [@uw](https://ecm.community/u/uw)\ **Post date:** [4. Dezember 2023 um 17:41 UTC](https://ecm.community/t/problem-beim-uebertragen-von-dateien-via-http-post/501/4 "2023-12-04T17:41:39Z")
Hallo @fb, ok, sehr gut. Wegen der Datei würde ich bei dem Grössenverältnis darauf Wetten, dass einfach die Base64 Daten 1:1 archiviert wurden. Dass du einfach prüfen, in dem du die Datei aus dem enaio kurz exportierst (rechts Klick → Exportieren → Inhalt). Ich kenne mich leider nicht wirklich in node-red aus. Grüsse Uli ---
**Author:** ![fb](https://ecm.community/user_avatar/ecm.community/fb/32/209_2.png) [@fb](https://ecm.community/u/fb)\ **Post date:** [6. Dezember 2023 um 14:20 UTC](https://ecm.community/t/problem-beim-uebertragen-von-dateien-via-http-post/501/5 "2023-12-06T14:20:08Z")
Hallo @uw , vielen Dank für deine Rückmeldung. Ich habe einiges ausprobiert und auch geschaut was letztendlich im enaio ankommt (also auch exportiert und mal verglichen) … kein Erfolg. nodered scheint hier etwas zickig zu sein, ich habe mit mit einem nachgelagerten CURL beholfen das für die Dateianlage zuständig ist. Merci mol und Viele Grüße Flo ---
**Author:** ![uw](https://ecm.community/user_avatar/ecm.community/uw/32/695_2.png) [@uw](https://ecm.community/u/uw)\ **Post date:** [7. Dezember 2023 um 17:26 UTC](https://ecm.community/t/problem-beim-uebertragen-von-dateien-via-http-post/501/6 "2023-12-07T17:26:30Z")
Hallo @fb, ich habe mir kurz ein Node-RED als Docker gestartet un den Fall versucht nachzustellen und bin leider auch auf keine Lösung gekommen. Die Datei wird bei mir zwar abgelegt, ist jedoch defekt. Leider hat hier Node-RED ähnlich wie andere ETL Tools immer einen Schwachpunkt. Prinzipiell kann man im enaio Context auch eigene Services per Python oder, etwas aufwändiger, per Java bauen, welche die gewünschten Endpunkte bereitstellen. Dabei gibt es grundsätzlich zwei Optionen: - Service der sich vor dem enaio Gateway befindet und sich wie ein normaler Webclient verhält `Extern` → `DMZ` → `MeinService` → `Firewall` → `enaio Gateway` → `MicroServices` - Service der sich hinter dem enaio Gateway befindet und sich wie ein Microservice verhält `Extern` → `Firewall` → `enaio Gateway` → `MeinService` → _Eureka_ → `MicroServices bzw. enaio native API`. Diese Variante ist aufwändiger, bietet aber z.B. die Option, dass die Authentifikation des Benutzers vom Gateway übernommen wird. Grüsse Uli