Problem beim übertragen von Dateien via http POST

enaio®
,
1

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 :slight_smile:

Nun mein Problem: Wenn das Formular seine Dateien direkt an enaio sendet, kommen diese auch an :slight_smile: . 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

2

Hallo @fb,

ich vermute du verwendest hier den Insert Endpunkt
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-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:

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"
<suche.gif>
----------------------------469944898896943075608125--

Der AppConnector erzeugt aber folgende nicht fatale Meldung:

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
grafik826×317 26.7 KB

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"
<suche.gif>
----------------------------139623109559666484303029--

In sofern ist das leider nicht die Lösung.

3

Hallo Uli,

vielen Dank für die superschnelle Antwort :slight_smile:

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 :wink: ) → 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
image1570×764 65.3 KB

Der Mimetype passt, aber die Dateigröße zeigt das etwas schief gelaufen ist, das Original hat 66KB.

Habt Ihr hierzu eine Idee?

LG Flo

4

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

5

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

6

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

1 „Gefällt mir“