I'm writing a compact framework 3.5 application for a windows mobile device. In this application I'm consuming a web service in order to sync with our database. However, whenever I try to make a call to the web service from the device or the emulator, I get the following error: Invalid URI: Hostname could not be parsed. I'm connected to the network via R-NDIS. The service is running on my development machine right now, and I'm actually able to browse to the asmx page through pocket IE. What am I missing?
Thanks!
This might be a proxy problem. The following worked for me.
var service = new WebService.Service();
service.Proxy = GlobalProxySelection.GetEmptyWebProxy();
You might not be picking up the proxy server IE is using, or pocket IE might be displaying a cached version of the ASMX page (and thus not really able to access it either). Probably neither one of these is your problem, however.
Update: try putting this in your application's config file:
<configuration>
<system.net>
<defaultProxy>
<proxy autoDetect="true" />
</defaultProxy>
</system.net>
</configuration>
Related
I'm new at using SoapUI, I'd like to know if my machine supports SOAP and in case yes, what I can use as an endpoint for my newly created SoapUI project.
My machine is a Windows-10, and on top of that I have installed Cygwin (enabling some UNIX features).
Does somebody know how I can retrieve a possible value for an endpoint for my SoapUI project?
Oops, from the comment I have the impression that my question is badly formulated: on my PC I have a server application, of which I don't know if it supports SOAP (I know it supports HTTP because I'm using localhost in a browser to access it).
However when I use localhost or 127.0.0.1 as an endpoint in my SoapUI project, nothing happens (I see no response and the request log stays empty), hence my question.
Per default, mostly no application will act as a SOAP prodiver, as it is much more complicated as REST/http for example.
If your application has the capability of a SOAP provider, it is usually SOAP over HTTP. But you need to know the correct endpoint url address.
Not only 127.0.0.1
Usually there is a servicename in the url (and you can also try to show wsdl with ?wsdl), like http://127.0.0.1/myapplication/myservice?wsdl
when setting up a new soapui project, you also have to provide the wsdl location
(http://127.0.0.1/myapplication/myservice?wsdl)
Regards, rka
I am new in the area of SOAP Based web services. I am using TomEE server. The server is a bit customized according to my organization's need.
Few days back, when I was trying to run the web services example from TomEE website, I was able to generate the wsdl and calling the web service by a client.
Now, when I need to use the customized version of TomEE plus (by the organization), I can see that the request does reach to the server and hence there is a log entry also but my #WebMethod is not getting executed.
Does any one has any idea about any configuration which can prevent the request from reaching to the webservice method? Is there any pointer around how can I debug further to reach out to the root cause of this issue?
Without further information about what is customized it's like fishing in the dark.
I would guess that perhaps the global web.xml or the server.xml of tomee server is changed so that some URI context mappings are not forwarded or ignored. But it's only a lucky tip.
I'm currently attempting to deploy the Navision webservice (from Dynamics Navision 2009) and am finding that the webservice authenticates when connecting to a local Navision SQL database but NOT a remote Navision SQL database.
So we have servers S (with a full Navision install) and W (with only the Services installed). The CustomSettings.config file on these two systems is identical except that where S references localhost:
<add key="DatabaseServer" value="127.0.0.1"></add>
<add key="ClientCredentialType" value="Windows"></add>
W references S:
<add key="DatabaseServer" value="S"></add>
<add key="ClientCredentialType" value="Windows"></add>
(Other details omitted.) The webservice itself is running as the same domain user in both cases, and that user is authenticated within Navision.
When I connect to the webservice which is running on S, authentication works and the service proceeds as normal:
http://S:7047/DynamicsNAV/WS/Company/Codeunit/RLIntegartion
I'll omit the actual result here. When connecting via W instead:
http://W:7047/DynamicsNAV/WS/Company/Codeunit/RLIntegartion
the webservice instead returns XML indicating an authentication failure:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode xmlns:a="urn:microsoft-dynamics-schemas/error">
a:Microsoft.Dynamics.Nav.Types.NavDatabasePasswordException
</faultcode>
<faultstring xml:lang="en-US">
The login failed when connecting to SQL Server S.
</faultstring>
<detail>
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
The login failed when connecting to SQL Server S.
</string>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
I can configure an ODBC connection on W to the Navision database on S and the connection succeeds and authenticates correctly, so the actual database connection and authentication appears to be fine.
I'm aware that the webservice itself must normally be accessed locally so that any files written can be read from where the Navision webservice has written them, but from what I can tell in the documentation the webservice may legitimately access the database from a separate server. However, in practice (per above) this doesn't seem to actually work.
Is this a restriction that Navision imposes? If not, does anyone have any suggestions as to why the webservice is failing to authenticate when accessing a remote database when the same webservice succeeds locally?
Or could it be a limitation imposed by the codeunit programmers? I've spoken to them and they indicate that this should work, but clearly it does not.
That is known problem of Nav 2009. In later versions it's working without additional tricks. To solve this you need to create SPN.
Me personally was not able to set it properly so I just always installed web service tier on the same server with SQL. In this case it works.
There are three participants in this scheme - DB, web service and the client (that connects to this service). The problem appears only when all these three participants are on three different machines.
This three-machine setup will work only if the following requirements are fulfilled:
1) your client is capable of using Kerberos authentication (e.g. Internet Explorer or .NET applications are capable, but Chrome or PHP applications are not)
2) you set up NAV to use Kerberos authentication (as opposed to NTLM) and you set up delegation.
Delegation is a process that allows NAV server (or web service) to take the authentication ticket that came from client and pass it to SQL Server. You need to explicitly allow this in Active Directory setup. For that you will need SPNs - they basically describe the subjects that take part in this delegation.
You may refer to these manuals to setup the whole thing:
MSDN Walkthrough: Installing the Three Tiers on Three Computers
MSDN How to: Configure Web Services with Delegation
NAV 2009 Web Services on a three machine setup
You can also revert to more simple setup of using two-machines setup. In this case, either NAV server and SQL server should be on the same machine, or NAV server and the web service client should be on the same machine. As an example of the latter, you may create a small custom web service which acts as a proxy for your calls, and publish it on the same machine as NAV server/web service.
I have an ASPX page. When the page is loaded there is code in the code behind that uses an API. The API makes an HTTPS call out to a third party, commercial web service. I am trying to troubleshoot why the API calls are not working properly. Apparently the API actually constructs an XML request that is sent out over HTTPS to the web service. I've been told by the support rep that I need to provide them with the XML that is being sent. The only way I can figure out how to get the XML is to use a tool like Fiddler to see what is being sent out. So how can I use Fiddler to see the contents of the XML request that is being sent from the server out to the web service? I am running everything directly on the server but all I am seeing is the GET request for the ASPX file itself. I am not seeing anything in relation to the HTTPS request that the server code is sending out to the web service. I have not used Fiddler much so I am hoping that maybe I just don't have it set up right to monitor that traffic.
Corey
After mucking around with it a bit I found this post: Why isn't fiddler capturing request when invoking XMLRPC from iis?. That seemed to do the trick! Basically it sounds like the default proxy settings in Win7 are on a per user basis. So I went in and changed the identity of the AppPool for my site to a local user (Administrator) and then it worked great. I started up Fiddler. Then I started up my ASP.NET app and then when I loaded the page I saw the request that went out to the web service from my code behind! Yay!
We have a site running on MOSS 2007 which makes calls to custom web service asmx methods on the same domain from the client.
On the live site requests are getting redirected to the following url:
http://[domain]/_layouts/error.aspx?ErrorText=Request format is unrecognized for URL unexpectedly ending in %27%2FIsSuspectWaterLevel%27.
We've added the following to the sites web.config without any joy:
<system.web>
<webServices>
<protocols>
<add name="HttpSoap" />
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
...
</system.web>
Interestingly enough we don't have this issue on the test server which is supposed to be pretty identical to the live server.
Any ideas to what other variable might be at play here?
Thanks in advance for any ideas,
Gavin
Update:
While a call to
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
fails, I can still access
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel
though it fails when I invoke the method in the same way.
I wonder if this helps shed more light on the issue?
Another Update:
I've just observed the same error on the dev server. Removing the apps dll from GAC and then re-copying it in solved the issue. The live server tested fine with initial deployment so perhaps there's an issue with Sharepoint loosing some reference over time? Clutching at straws as very confusing behaviour!
Yet Another Update:
It seems everytime I touch (open and save) the web.config file in 12 Hives the problem is fixed again for a period, but after a while the problem comes back. I wonder if it's anything to do with the app pool being recycled?
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\web.config
An inelegant workaround to this issue that works for us: We've swapped out the web service asmx end point for a web handler ashx endpoint. This doesn't suffer the same issue for some reason.
I'm guessing from this that there's some issue creeping in after a period of time which is causing urls to resolve incorrectly. I suspect that the / after the .asmx in the url is the curprit. The ashx endpoint implemented is working purely on url parameters and posted data.
Obviously this work around won't always be an option for others who might experience the same issue as we're loosing a lot of the rich web service functionality that's pre-baked in to an asmx endpoint.
Unfortunately I won't be able to test any other solutions that people might put forward from now on as we've moved away from the web service asmx approach. Sorry.