Right, which works fine to pull the WSDL, but I needed to see what was actually being sent to the soap service. Because WSDL can specify an endpoint address other than the local address, once the web service had retrieved the WSDL, all calls to the actual web service itself were routed to the external address before the proxy could intercept them.
This is the line in the WSDL responsible for that: <port name="StiOrderServiceSoap" binding="s0:StiOrderServiceSoap"> <soap:address location="http://someaddress.com/SendOrder.asmx"; /> </port> Because it was set to someaddress.com, instead of my local machine, the SOAP calls were sent directly to that address. However, by pulling down the WSDL, changing that line to point to my machine, and then hosting the WSDL locally, I was able to use the proxy to intercept the traffic to and from the webservice. This is an awesome debugging tool for web service communication - especially between disparate web services platforms. Without it (or any other proxy that fills this need), I don't know how I would have been able to see the exact SOAP request I was generating. I finally found the technote on MM's site too (http://www.macromedia.com/support/coldfusion/ts/documents/tcpmonitor.htm) I'm surprised this isn't more publicized - it's really quite a nice CF freebie! For anyone that's interested - the final solution, which I figured out by viewing the outbound request, was that I needed to manually apply the namespace attribute to one of my manually-generated SOAP headers because the xmlns attribute added by the underlying apache axis engine gets a unique namespace prefix and that prefix wasn't jiving with the aasp.net web service :) It turned out to be only a slight modification of the code Sean posted on his blog way back when (thanks Sean - I owe you a beer or two): /Add the authorization header into the web service oHeader = createObject("java", "org.apache.axis.message.SOAPHeaderElement").init("", "AuthenticationToken"); oHeader.addAttribute("", "xmlns", "http://tempuri.org/";); oHeader.addChildElement("m_strInnerToken").addTextNode(variables.sAuthToken) ; ws.setHeader(oHeader); Thanks again to everyone who had a suggestion - I knew I could count on this list :) Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Watts Sent: Wednesday, June 16, 2004 7:15 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] way to dump a web service request > You're indeed correct :) I had to bring the WSDL down > locally and change the <soap:address location=""> property to > my machine - that's why it wasn't calling the local version! You shouldn't have to do that - all you should have to do is specify the WSDL URL using the proxy address, too. So, for example, if the web service is at foo.com, you'd configure the proxy to talk to foo.com, then rewrite your CFINVOKE tag to point to the proxy. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
