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?
Related
ColdFusion seems to cache its initial request to a web service. When modifying the web service's signature (e.g, adding a parameter to the web service method) it seems that ColdFusion has no idea how to call that web service until the "ColdFusion 2016 Application Server" Windows service is restarted. This complicates development as it affects all ColdFusion websites during that restart period effectively clearing all sessions.
The context of the execution of these web services are through the CreateObject method.
Application.MyWebServiceVariable = CreateObject("webservice", "PATH");
In the past other have mentioned using the refreshwsdl argument, as such.
oWsdlArgs = structNew();
oWsdlArgs.refreshwsdl="yes";
Application.MyWebServiceVariable = CreateObject("webservice", "PATH", oWsdlArgs );
Unfortunately this does not resolve the underlying issue where the actual Windows service must be restarted in order for ColdFusion to refresh its internal cache of that web service method signature.
I can also confirm that simply restarting the ColdFusion application using ApplicationStop() does not work.
Is there a way to recycle this internal cache of the web service signature so that developers don't need to restart the Windows service?
Additional Notes
Apparent in ColdFusion 9 to ColdFusion 2016
Web services are SOAP-based hosted on IIS
Web services' logic are within a DLL
If you are calling these webservices using createObject and/or cfinvoke, then as you have seen, CF caches the definitions. The easiest way I have found to refresh these definitions without a CF service restart is if you have access to the Coldfusion Administrator.
CF Admin -> Data & Services -> Web Services
Under there you should see an entry for each wsdl that CF has cached, with a button to use to force it to update.
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.
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"})
I have a problem when calling a method from an external web service.
The error returned is as follows:
The request failed with HTTP Status 403
My application is deployed using ClickOnce technology. The strange thing is that when I call service (test the code) on my development machine and additionally in test environment (IIS 6, Windows 2003 Server) everything is fine.
Unfortunately when application is in production environment (Windows 2003 Server, IIS 6) the error is returned.
I don't use a service reference to call a web service, instead I use a proxy class generated from wsdl.exe application. Can someone please help me.
EDIT:
I noticed that I can't even access wsdl file using web browser from that production server. This production server is also in different domain.
I found the solution of my problem. It seems that the company that owns the external web service has some kind of access list with IP addresses allowed to access this web service