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?
LVL 16
RCorfmanAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

PluckaCommented:
RCorfman,

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

Regards
Plucka

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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?
PluckaCommented:
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.
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

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" />
</wsdl:message>

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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Web Servers

From novice to tech pro — start learning today.