I have had this issue recently. I realize this is a post from 2013, but my answer is for other people with the same issue, for future reference.
In my case: we used constants for end-points and on one of the environments we had an end-point constant populated with the WS-DOC location, instead of the actual location of the webservice. The HTTP 200 OK is the correct "soap" response, since there is no error on the called website. But there is no webservice there being able to process the request.
So, verify if the constant is populated in a format with /ws/ , for example: http://localhost:8080/ws/WSGetListPerson10/
Please turn on debug log for webservice and paste the request and response here . Probably that will help others to understand what error is there for XML parsing or ....
Please turn on debug log for webservice and paste the request and response here . Probably that will help others to understand what error is there for XML parsing or else.
Probably you can turn on debug mode of logging for webservice and see what XML and parsing you are doing.
I have seen something similar before, does the webservice by any chance return the content type text/html instead of text/xml in the http header?
If not, set the webservices and xml import lognode to trace.