Larry,
Thanks for the information.. It is just really disappointing.. I sat
down.. downloaded/installed 7.0 dev.. and got a simple call working..
and was all excited.. and jumping up and down.. then.. this.. out goes
the reason to upgrade to 7.0.. :(
In 7.0, I can pass elements-in-elements but can't pass in element based
on a complex..
i.e following Works..
<request>
<version> </version>
<item>
<quantity> </quantity>
</item>
</request>
Not.
<request>
<version> </version>
<something type="complexType"> </something>
</request>
oh.. also I can pass in a XML Object for the soapHeader.. so I was
hopping from some magical way of doing this.. but from looks of it
there is none.
Thanks for the direct post.. option.. I didn't even think about that.. I
was just gonna go back to the straight XML API.. stupid me..
--
Regards,
Lawrence B. Afrin, M.D. wrote:
> Umer --
>
> As inferred by Dave Watts, your problem is that ns:DetailLevelCodeType
> defines a complex datatype, not the simple
> strings defined by the other parameters. Thus, the service you are trying to
> talk to requires you pass a
> complex-within-complex datatype, and the reason you are having difficulty
> figuring out how to do this is that ColdFusion
> can't do it.
>
> Your problem is exactly the same problem I (and my developer Doug James) have
> been pestering the cf-talk list about over
> the last few weeks, though the context for our problem (interfacing CF to
> UDDI web services) has been different from
> yours. Regardless, ColdFusion has no way to map ColdFusion
> structures-within-structures to the type of
> element-within-element XML messages required by WSDLs that define
> complex-within-complex structures. Why Macromedia
> hasn't yet provided a way to pass CF XML document objects, rather than just
> CF structures, to web services requiring
> complex-within-complex input arguments......well, I don't know.
>
> When you define a ColdFusion structure, the structure's keys become the names
> of XML *attributes* which modify the XML
> root element of the web service input argument to which you are feeding the
> structure, and the value of each key becomes
> the value of that XML attribute. For example:
>
> <cfset find_business = structNew()>
> <cfset find_business.generic = "2.0">
>
> is equivalent to
>
> <find_business generic="2.0">
>
> But, if the WSDL requires this...
>
> <find_business>
> <generic>2.0</generic>
> </find_business>
>
> ......ah, now you're stuck, for this is a complex-within-complex definition
> within the WSDL, and there is no way to build
> a structure within CFMX 6.x (nor within CFMX 7, as it turns out) that will
> get translated by CF into the above XML
> snippet as the Axis engine is building the outgoing SOAP message. Basically,
> you can't set up a CF
> structure-within-structure that'll get mapped to an element-within-element
> XML structure to be sent as the body of the
> SOAP message going out to the web service. And if you try to build the input
> XML message yourself and specify the
> resulting XML document object as the input argument in a <cfinvoke>, CF will
> just auto-translate this document object
> into a structure -- which will be in the wrong format compared to how Axis,
> after parsing the WSDL, expects to see the
> input argument.
>
> Solution? Yes, there is one. Basically, you have to bypass CFMX's Axis web
> services package and all the niceties it
> provides you. You need to build your own SOAP input message, HTTP POST it to
> the target web service, and parse the SOAP
> output message, as follows:
>
> <cfhttp method="POST"
> url="path-to-the-web-service-NOTE-not-the-path-to-the-WSDL">
> <cfhttpparam type="Header" name="SOAPAction" value="#chr(34)##chr(34)#">
> <cfhttpparam type="XML" value='<?xml version="1.0" encoding="UTF-8"
> ?><Envelope
> xmlns="http://schemas.xmlsoap.org/soap/envelope/";><Body><yourWSDL-compliantXMLinput
> messagegoeshere/></Envelope>'>
> </cfhttp>
> <cfif cfhttp.fileContent is not "Connection Failure">
> <cfset x = xmlparse(cfhttp.fileContent)>
> </cfif>
> <cfset soapoutputbody = x["soap:Envelope"]["soap:Body"]>
>
> Then you can dig deeper into the soapoutputbody XML document object to ferret
> out the return info you're really looking
> for.
>
> [Notes: (1) Depending on the web service you're tapping into, you may need to
> define the SOAPAction header as something
> other than the pair of double-quote marks shown above. (2) CFMX 6.0 won't
> suffice for this workaround. You need 6.1 or
> later, because it wasn't until 6.1 that the type="Header" and type="XML"
> attributes were added to the cfhttpparam tag,
> and these attributes are critical to making this workaround work.]
>
> The tough part to making this work is figuring out exactly what kind of a
> SOAP input message your target web service
> requires. Once you've got that figured out, doing the cfhttp and wading
> through an xmlparsing of the service's output
> is pretty straightforward.
>
> Doug and I recently brought this to Macromedia's attention, so we can hope
> that a 7.0 Updater, or 7.1, will correct this
> deficiency sometime within the next year or two.
>
> -- Larry Afrin
> Medical University of South Carolina
> [EMAIL PROTECTED]
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:195716
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
