A(nother) Reason to Love Adobe

689ee0dd-9d27-46c6-bb27-1f29ac4c6d03</s1:Id>
bbd12fa7-f292-4bc5-a37f-06234e877ad8</s1:UserId>
user-name</s1:UserName>
e6b3998c-13d9-49fe-a13e-7af27c8229fd</s1:ApplicationId>
</Token>
</SOAP-ENV:Header></pre>
The Id, UserId, and ApplicationId properties of the Token object (children of the Toeken element in XML parlance) are Guids (Globally Unique Identifiers). A Guid, at its core, is nothing more than a string. However, because it's got a different type/class, I am not able to use a simple string. I have to pass in a string to my Guid constructor to set the Token properties properly.

Setting up the Token in Flex is pretty easy. I actually blogged about it previously on working with SOAP responses. Basically, I just store the token returned from the authentication routine in a globally available Token object (okay, it's not really globally available, this is a PureMVC app, so I get it via a proxy!).

When I use the Flex-built AS3 classes to interact with one of the application's Web Services, I just do something along the lines of the following:

public function getReports( rptReq:ReportRequest ):void
{   
 rs = new ResearcherService();
 rs.addEventListener( FaultEvent.FAULT, oops );
 rs.addrequestReport_header( token );
 rs.addrequestReportEventListener( reportsRequestReceived );
 rs.requestReport( rptReq );
}

Pretty easy. Just create a new service, add a couple of event listeners, and throw the token into the header. So long as the method only returns what Flex considers a "simple" value, I'm good to go. The RequestReport method (above), does just that. It only returns a simple object that has a few properties (strings, numbers and one array). Easy.

However, this same Web Service has another method, GetRequestHistory, that is pretty complex as regards what it returns (strings, numbers, file data, other objects). When I tried to deploy similar code to what's above, I get a SOAP decoding error, as Flex cannot resolve the type of the returned data (Adobe refuses to fix this issue in Flex 3, having said it's fixed in Gumbo, which it is but I can't use alpha software for a this application, the software changes too frequently -- thanks, Adobe!). 

Anyway, in order to get the GetRequestHistory method to work, I need to use the "old school" WebService class (and then manually get to parse the SOAP response...fun!!!!). Here's the code to call GetRequestHistory with the WebService class, including setting up the SOAP header.

public function getRequestHistory():void
{  
 var qname:QName = new QName( "http://tempuri.org/", "Token" );
 var hdr:SOAPHeader = new SOAPHeader( qname, token );   
 ws = new WebService();
 ws.addHeader( hdr );
 ws.wsdl = "http://mydomain.com/MyService.asmx?wsdl";
 ws.addEventListener( FaultEvent.FAULT, oops );
 ws.addEventListener( LoadEvent.LOAD, wsHistoryReady );  
 ws.loadWSDL();   
}

private function wsHistoryReady( evt:LoadEvent ):void
{   
 ws.GetReportHistory.resultFormat = "e4x";
 ws.GetReportHistory.addEventListener( ResultEvent.RESULT, reportHistoryReceivedWS );
 ws.GetReportHistory( studyName );   
}

First, I create two variables, a qname (class: QName) and a header (class: SOAPHeader). The qname is a qualified name for the (SOAP) XML to be sent to the service. It defines a valid identifier for elements and attributes. You pass two attributes to the QName constructor: the URI of the namespace and the local name, both of which you would get from looking at the WSDL file. The local name is, so far as I can tell, the name of the object (or root XML element) you are passing. In my case, it's called Token (see the SOAP Header excerpt above for why/how this is the case).

Second, you pass the QName and object to the SOAPHeader constructor. Flex has now, in theory :), created the appropriate SOAP Header. All that's left is to apply it to the WebService instance, which is quite simple...you just pass the SOAPHeader variable (hdr in the code above) to the addHeader method and you're good to go. 

Finally, load your WSDL and invoke your method! I've seen this step done a variety of ways but I prefer to add a LoadEvent listener to my WebService classes and only call my method once the WSDL has loaded (ws.addEventListener( LoadEvent.LOAD, wsHistoryReady );). Flex loads the WSDL really, really, fast and I've made calls to a WS method immediately after the loadWSDL() statement without any issues but this (waiting for the LoadEvent to fire) just seems a better practice to me.

The final note I'll make is that I had A LOT of trouble making the resultFormat of the WebService instance an "object" when dealing with the encoding/decoding issues I've mentioned. This wasn't really surprising to me because the Flex-generated Web Service classes couldn't decode the object returned from the SOAP, so why should the straight-up WebService class? 

Next up, manually decoding the freaking complex object/XML to the appropriate ActionScript objects so I can use the returned data in my application. Ugh.</div>
Comments