as there seems to be no answer here yet, i'd like to ask, if there was a solution found.
I have a similar issue, just the other way round. My SOAP Request has a Content-Type "Multipart/related" when it is generated, but then somewhere this gets changed and the enclosing HTTP-POST Request has an additional Content-type "application/x-www-form-urlencoded" and gets bounced on the reciever-side therefore.
sadly most of the issues here regarding Content-types and SOAP and how to tinker in this, have no answers.
any hint would be mostly appreciated.
thanks in advance
isn't it a solution to add a Transport Header step on the Route Node and set http Content-Type to the appropiate value?
That should work for outgoing requests.
technically that might be a solution. And additionally this strengthens my assumption, that something similar is causing the effect, as there is only this one customer-installation on which the problem occurs.
i guess there might be some sort of redirecting node on the route of transport, that is doing exactly this, and that is setting the faulty content-type.
i tried to reproduce the effect in a test-environment and it didn't occurr.
thanks for the hint, i hope our customer will be able to analyze his route of transport regarding this. :-)
Well, good to see the question being looked upon again after almost an year !
I couldn't find the solution because of Oracle SOA "CAN'T" send or receive DIME attachments and messages. Hence, use of BPEL/Mediator for interaction with 3rd party .NET service was out of question. If you have read somewhere in the Oracle's document that they support DIME, MIME, MTOM attachments, then, it is not entirely true.
Ultimately, I had to resort to Apache Java Webservices, which do support DIME messages and attachments.
I wrote couple of Java codes to send and receive dime via SOAP Protocol, deployed them on the Weblogic Server and used those as Partner Links in my services.
well, as the complete HTTP POST Request including the enclosed SOAP Request is built by another library (OCSI, it's a german e-gov standard) there is no problem with this layer.
It's just being sent by the Applicationserver.
But here the WLS seems to tweak the Content-type of the HTTP Request and thereby causes the problem.
We tested with several Transportlayers, no difference.
As there is only one Customer having this Problem, the OSCI library seems to be working perfectly correct.
It's hard to find anything about WLS configuration possibilities regarding this topic...