Coldfusion 2023 SOAP API, name of parameters on wsdl change to generic one

Report · Mar 20, 2024

I have a legacy SOAP API built in Coldfusion. This API is well established and works most times, until it doesn't but just for some third parties integrating with it. The issue I am facing is quite odd, I have checked the logs but not able to pinpoint why it occurs or when.

This is what the API Method in question looks like when I access the wsdl directly from browser:

As you can see the parameters names for function SubmitJobApplocationRequest are defined and listed as expected; however quite regularly, after the API gets used for sometime (once again, I am not able to find out when it occurs unfortunately nor why it does), the parameter names change to the following:

At this stage, some of the third party software's integrating with this API get the following error message back from Coldfusion:

coldfusion.xml.rpc.CFCInvocationException: [coldfusion.runtime.MissingArgumentException : The TOKEN parameter to the SubmitJobApplication function is required but was not passed in.]

I originally believed that the issue could be caused by the parameters not being passed in the exact same order as what Coldfusion expects them to be, however the code snippets I have been provided by the developers from one of these third party softwares show the parameters being passed in the correct order.

The simplest solution I have found to fix the issue (until it occurs again) is to save the CFC template again by adding/removing a space anywhere within the template; it seems to be refreshing the wsdl perhaps?

Another thing to note is that we are using Coldfusion 2023 and we have recently upgraded from 2018 (and before then 2016) however we were already experiencing it, so it doesn't seem to relate to this upgrade process.

The server on which this API is hosted is not load balanced and there is only the 1 CF template in the folder.

Has anyone experienced the same issue with Coldfusion with the name of the parameters changing? Or anyone could suggest what I could look at to find out why it is happening?

Report · Mar 20, 2024

I've not heard of that issue before, no. I'll say that since editing the file seems to fix things, that's about refreshing the template cache (versus refreshing the wsdl, which is related to how CF as a client calls upon a soap web service).

You could automate the process, in that there's a cf admin api method (in its runtime.cfc) called cleartrustedcache, which optionally takes an argument of a path to a filename whose template cache entry is to be flushed. A Google search will find details on doing that.

And until you find and resolve the root cause problem, you could also automate checking for the situation with a scheduled task that detects when it's happening (by creating an instance of the web service and assessing its results).

If you might assert that the problem is that some customers get the problem and not others--such that the scheduled task might not detect when it's happening, that's certainly a very challenging situation. In either case, I hope someone else might have a better idea for you.

/Charlie (troubleshooter, carehart.org)

Report · Mar 21, 2024

Thank you Charlie for your response.

I have tried with a template that checks the response of the SOAP API and checks the first agument/parameter name. if not what expected, I can then clear the trusted cache for that template and seems to be working fine; I might set up a scheduled task for that and keep it monitored. However, there might still be instances in which the issue occurs between each scheduled task call.

Eg, if the schedule is running every 5 minutes to check and reset the cache, if a SOAP request comes through within that timeframe and the WSDL object returns generic names for the parameters, the issue will still occur

Report · Mar 21, 2024

So there is a function in a web-service CFC. Its arguments are token, jobId, firstname, and so on.

As the error message suggests, that function is actually SubmitJobApplication, not SubmitJobApplicationRequest. SubmitJobApplicationRequest is not created by the developer. It is an internal object that the WSDL engine creates to represent request-data. So it is up to the WSDL engine how it represents the data within the SubmitJobApplicationRequest object.

That said, it appears as if the order of the arguments may change from one web-service invocation to the next. That would be one reason why the engine would switch to generically named variables in0, in1, in2, and so on. Something else strengthens this hypothesis. Namely, the engine's use of the <wsdl:message> element to hold the arguments.

I would expect to see something like

<xs:element name="submitJobApplication">
	<xs:complexType>
		<xs:sequence>
			<xs:element name="token" />
			<xs:element name="jobId" "/>
		</xs:sequence>
	</xs:complexType>
</xs:element>

instead of

<wsdl:message name="submitJobApplicationRequest" >
	<wsdl:part name="token" ></wsdl:part>
	<wsdl:part name="jobId" ></wsdl:part>
</wsdl:message>

Suggestion: ensure that

each of the arguments of the function SubmitJobApplication is of simple-type.
every invocation of the function is on the basis of single arguments, rather than by means of a complex-type or argumentCollection.

Report · Mar 21, 2024

Hi @BKBK

Thanks for your response. I have just tried what you have mentioned in regards to passing the arguments in the incorrect order and that seems to be what is triggering the issue!

Unless there is a workaround in Coldfusion to either not accept requests where the order of the arguments is incorrect, or somehow to stop Coldfusion from behaving this way in that case?!, then my only option is to try and find out which third party integration sends through requests with the arguments/parameters in the incorrect order and ask them to fix it.

In regards to the the suggestions you have provided, for what I can see, all the arguments of the function SubmitJobApplication are of simple-type (see here below) so that should already be covered

Report · Mar 22, 2024

Strange. I did a test, but was unable to reproduce your WSDL elements. Details of the test follow.

Having checked on the web-service page in the ColdFusion Administrator that the version is 2, I created the following web-service CFC:

<!--- Path under root: /workspace/CF_Project/wsdl_test/JobApplication.cfc --->
<cfcomponent wsversion="2" >
	<cffunction name="SubmitJobApplication" access="remote" returntype="String" output="no">
		<cfargument name="jobId" type="string" required="yes">	
		<cfargument name="token" type="string" required="yes">	
		<cfargument name="firstname" type="string" required="yes">	
		<cfargument name="resume" type="string" required="no">
		<cfargument name="isScreeningAnswered" type="boolean" required="no" default="false">	
		
		<cfset var wsResult="Job with ID " & arguments.jobId & " and Token " & arguments.token & ". " & 
		                     "Candidate's First Name: "  & arguments.firstname & ". " &
		                     "Candidate's resume:" & arguments.resume & ". " &
		                     "Is screening answered: " & arguments.isScreeningAnswered & "." >
		                      	
		<cfreturn wsResult>
		
	</cffunction>
</cfcomponent>

When I launch http://localhost:8500/workspace/CF_Project/wsdl_test/JobApplication.cfc?wsdl I get the following WSDL:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:ax213="http://rpc.xml.coldfusion/xsd" xmlns:ns="http://wsdl_test.cf_project" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:ns1="http://org.apache.axis2/xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://wsdl_test.cf_project">
<wsdl:types>
<xs:schema xmlns:ax214="http://rpc.xml.coldfusion/xsd" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://wsdl_test.cf_project">
<xs:import namespace="http://rpc.xml.coldfusion/xsd"/>
<xs:element name="workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="CFCInvocationException" nillable="true" type="ax214:CFCInvocationException"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="SubmitJobApplication">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="jobId" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="token" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="firstname" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="resume" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="isScreeningAnswered" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="SubmitJobApplicationResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="document">
<xs:sequence>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:schema>
<xs:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://rpc.xml.coldfusion/xsd">
<xs:complexType name="CFCInvocationException">
<xs:sequence/>
</xs:complexType>
<xs:complexType name="StructDelegate">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="entries" nillable="true" type="ax213:EntryDelegate"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EntryDelegate">
<xs:sequence>
<xs:element minOccurs="0" name="key" nillable="true" type="xs:anyType"/>
<xs:element minOccurs="0" name="value" nillable="true" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="QueryBean">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="columnList" nillable="true" type="xs:string"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="data" nillable="true" type="ax213:ArrayOfObject"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayOfObject">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="array" nillable="true" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DocumentDelegate">
<xs:sequence>
<xs:element minOccurs="0" name="document" nillable="true" type="ns:document"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayDelegate">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="array" nillable="true" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
<wsdl:message name="SubmitJobApplicationRequest">
<wsdl:part name="parameters" element="ns:SubmitJobApplication"/>
</wsdl:message>
<wsdl:message name="SubmitJobApplicationResponse">
<wsdl:part name="parameters" element="ns:SubmitJobApplicationResponse"/>
</wsdl:message>
<wsdl:message name="workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException">
<wsdl:part name="parameters" element="ns:workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException"/>
</wsdl:message>
<wsdl:portType name="workspace.CF_Project.wsdl_test.JobApplication.cfcPortType">
<wsdl:operation name="SubmitJobApplication">
<wsdl:input message="ns:SubmitJobApplicationRequest" wsaw:Action="urn:SubmitJobApplication"/>
<wsdl:output message="ns:SubmitJobApplicationResponse" wsaw:Action="urn:SubmitJobApplicationResponse"/>
<wsdl:fault message="ns:workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException" name="workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException" wsaw:Action="urn:SubmitJobApplicationworkspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="workspace.CF_Project.wsdl_test.JobApplication.cfcSoap11Binding" type="ns:workspace.CF_Project.wsdl_test.JobApplication.cfcPortType">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<wsdl:operation name="SubmitJobApplication">
<soap:operation soapAction="urn:SubmitJobApplication" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException">
<soap:fault use="literal" name="workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="workspace.CF_Project.wsdl_test.JobApplication.cfcSoap12Binding" type="ns:workspace.CF_Project.wsdl_test.JobApplication.cfcPortType">
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<wsdl:operation name="SubmitJobApplication">
<soap12:operation soapAction="urn:SubmitJobApplication" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
<wsdl:fault name="workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException">
<soap12:fault use="literal" name="workspace.CF_Project.wsdl_test.JobApplication.cfcCFCInvocationException"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="workspace.CF_Project.wsdl_test.JobApplication.cfc">
<wsdl:port name="workspace.CF_Project.wsdl_test.JobApplication.cfcHttpSoap11Endpoint" binding="ns:workspace.CF_Project.wsdl_test.JobApplication.cfcSoap11Binding">
<soap:address location="http://localhost:8500/workspace/CF_Project/wsdl_test/JobApplication.cfc"/>
</wsdl:port>
<wsdl:port name="workspace.CF_Project.wsdl_test.JobApplication.cfcHttpSoap12Endpoint" binding="ns:workspace.CF_Project.wsdl_test.JobApplication.cfcSoap12Binding">
<soap12:address location="http://localhost:8500/workspace/CF_Project/wsdl_test/JobApplication.cfc"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

The section containing the arguments looks different from yours:

I am therefore curious what WSDL you will get if you run my CFC. To do so, save the code as JobApplication.cfc. Then launch http://path/to/JobApplication.cfc?wsdl in a browser.

Report · Mar 22, 2024

There was a second part to my suggestion: how the web service is invoked. The suggestion is that you should test this invocation style,

<cfinvoke
	webservice="http://localhost:8500/workspace/CF_Project/wsdl_test/JobApplication.cfc?wsdl"
	method="submitJobApplication"
	returnvariable="jobApplicationResult">
		<cfinvokeargument name="jobId" value="Job1234">
		<cfinvokeargument name="token" value="5A6B7C#getTickCount()#">
		<cfinvokeargument name="firstname" value="Bkbk">
		<cfinvokeargument name="resume" value="'BKBK Work History'">
		<cfinvokeargument name="isScreeningAnswered" value="true">
</cfinvoke>
<cfoutput>#jobApplicationResult#</cfoutput>

as opposed to this one,

<cfscript>
stArgs = {jobId="Job1234",
	token="5A6B7C#getTickCount()#",	
	firstname="bkbk",
	resume="BKBK Work History",
	isScreeningAnswered=true};
</cfscript>

<cfinvoke	webservice="http://localhost:8500/workspace/CF_Project/wsdl_test/JobApplication.cfc?wsdl"
	method="submitJobApplication"
    argumentCollection="#stArgs#"
	returnvariable="jobApplicationResult">
</cfinvoke>
<cfoutput>#jobApplicationResult#</cfoutput>

Report · Mar 25, 2024

Hi @BKBK

On the server we have, CF has the web service version set up to 1 so I believe that is what causes the discrepancy on the way CF creates the wsdl

I first tried using your code with version 1 and then with version 2 and yeah, the wsdl are completely different

V1

<wsdl:definitions xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://test" xmlns:intf="http://test" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns1="http://rpc.xml.coldfusion" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://test">
<!-- WSDL created by ColdFusion -->
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://rpc.xml.coldfusion">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="CFCInvocationException">
<sequence/>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="SubmitJobApplicationResponse">
<wsdl:part name="SubmitJobApplicationReturn" type="xsd:string"> </wsdl:part>
</wsdl:message>
<wsdl:message name="CFCInvocationException">
<wsdl:part name="fault" type="tns1:CFCInvocationException"> </wsdl:part>
</wsdl:message>
<wsdl:message name="SubmitJobApplicationRequest">
<wsdl:part name="jobId" type="xsd:string"> </wsdl:part>
<wsdl:part name="token" type="xsd:string"> </wsdl:part>
<wsdl:part name="firstname" type="xsd:string"> </wsdl:part>
<wsdl:part name="resume" type="xsd:string"> </wsdl:part>
<wsdl:part name="isScreeningAnswered" type="xsd:boolean"> </wsdl:part>
</wsdl:message>
<wsdl:portType name="JobApplication">
<wsdl:operation name="SubmitJobApplication" parameterOrder="jobId token firstname resume isScreeningAnswered">
<wsdl:input message="impl:SubmitJobApplicationRequest" name="SubmitJobApplicationRequest"> </wsdl:input>
<wsdl:output message="impl:SubmitJobApplicationResponse" name="SubmitJobApplicationResponse"> </wsdl:output>
<wsdl:fault message="impl:CFCInvocationException" name="CFCInvocationException"> </wsdl:fault>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="JobApplication.cfcSoapBinding" type="impl:JobApplication">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SubmitJobApplication">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="SubmitJobApplicationRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://test" use="encoded"/>
</wsdl:input>
<wsdl:output name="SubmitJobApplicationResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://test" use="encoded"/>
</wsdl:output>
<wsdl:fault name="CFCInvocationException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="CFCInvocationException" namespace="http://test" use="encoded"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="JobApplicationService">
<wsdl:port binding="impl:JobApplication.cfcSoapBinding" name="JobApplication.cfc">
<wsdlsoap:address location="https://turbows.staging.turborecruit.com.au/test/JobApplication.cfc"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

V2

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:ns="http://test" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ax21="http://rpc.xml.coldfusion/xsd" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:ns1="http://org.apache.axis2/xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://test">
<wsdl:types>
<xs:schema xmlns:ax22="http://rpc.xml.coldfusion/xsd" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://test">
<xs:import namespace="http://rpc.xml.coldfusion/xsd"/>
<xs:element name="test.JobApplication.cfcCFCInvocationException">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="CFCInvocationException" nillable="true" type="ax22:CFCInvocationException"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="SubmitJobApplication">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="jobId" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="token" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="firstname" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="resume" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="isScreeningAnswered" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="SubmitJobApplicationResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="document">
<xs:sequence>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:schema>
<xs:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://rpc.xml.coldfusion/xsd">
<xs:complexType name="CFCInvocationException">
<xs:sequence/>
</xs:complexType>
<xs:complexType name="StructDelegate">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="entries" nillable="true" type="ax21:EntryDelegate"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EntryDelegate">
<xs:sequence>
<xs:element minOccurs="0" name="key" nillable="true" type="xs:anyType"/>
<xs:element minOccurs="0" name="value" nillable="true" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="QueryBean">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="columnList" nillable="true" type="xs:string"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="data" nillable="true" type="ax21:ArrayOfObject"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayOfObject">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="array" nillable="true" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DocumentDelegate">
<xs:sequence>
<xs:element minOccurs="0" name="document" nillable="true" type="ns:document"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayDelegate">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="array" nillable="true" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
<wsdl:message name="SubmitJobApplicationRequest">
<wsdl:part name="parameters" element="ns:SubmitJobApplication"/>
</wsdl:message>
<wsdl:message name="SubmitJobApplicationResponse">
<wsdl:part name="parameters" element="ns:SubmitJobApplicationResponse"/>
</wsdl:message>
<wsdl:message name="test.JobApplication.cfcCFCInvocationException">
<wsdl:part name="parameters" element="ns:test.JobApplication.cfcCFCInvocationException"/>
</wsdl:message>
<wsdl:portType name="test.JobApplication.cfcPortType">
<wsdl:operation name="SubmitJobApplication">
<wsdl:input message="ns:SubmitJobApplicationRequest" wsaw:Action="urn:SubmitJobApplication"/>
<wsdl:output message="ns:SubmitJobApplicationResponse" wsaw:Action="urn:SubmitJobApplicationResponse"/>
<wsdl:fault message="ns:test.JobApplication.cfcCFCInvocationException" name="test.JobApplication.cfcCFCInvocationException" wsaw:Action="urn:SubmitJobApplicationtest.JobApplication.cfcCFCInvocationException"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="test.JobApplication.cfcSoap11Binding" type="ns:test.JobApplication.cfcPortType">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<wsdl:operation name="SubmitJobApplication">
<soap:operation soapAction="urn:SubmitJobApplication" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="test.JobApplication.cfcCFCInvocationException">
<soap:fault use="literal" name="test.JobApplication.cfcCFCInvocationException"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="test.JobApplication.cfcSoap12Binding" type="ns:test.JobApplication.cfcPortType">
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<wsdl:operation name="SubmitJobApplication">
<soap12:operation soapAction="urn:SubmitJobApplication" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
<wsdl:fault name="test.JobApplication.cfcCFCInvocationException">
<soap12:fault use="literal" name="test.JobApplication.cfcCFCInvocationException"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="test.JobApplication.cfc">
<wsdl:port name="test.JobApplication.cfcHttpSoap11Endpoint" binding="ns:test.JobApplication.cfcSoap11Binding">
<soap:address location=""/>
</wsdl:port>
<wsdl:port name="test.JobApplication.cfcHttpsSoap11Endpoint" binding="ns:test.JobApplication.cfcSoap11Binding">
<soap:address location="https://turbows.staging.turborecruit.com.au:443/test/JobApplication.cfc"/>
</wsdl:port>
<wsdl:port name="test.JobApplication.cfcHttpSoap12Endpoint" binding="ns:test.JobApplication.cfcSoap12Binding">
<soap12:address location=""/>
</wsdl:port>
<wsdl:port name="test.JobApplication.cfcHttpsSoap12Endpoint" binding="ns:test.JobApplication.cfcSoap12Binding">
<soap12:address location="https://turbows.staging.turborecruit.com.au:443/test/JobApplication.cfc"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Based on your knowledge, if we were to upgrade from V1 to V2, would the issue with the parameter names still occur? And would there be issues with third party integrating into it?

Report · Mar 26, 2024

Seems like we're on to something. As I mentioned earlier in my tests, I had to first verify that :

the CFC has attribute wsversion="2";
the selected web service version in the ColdFusion Administrator is 2. Remember to press the button to Update Web Service Version.

Test that and see what happens.

Report · Mar 26, 2024

Hi @BKBK

The test I have done with your template has attribute wsversion="2" however on CF Admin that value is set to 1; If i was to change that on CF Admin to 2, then it would potentially affect all of our third party partners currently integrating with the API.

The official API CFC dosen't have any wsversion setup therefore it will default to what is specified on the CF Admin (which is currently version 1).

The interesting fact however is that, even if I don't specify wsversion="2" on the template you have provided and I consume that API passing the parameters in the incorrect order, Coldfusion does not alter the name of the parameters.

So then, I have checked again the <cfcomponent> tag of our API and noticed that we have all the following attributes setup

<cfcomponent name="JobApplicationsAPI" displayname="JobApplicationsAPI"  porttypename="JobApplicationsAPI" serviceportname="JobApplicationsAPI" hint="JobApplication web services">

I am not sure why the porttypename and serviceportname are set up with the same name as the component itself to be honest nor if there is a neeed for those to be there. I have tried changing them and at a first glance the parameter names are not changing but I will do more testing and revert back

Report · Mar 27, 2024

The way I see it, some subsystems/components should not have version 1, while others have version 2. I would make sure the web-service (Axis) version is either version 1 across the board, or else version 2.

If you are a web-service publisher, then you can specify the (same) version in:

the web-service CFC, as the wsversion attribute;
the Web Service page in the ColdFusion Administrator;
the configuration file, neo-xmlrpc.xml, as the element <var name='version'><string>1</string></var> or <var name='version'><string>2</string></var>

If you are a CFML web-service consumer, then you should specify the version - as the value of the wsversion attribute - when you create the web-service object using:

<cfoject>;
createobject();
<cfinvoke>.

The web-service / Axis version corresponds to the WSDL version. If the WSDL is version 1, then its URL is the usual http://path-to-web-service-cfc?wsdl. If the WSDL is version 2, then its URL is http://path-to-web-service-cfc?wsdl2.

For backward compatiblity, you may call a version 2 service using a URL that ends in ?wsdl. However, you may not call a version 1 service using a URL that ends in ?wsdl2.

For more suggestions on WSDL version compatibility, see the attached summary from Web service enhancements in ColdFusion.

Adobe Community

Coldfusion 2023 SOAP API, name of parameters on wsdl change to generic one