In making a CF web-service call it was necessary to create a SOAP header. In CF9 we were able to use the setHeader() method. This works on my production server (running CF9). However, I've upgraded my local system to CF10 (for dev purposes) and discovered this method no longer works. It throws the following error:
Web service operation setHeader with parameters {...} cannot be found.
When I dump the object, I see that org.apache.axis2.client.Stub is used instead of org.apache.axis.client.Stub. So my question is two fold:
Where is the setHeader method in Axis2 ?
If that method is no longer accessible, how do I specify for my object call to use Axis1.x NOT Axis2 ?
I hope this makes sense.
How do I specify for my object call to use Axis1.x NOT Axis2
You can always switch back to Axis1, as described here and here. In summary:
...ColdFusion 10 allows you to specify the version of Axis in which
WebServices should be published or consumed. [It] has given a control
at three levels:
Server level
New setting named wsversion in the CF WebServices Administration screen
Application level (via the Application.cfc)
this.wssettings.version.publish = 1
this.wssettings.version.consume = 1
Component level
For publishing <cfcomponent wsversion="1">
For consuming createObject("webservice", theURL, {wsversion="1"})
Related
I'm in the process of migrating our web applications from a Cold Fusion 9 server to a Cold Fusion 2016 server and one of the web service calls that works perfectly in CF9 is now raising the following error in CF2016.
Web service operation InsertBank with parameters
{2,JOHNSON,BRIAN,450,450100530,21/02/2017,C,11212,006,128661543321,A,en}
cannot be found.
I'm calling the method directly through CFScript (I've already defined the web service using createObject(), and assigned it to an application variable for easy use)
result = Application.AdminWS.InsertBank(Trim(Application.ApplicationId),Trim(uname),Trim(Session.Employee.Client.xmlText),Trim(Session.Employee.Certificate.xmlText),Trim(DateFormat(Now(),"dd/mm/yyyy")),"C",Trim(instiNum),Trim(accouNum),Trim(transNum),Trim(varAccStatus),session.language);
I'm aware that Axis2 was introduced in CF10 however in ColdFusion Administrator I set the default as Axis1; I don't believe this is the cause of the issue. I've tried refreshing the WSDL however the only difference between the WSDL files between the two servers are the URLs.
Is there a way to cfdump a web service and view all of it's parameters?
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.
While developing a web application I have the following use case:
a 3rd party Web Service with quite a lot of methods is deployed on a test server A (with a single endpoint, e.g. http://3rdPartyServer/3rdPartySvc?WSDL)
a new method is about to be implemented in the near future, but I need to use it now
the rest of the methods are used throughout my code extensively
So I would like to do the following:
Create a mock service in SoapUI locally, based on the new WSDL which includes the new WS method (i.e. a superset of the WS methods currently on server A)
point my local application server to use the SoapUI mock service endpoint
mock only the response of the new WS method (create a dummy response for it in SoapUI)
let the other WS method calls to reach server A and return whatever it returns normally (i.e. use SoapUI as a proxy for these calls)
I've gone through the SoapUI documentation regarding service mocking and have used it numerous times, but could not find an option for such "pass-through" behavior.
When you read in your WSDL, the endpoint will point to your server.
Open your service, and select the service endpoint.
Add a second endpoint, to point to your mock. SoapUI has little bit of documentation showing this here. Only step "2. Getting Started" applies, not step 3!
In each of your tests, where you are using the mocked method, you will need to select the mock endpoint. Further discussion is here.
I imported a service reference to a SOAP web service from the customer and coded my client based on that.
After going to production, they said they will launch a new version of the web service with changes to the output type of one of the requests I make to the service (among new messages that I don't consume).
I know I can update my service reference and update my client code to process the updated wsdl and launch an update to my client at the same time the web service updates.
But, is it possible to instrument the WCF code in some way so that I can handle both versions of the response without having to coordinate the update of my client with the update of the web service?
In most cases, NO. It depends on what has changes in the service interface? In most cases you'll need (and want) to upgrade your client. You can always ask them to support more versions of their interfaces.
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.