-
Why would I be getting a XML parse error when the same SOAP Envelope successfully sends on SOAP UI? The SOAP Envelope is validated and was generated using Mirth. If I use SOAP UI generated SOAP Envelope it fails too, while SOAP UI can successfully send that request too. I have the data types set for all to I have pasted the SOAP Envelope, SOAP Response example from SOAP UI, server log, error message, and channel export below. Mirth 4.5.0 SOAP Envelope:
SOAP Response Example from SOAP UI
Server log
Channel export:
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
I suspect from the stacktrace that the XML stream reader misreads the tag as CDATA when the WSDL has none. The GitHub repository is archived: https://github.com/JetBrains/jdk8u_jaxp/blob/master/src/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java#L652 I was able to implement another public WSDL successfully. http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?WSDL I did have to switch the Port/Endpoint to not use SOAP version 1.2 in order to get it to work. |
Beta Was this translation helpful? Give feedback.
-
Looks like a known bug in Mirth, where Mirth is unable to parse the web service WSDL if the WSDL contains non-ascii standard characters: `If you get an error message, e.g. “Get Operations fails with Method failed: 500 Internal Server Error” this can be caused by non standard ASCII characters in the WSDL returned by the web service; e.g. accented characters. The current version of Mirth Connect doesn’t have an option to define the encoding for a web service client - and uses the default operating system encoding (windows-1252 in most cases) which is in fact incorrect (should be UTF-8). But as a workaround you can override the “default” encoding in your mcservice.vmoptions file. Please note that setting the default encoding in mcservice.vmoptions has an impact on all channels where you have “Default encoding” selected on the connectors ! Since most web service providers return the WSDL in UTF-8 you can add the line below to your mcservice.vmoptions as a workaround. (don’t forget to restart the Mirth Connect service !) -Dfile.encoding=utf-8 |
Beta Was this translation helpful? Give feedback.
Looks like a known bug in Mirth, where Mirth is unable to parse the web service WSDL if the WSDL contains non-ascii standard characters:
`If you get an error message, e.g. “Get Operations fails with Method failed: 500 Internal Server Error” this can be caused by non standard ASCII characters in the WSDL returned by the web service; e.g. accented characters.
The current version of Mirth Connect doesn’t have an option to define the encoding for a web service client - and uses the default operating system encoding (windows-1252 in most cases) which is in fact incorrect (should be UTF-8).
But as a workaround you can override the “default” encoding in your mcservice.vmoptions file.
Please note…