This content has been marked as final. Show 7 replies
To make your web service request go through the proxy, you set the useProxy property of your web service to true, so
myService.useProxy = true;
If you set the wsdl property on the web service rather than specifying a destination, the destination DefaultHTTP that is defined in the proxy-config.xml file gets used. The destination has <dynamic-url> properties which contain url patterns that determine which urls the proxy lets through.
So, to wrap up. To use the proxy, set useProxy to true on your web service. Then edit the DefaultHTTP destination in proxy-config.xml and add a dynamic-url property that will allow your web service request to go through.
If you want to configure a destination on the server rather than using the wsdl property, look at the Configuring RPC Services -> Configuring destination properties -> Web service properties section in the developers guide. The doc on this is pretty good.
Thanks for the information Alex. The only thing that's still a bit foggy for me is where I am supposed to place this proxy-config.xml file? Do I just put it in the same folder on my web server as the SWF file for my flex application? I've seen people mention putting it in WEB-INF/flex but that seems to be a Java-specific folder. What if the site that hosts my SWF is ASP.NET or something?
Ok. I think I see what the confusion is. The WEB-INF/flex directory is a Java-specific folder. It's part of Flex Data Services, which is a j2ee web application. If you're not running the web application then you can't use the proxy.
Alex - thank you for clarifying this with me. I was confused over this point. I have seen reference to Flex Data Services and now I understand this part. I guess I'm just left with this question then ...
If I'm not using Data Services, do I not have any way of handing soap faults other than recieving an HTTP request error? If this is the case, this would be quite disappointing as this seems to kill the whole web services scenario.
This issue is a limitation of the plugin API provided by the browser.
Using FDS to proxy web service calls allows us to make the proxied call on your behalf from the server where this limitation doesn't exist. A 500 fault response can be returned as a 200 reponse that is readable by Flash.
If using FDS to proxy web service calls isn't an option and you need access to the information in SOAP faults, you'd need to do custom work on the server to reset the status code to 200 for the fault responses returned to Flash clients.
Seth - this is interesting info. So you are saying that when Flash makes external communication via the mx.rpc.http/soap objects that is uses an API on the web browser? Does the same apply to the flash.net objects?
The plugin player (non-IE) uses the browser plugin API to make its network calls. The IE player uses the Windows network stack to make its calls. This is true of the flash.net classes, as well as the mx.rpc classes (whose functionality is built on top of flash.net).