During a partial refactoring process of the Behrloo client system, one of the items on my list was the backend webservice result processing. Without going into a lot of detail how these services are wrapped, it suffices to say that somewhere in the application a couple of webservices are being initialized and utilized through the macromedia webservice classes.

You might be familiar with them, they come in several flavours, for example the WebServiceConnector and the Webservice class. Personally I don’t like to use the WebServiceConnector, mostly since the Webservice class is simple enough to use and tends to give you more control over what is happening.

Basic example

As a simple example of using this Webservice class, paste the following code onto the first frame of the timeline in a new fla document (on a sidenote, REAL applications are not written on a timeline, but for example purposes/quick proof of concepts, this will do just fine):

//example 1
import mx.services.*;

var lLog:Log = new Log (Log.VERBOSE, "myLog");
var lWebService:WebService =
     new WebService ("http://www.flash-mx.com/mm/tips/tips.cfc?wsdl", lLog);

You’ll note some log information passing by in your output window, showing you the progress during the initialization process and such. Somewhere at the end you’ll see a line like:

4/23 13:14:32 [INFO] myLog: Made SOAPCall for operation getTipByProduct

This means the webservice supports an operation called getTipByProduct. Other than that you don’t really know much about it. This is the first step in handling webservices, getting a grip on what your dealing with. Although there are different methods for doing so, I’ll mention two:
1. the webservice panel in flash, this allows you to enter a webservice url, and check the methods including the required parameters and expected return types in flash.
2. WebServiceStudio, a neat little tool. You might need to disable your proxy if it is giving you the same headaches as ours, but other than that, this tool will let you open, inspect and interrogate webservices.

Looking through Flash’s helpfiles you’ll find an example where the getTipByProduct is called with a string argument of “Flash”, so let’s try that one by extending our example.

Webservices are asynchronous

First thing to realize is that, just like most things in flash, a webservice is asynchronous, meaning that code following the instantiation of a webservice will execute before the webservice is actually instantiated. An example that demonstrates this fact extends the previous example:

//example 1
import mx.services.*;

var lLog:Log = new Log (Log.VERBOSE, "myLog");
var lWebService:WebService =
    new WebService ("http://www.flash-mx.com/mm/tips/tips.cfc?wsdl", lLog);

//example 2 addition
trace ("*** You'll see me before the log output has completed ***");

This ofcourse means that if you try to call a method on the webservice before it has been instantiated the call will fail. In other words: we will have to wait till it has been successfully instantiated. Without too much further explanation, we’ll just show the complete process of calling a method on the webservice and showing the results and then continue to the result processing part, since the process itself is explained in enough detail in the Flash Manual:

//example 1
import mx.services.*;

var lLog:Log = new Log (Log.VERBOSE, "myLog");
var lWebService:WebService =
   new WebService ("http://www.flash-mx.com/mm/tips/tips.cfc?wsdl", lLog);

//example 2 addition
trace ("*** You'll see me before the log output has completed ***");

//example 3 addition
import mx.utils.Delegate;

lWebService.onFault = function () { trace ("WHOOPS!"); }
lWebService.onLoad = Delegate.create (this, _performExampleCall);

function _performExampleCall() {
   trace("\n\nPerforming example call...");
   var lPendingCall:PendingCall = lWebService.getTipByProduct("Flash");
   lPendingCall.onResult = Delegate.create (this, _parseResult);
}

function _parseResult (pResults:Object) {
   trace ("\n\nResults:\n"+pResults);
}

Decoding webservices results

The thing to note in this example is that the result is a simple string. However, and that is were we get to the interesting part of this post: that is not always the case. The result could be an array, a predefined class, or some other complex object. This is were a couple of other settings/flags come into play:

- doDecoding
- doLazyDecoding

The Flash manual has this to say with respect to these two flags:

SOAPCall.doDecoding-description:
Turns decoding of the XML response on (true) or off (false). By default, the XML response is converted (decoded) into ActionScript objects. If you want just the XML, set SOAPCall.doDecoding to false.

SOAPCall.doLazyDecoding-description:
Turns “lazy decoding” of arrays on (true) or off (false). By default, a “lazy decoding” algorithm is used to delay turning SOAP arrays into ActionScript objects until the last moment; this makes functions execute much more quickly when returning large data sets. This means any arrays you receive from the remote location are ArrayProxy objects. Then when you access a particular index (foo[5]), that element is automatically decoded if necessary. You can turn this behavior off (which causes all arrays to be fully decoded) by setting SOAPCall.doLazyDecoding to false.

Let’s look into doDecoding first:

Although the description is pretty clear, the actual results I got when interpreting webservice results in Behrloo (which uses a .Net webservice backend), were kind of puzzling. When I turned decoding off, I still got an xml object as a result (while I was expecting a large string of some sort), and when I turned decoding on, I got an object which consisted of nodes of type String, Boolean, Array but also of XmlNode (so part of the result was still xml).

In the first implementation of the Behrloo backend, I had decoding turned on, and I dealt with both ‘decoded’ nodes, and xml nodes, which I decoded myself using several xml parsing mechanisms. However triggered by the testresults above, I decided to dive a bit deeper into the WebService class source code, and I found that under the hood the Webservice class is already an XML object to execute any calls to a webservice. This means that WHATEVER you do, the result is always already an XML object. With or without decoding.
With decoding turned on, it goes on to try and decode your object, EXCEPT for the nodes with an xsi:type=”…” attribute, which unfortunately most of my nodes had. I found no way to override this behavior, which means that the default decoding mechanism didn’t do a lot to help me.

Disabling the default decoding

By default, the result is decoded. This takes time, and is kind of useless if you are not using this feature anyway. However disabling the decoding cannot be done on a pendingcall since in order to get a reference to a pendingcall, you need to execute it first, so we disable the decoding through:

_myWebService.getCall ("<operation name here").doDecoding = false;

If you want to do this automatically for all calls defined on a webservice use something like:

for (var lOperationName:String in _myWebService.stub.activePort) {
	myWebService.getCall (lOperationName).doDecoding = false;
}

So what about doLazyDecoding?

LazyDecoding only kicks in if you have doDecoding enabled, after all if we do not decode anything, setting it to lazy has no effect.

Parsing the webservice result with decoding turned off

Well assuming you still want to use webservice and don’t want to switch to something like remoting, we use a simple XmlUtil class that converts XML objects to complete actionscript objects. In our project we need to interpret the complete result from the webservice, so this is feasible (in other words, we don’t spend time decoding object we don’t use anyway).

The source for our XmlUtil can be found here (save as XmlUtil.as in nl/trimm/util):
XmlUtil.as

Tags: flash, webservices