Hello,
I am doing some work on an application to access NAV through published web services. I have installed the server tier and the demo database I am using on my laptop (Windows XP) and published a codeunit webservice. I can see the WSDL and all the normal stuff by using the /DynamicsNAV/WS/Services, etc.
I am using soapUI to do some response testing, and, if I use my normal login (the login I used to install the server tier, etc.), I can access the web services accordingly and everything works well. To do some further testing, I created a new windows login, gave it SUPER permissions in the NAV demo database, synchronized, etc., and try to use it to log on the web service (using NTLM security). However, I always get a HTTP 401 Unauthorized response from any SOAP requests (even though this login can see the definitions through a browser).
Does anyone have any advice on this or am I missing something obvious?
TIA!
0
Comments
It seems old post, but I got the same error "SOAP message is invalid" while testing with SOAPUI application.
HTTP/1.1 500 Internal Server Error
Content-Length: 394
Content-Type: text/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Thu, 28 Aug 2014 07:48:44 GMT
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode xmlns:a="urn:microsoft-dynamics-schemas/error">a:System.Net.WebException</faultcode>
<faultstring xml:lang="fr-FR">Soap message is invalid!</faultstring>
<detail>
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">Soap message is invalid!</string>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
May be there is some issue in soap massage.
You issue is not related to security at all. NAV does not understand your request document.
Please make sure you are using a valid soap envelope and the Body contents adhere to the request document specification as given by the WSDL document returned by the web service. Generating the request with a tool such as SoapUI, Visial Studio or Web Service Studio and looking at that might be easier, though, than analyzing the WSDL.