Hallo zusammen!

Dringende Bitte um ein funktionierendes Beispiel eines ProvideAndRegisterDocumentSet-Request mit MTOM/XOP und bitte als komplette HTTP-Nachricht, also mit den Headern, die beim Senden vor dem gesendeten Inhalt kommen (Beispiel s.u.).

Vielen Dank im Voraus!

Hintergrund:

Wir schaffen es leider bisher nicht, einen funktionierenden ProvideAndRegisterDocumentSet-Request mit MTOM/XOP zu senden, so dass der Request vom Konnektor angenommen wird.
Wir haben uns hierzu an dem Beispiel provideandregister.xop auf GitHub / Gematik orientiert.

Getestet mit einem gemanagten Secunet- und einem eigenen RISE-Konnektor in der RU.
Beim Secunet-Konnektor konnten wir das SOAP-XML ohne MTOM senden, um es zu überprüfen, das hat funktioniert.
Wenn wir aber die MTOM-Struktur verwenden, kommt immer Syntax Error, von beiden Konnektoren, mit denen wir testen konnten.
Hier ein Auszug aus dem Übertragungsprotokoll, was wir gesendet haben:

POST [...]fm/phrservice/v1 HTTP/1.1
Content-Type: Multipart/Related; start-info="text/xml"; type="application/xop+xml"; boundary=MIME_MTOM_Boundary; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"
SOAPAction: "ProvideAndRegisterDocumentSet"
Host: 192.168.135.1
Content-Length: 14377
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

(ab hier der Inhalt von provideandregister.xop aus obigem Link aus dem Gematik Github Sample)
--_MIME_MTOM_Boundary_
...
--_MIME_MTOM_Boundary_--
(am Ende ein CRLF hinter dem letzten MIME MTOM Boundary, wie in provideandregister.xop)

Hier die Antwort des RISE-Konnektors darauf:
RegistryError Code 4000 - Syntaxfehler

Hallo,

ja, das hab ich auch schon alles gemacht:
Gematik-Jira-Helpdesk, Gemmunity-Forum, Github-Issue.
Erfahrungsgemäß gehe ich da nicht von einer hohen Erfolgswahrscheinlichkeit aus, deshalb greife ich nach jedem Strohhalm.

Theoretisch sollte es auch jeder PS-Hersteller beantworten können, da es im gemILF_PS_ePA so steht, dass man für Dokument-Upload und -Download das MTOM/XOP Format verwenden muss.
Praktisch jedoch wurde das bei der Zertifizierung durch die Gematik nicht geprüft, deshalb dürfte es einige PS-Hersteller geben, die das nicht umgesetzt haben.

Lösung:
(Dank an Jürgen Gmeiner im Gemmunity-Forum)

Ein vollständiger korrekter Content-Type Header im Request für MTOM für ProvideAndRegisterDocumentSet sähe so aus:

Content-Type: multipart/related; start-info="application/soap+xml"; type="application/xop+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"; boundary=MIME_MTOM_Boundary
Darin kann der Wert von boundary beliebig gewählt werden, alles andere muss genau so sein wie hier angegeben.

In gemILF_PS_ePA_V1.4.3 steht es irreführend:

A_15570 - Content-Type und Charset im http-Header
Beispiel einer korrekten Angabe im http-Header:
Content-Type: text/xml; charset=utf-8.[<=]

Des weiteren steht im ILF steht unter 5.2.3.3 Nutzung:
"Ein http-Request im MTOM/XOP - Format (type="application/xop+xml") führt zu einer
MTOM-Response."
Jedoch fehlt die Angabe, dass und wie dies in den Content-Type Header des Requests eingefügt werden muss, sowie ein Beispiel, wie es auszusehen hat.

Hallo, "bisschen" spät, ich weis.

Aber ich habe mit MTOM jetzt Durchbrüche machen können und würde deswegen meine Hilfe anbieten. Besteht noch Bedarf?