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.
Related
We have deployed our webservice in liberty server.Earlier it was on IBM WAS. After deploying in liberty, we came to know that Webservices is running on CXF webservice framework. In WAS, it was Axis framework.
Another difference is that , changes happened in wsdl url & content. The old wsdl url is http://localhost:8080/Hello/HelloServices/Helloservices.wsdl and it contains xsd schema definition.
In the liberty server above wsdl url is not working and throwing file not found. But if we try to invoke http://localhost:8080/Hello/HelloServices?wsdl it's working.
Could anyone tell why old url is not working in New server. Is it due to server or inbuilt cxf framework in server.
Another team is using wsdl url to consume this webservice, with this new url they are not able to achieve it.
Any thoughts or suggestions are appreciated..
Thanks in Advance
The main reason for this is the change in the JAX-WS implementations used by the different WebSphere profiles. CXF, unfortunately, hard codes the WSDL url to append ?wsdl in several locations and so this is something that is not possible to change in configuration. The easiest solution would to add a ServletFilter to check the incoming request url for http://localhost:8080/Hello/HelloServices/Helloservices.wsdl and then redirect the request to http://localhost:8080/Hello/HelloServices/Helloservices?wsdl.
There's a good SO post that shows how to write a ServletFilter to redirect here:
How to use a servlet filter in Java to change an incoming servlet request url?
The other option would be to have the client side update either their code or configuration to account for the change to the WSDL URL.
I was asked this question in a technical interview for a integration intern role.
He was digging much into understanding of SOAP web services.
Question). Consider that you are exposing a web service through SOAP to a Client.
The url through which you are providing the service is up and running when you check it.
But the Client has a problem, he is not able to access your webservice.
How will you go on troubleshooting this issue?
My response:
I would first check whether the url the client is trying to access the service is correct.
Will check the .wsdl file: port, bindings & will check once whether upon sending a SOAP request to the URL, am I receiving the SOAP response in local through SOAP UI.
If I get error, will troubleshoot based on the kind of error I get: Like page not found, null exception etc.
I felt he was still expecting some other point. He hinted saying where in what registry you will check all the web services which have been hosted(I guess this was much of a production support issue :P)
I told I may look into UDDI registry, but was not sure with this.
Please let me know your inputs on what could be possibly a right approach?
Apache jUDDI PMC here. Yes UDDI could be used to verify that the client is pointed at the right location, assuming the client knows where the UDDI server and that it is registered and the client knows what to query for on the UDDI server and a UDDI query is part of that client's normal workflow. That's a lot of assumptions but certainly feasible.
Most of time, the endpoint is in a config file somewhere or some idiot hard coded it.
That said, this my go to list for checking SOAP service connectivity (from the client's perspective)
DNS resolution of the hostname in the URL
Ping the remote host
HTTP GET to the URL of the SOAP service + ?wsdl (this usually works). This is also a good time to verify SSL connectivity.
You can also parse the WSDL doc, assuming one is returned for identify the endpoint url.
Finally if that all works, execute the service. HTTP 200 is general a positive sign
Edit:
Another alternative approach is to implement a very simple API (wsdl method) on every SOAP service that simple returns a true/false that answers the question "Am I open for business?". This method would provide a standardized approach for identifying if a service was available or not by testing an external dependencies (databases and whatnot).
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 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!
Now I want to prefix this with I am unsure whether this should be here or on server fault so I'll post it here to begin with.
We are developing a REST API in Coldfusion 9 which is being hosted on IIS 7 for a client which on certain calls must call another internal webservice. When making these calls from the server that the API is hosted on there are no errors, however when we make the call from a remote machine the following message is returned:
'connection failure. status code unavailable.'
I have googled the issue where the following was suggested as a fix http://www.talkingtree.com/blog/index.cfm/2004/7/28/20040729 but it does not work for me. The following are the notes from my own testing:
The calls which are causing the issue are a mix of get, put, post and delete.
The only common part of each call is the talking to the same webservice.
I am able to call the webservice directly from the places where I make the remote calls to the API from.
While all the calls make a call to the same webservice they do not all make the same call to the webservice.
Ideas:
Call the web service remotely using a URL that resolves to the internal ColdFusion server (e.g. http://[servername]:8300). You will probably have to some configuration to get this working. Reason for doing so is to identify if IIS or ColdFusion is the root cause. If you can hit the internal server remotely then IIS is probably the issue.
Is the web service call over SSL? If so, is remote caller also ColdFusion? If you've answered both yes, check to see if the SSL certificate is trusted by the remote caller's JVM. If not, you need to register it as part of the JVM's keystore.
Can you ping the host server from the caller? If not, does the caller need a "hosts" entry?
If enabled on your host, review the .NET filter and how it interacts with HTTP calls. I've experienced a situation where I was unable to access a folder called "/bin" because the .NET filter intercepted the requests.
The issue turned out to be that each of the calls required basic authentication which the calls themselves were handling, however basic authentication had been turned on in IIS which was causing IIS to intercept any requests with an Authorization header.
This causes an issue as IIS assumes that if authentication is passed up then it is for a user on that machine/domain and would reject any other credentials (which were valid for the system). It was working when we were logged into the machine because it was coming locally it did not need to authenticate the user.