AxisFault: ColdFusion Web Services And XML Data Types

Posted June 15, 2009 at 10:23 AM

Tags: ColdFusion

A little while ago, I was helping someone debug a ColdFusion, SOAP-Based, web service error. Web services in general are not easy to debug and the problem was not too obvious, so I thought I'd post it here. To narrow down the problem, I set up a sample web service with just enough logic to duplicate the error. Here is the remote ColdFusion component:

 Launch code in new window » Download code as text file »

As you can see from the code, all this remote web service does it take an XML string, parse it, search for the value node, and return the text of that node. To invoke the web service, I simply created the XML data and posted it to the web service using CFInvoke:

 Launch code in new window » Download code as text file »

Nothing out of the ordinary going on here; but, when I invoke the web service, I get this ColdFusion error:

Cannot perform web service invocation Test. The fault returned when invoking the web service operation is:<br> <pre>AxisFault faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException faultSubcode: faultString: coldfusion.xml.rpc.CFCInvocationException: [coldfusion.xml.XmlProcessException : An error occured while Parsing an XML document.] faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}stackTrace:coldfusion.xml.rpc.CFCInvocationException: [coldfusion.xml.XmlProcessException : An error occured while Parsing an XML document.]

If you look at the error, you'll see that it was thrown "while Parsing an XML document." This parse is performed in the XmlSearch() method call. So, why is the XmlParse() method failing? After all, if it made it to the XmlSearch() method, then it means that the CFArgument of type, "XML," was fine.

The problem is that "XML" means something different in ColdFusion depending on where it is used. If it's used completely within the ColdFusion application, XML is the standard XML that we are used to dealing with - either an XML string or the ColdFusion XML document. Once, we leave ColdFusion and venture into the web service world, however, XML appears to be a different beast. If we add a CFDump to our remote access web service:

 Launch code in new window » Download code as text file »

... we get the following output:

As you can see, the XML document that came through wasn't the XML data string that we passed in; it was the Xerces XML document (which, if I had to guess is the Java object that ColdFusion XML documents decorate). It seems that the due to the XML data type, ColdFusion tried to implicitly convert the XML string into an XML document. Because this is no longer an XML string, but a complex XML Java object, XmlParse() doesn't know what to do and throws the above error.

To get around this, all we have to do is change our CFArgument data type from "XML" to "String":

 Launch code in new window » Download code as text file »

This gets rid of the error completely and allows the web service to return.

So, the moral of the story I guess is that while we can easily swap between data types in ColdFusion, once we have to interact with the outside world, we have to be really careful how we define our data. To the outside world, an XML object is NOT the same thing as the string representation of an XML object. It's actually not the same thing in ColdFusion either, but, due to run-time automatic data conversions of a typeless language, we rarely have to worry about it.

Download Code Snippet ZIP File

Post Comment  |  Ask Ben  |  Permalink  |  Other Searches  |  Print Page

• Add To Del.icio.us
• Add To Digg
• Add to Spurl.net
• Add to Wists
• Add to Simpy
• Add to Newsvine
• Add to BlinkList
• Add to Furl
• Add to reddit
• Add to FARK
• Add to BlogMarks
• Add to Yahoo! My Web
• Add to smarking
• Add to Ma.gnolia
• Add to Segnalo

Reader Comments

If I replace your cfsavecontent with this:

<cfxml variable="strData">
<data>
<value>Test</value>
</data>
</cfxml>

I get the same error, and it is definitely a XML object being passed.

@Stefan,

If you switch to CFXML, you have to remove the XmlParse() call. Then, it should work fine.

Ah, that is true. But the data is still not considered being XML -
<cfreturn isXML(ARGUMENTS.Data)> returns 'NO' in the cfc, but when tested before being sent in, it says 'YES'. Some strangeness there.

(I put that in before the XmlSearch so I never actually got there)

@Stefan,

Try IsXmlDoc(). It's meant for already-parsed documents.

IsXmlDoc() also returns false. But using your original code, with cfsavecontent and type="xml", it works if you skip the XMLParse().

If I send in a CFXML created object and use type="any", isXML returns true, if i use type="xml", isXML returns false. If I skip XMLParse, the XMLSearch works in all cases, so it does not seem to need XMLParse()?. Seems very strange for me. XMLSearch() has no problem working with a xmlString instead of a xmlDoc.

I guess the bottom line is that you can use type="xml" as long as you do not do XMLParse on the argument before using it, because it turns it into an XML object automatically, regardless if you pass a XML string or a XMLDoc.

@Stefan,

I believe XmlSearch() can take either an XML string or an XML document.

Yes. But what I meant is that the error you got was because you tried to do XMLParse on something that was turned into a xml object when you set the type to XML. An argument of type xml can be an xml string or a xml object. So rather than changing the argument type to string, I think it is better to skip xmlParse.

The strange thing, as I see it, is when you invoke the webservice as a component, then it does not to parse it. On the contrary, it seem to un-parse it.

If you <cfreturn arguments.data /> from the cfc
and dump the return value, you will see a xmlDoc from the webservice and a XML string from the component, regardless if you send in a string or a xmlDoc.

To me, it seem like a bug that the XML object you send into a component is turned into a XML string. I would not expect that.

But I am easily confused :)

WebService data types can be a pain in the ass. If you cast everything to a string you can always inside your own application cast them to the appropriate data type. Especially if you connect to other platforms the casting can be problematic, I've had troubles with .NET webservices vs. Coldfusion webservices (which are java thing) but obviously if everything are strings they can casted to the approriate data type.

@Marko,

Yeah, strings are easy to parse back and forth. When it comes to SOAP, generally, I prefer to actually write the XML myself and pass that via CFHTTP so there are no surprises. I've just had trouble with complex type casting so many times in the past.

Ben,
I'm trying to get the data from .asmx?wsdl
but all I see are the methods, just like your screen shot. I'm the consumer of web service so I can do anything with changing the datatype if they're using xml instead of string.
So how can I get my data? I've been searching anywhere with no success

@Mega,

At the end of the day, SOAP is just an XML based standard. If you need to, you can create your own SOAP XML and post that using something like CFHTTP rather than trying to create a web service object. This will give you ultimate control over the way the data is passed. The WSDL file should define the overall XML data structure.

Post Comment  |  Ask Ben

Post A Comment

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Formatting: <strong>bold</strong> <em>italic<em>
	Remember my information
	Subscribe to entry *
	Send me a copy of this comment (as part of the comment thread)

 

* If you subscribe, any new posts to this thread will be sent to your email address.