• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1316
  • Last Modified:

Webservice Providing with XML Type Argument

I'm working on writing a Webservice in MX 7. I have an argument defined as input type XML.  If I use the function isXML, isXMLDoc, or any of the other isXML functions on the argument, they return false. If I use isObject, it returns true. Any idea on how to process the passed argument as an XML object?

Right now, for testing, I'm using
<cfset xmObj = getSOAPRequest()>
<cfset xmarg = xmobj.xmlroot..xmlChildren[1].xmlChildren[1].xmlChildren[1]>

To get down to the level that I want to start processing.
I'd like to not do that and just have the argument BE and xml object. Any ideas?
  • 6
  • 2
1 Solution

Pass it in as type string, use XmlParse to get it to an XML object.

RCorfmanAuthor Commented:
No can do. I'm getting a complex document object from another system integrating with us. I have to accept an XML Object.  String wants to translate all those < and > symbols and won't work.  I have it working using getSoapRequest, but it seems strange.
Why, when I declare the argument as an XML Type, and I'm receiving an XML Type, isn't it defined as and xmltype with isXMLDoc or isXMLElement?
It does return true with isObject, but what the heck type of Object is it?
I think that you will find that the XML attribute type is XML text not XML object.

Have you tried not specifying a type and seeing what it comes through as.
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

RCorfmanAuthor Commented:
If I output the #argname#, the value is:
[#document: null]
RCorfmanAuthor Commented:
Maybe I misunderstood. I need the wsdl file to show something for the argument. It is bad enough with the xml type argument, as it shows an as
<wsdl:message name="myServiceRequest">
  <wsdl:part name="argname" type="apachesoap:Document" />

If I don't specify a type at all, then it uses the default... string
RCorfmanAuthor Commented:
I should have CFDumped it to start with.
<CFDUMP var="#argname#">
Turns out it is an object
object of org.apache.xerces.dom.DeferredDocumentImpl
It has a ton of methods, which you can see with CFDUMP.
I think it is probably somewhat of a waste of resources to turn around and store it in a CF XMLtype since it appears to be a Java XML Type, but I don't know that I want to mix up java 'stuff' in with my CF Page since I don't really know java, at least not well.
I'll at least post how to get it into a CM XML variable once I get to that point for posterity.
RCorfmanAuthor Commented:
<CFSET xmlString = argname.getNodeObject(1)>
<cfdump var="#xmlString#">
<CFSET xmlStringName = xmlString.getNodeName()>
<cfdump var="#xmlStringName#">

I was able to get the xmlStringName to be a normal string in cf that had my root element name of the passed in document, but I decided I don't know enough about that java class, org.apache.xerces.dom.DeferredDocumentImpl  to be able to dump it int a CF Xml object. I'm going to keep playing with the soapEnvelope, but this seems like a hard way to go. I'm still not overjoyed that XML webservice input type doesn't actually give a coldfusion xml object. It maybe that there really are efficiencies with using a DeferredDocumentImpl Java object, but it is beyond me for now.
RCorfmanAuthor Commented:
In the end, this was a more serious problem. Turns out coldfusion is not resolving the multiRef that websphere was passing to the webservice. CF7, at least in this initial version that we are using is broken in my opinion. type="xml" with a cfargument is broken, broken, broken. Not only does it not pass in a coldfusion xml variable (instead that java object), it also doesn't resolve the multiRef if it is utilized. I poked around with the DOM for the document using the Java object and found enough to know that I can't use it. I'd have to resort to using the entire envelope and I don't want to have to code the code to decode all those multiRef's websphere is passing... they are valid, but it is ugly.

In the end, we've mad the determiniation that both systems will go with the string object and I'll parse it from there.  The entire reason for upgrading from mx7 from 6 was to enable using the xml type and I can't anyway... go figure. I guess upgrading isn't a bad thing, but still frustrating.  Thanks for the help Plucka.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 6
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now