The Action Message Format protocol (AMF) is typically used by Adobe Flash and Flex applications to exchange data with the web server. This topic describes how LoadComplete supports the protocol.
AMF is a binary protocol based on the SOAP protocol. Currently, there are two versions of AMF: AMF0 and AMF3.
LoadComplete fully supports AMF, both AMF0 and AMF3 versions.
LoadComplete can detect AMF requests and responses and provides you with access to individual data values that are sent to or received from the server. LoadComplete can decode data from and encode it into the AMF binary stream. This feature lets you easily parameterize AMF traffic (for instance, traffic of Flash and Flex applications).
Also, LoadComplete supports automatic correlation of AMF request and response data. See About Data Correlation.
Content-Type attribute of AMF requests is application/x-amf:
For each parameter, LoadComplete displays the following information:
|Parameter||The parameter name.
LoadComplete obtains the parameter name from the AMF stream. Parameters whose names LoadComplete fails to retrieve are reported as
The root element of the parameter tree corresponds either to the Message or to the Header data block. These blocks are created by the server automatically and contain some service information along with the response body contents. Below is a brief description of the service parameters received from the server:
As these parameters store service information for parsing requests sent through the AMF protocol, it is not allowed to change the values of these parameters. For more information on the parameters described above, refer to the Adobe web site.
Array items are displayed as
Byte arrays, whose size exceeds 50 bytes, are displayed as strings. Shorter byte arrays are displayed as arrays.
|Type||The parameter type and the protocol version in which this type is defined (declaration of some types can be different in different protocol versions).
For parameters of the Object type, LoadComplete can also display the object’s class name as it is used in the source code.
If you are testing an application that uses AMF3, some cells can still display AMF0. This is the way the web server codes protocol version and data types in AMF requests.
|Value||The parameter value as it was during the scenario recording.
If a parameter of the String type is empty, LoadComplete will not display anything in the cell.
If you see that a parameter has the String type and the Value is nil, it means that the parameter contains the string “nil”.
|Variable||In responses, you use variables to store parameter values that LoadComplete extracts during a test run. You can then use those values in subsequent requests.
In requests, you replace the recorded parameter value with the value of the specified variable. This can be either a value extracted from a previous response, or a value that LoadComplete generates or loads from an external file.
|Path||The path to the parameter in the parameter tree, starting from the root element.|
The key benefit of accessing data values passed in AMF streams is that you can change them in your tests. This helps you pass information from earlier requests to further requests with ease. The entire procedure is very simple:
Open your scenario for editing.
In the scenario editor, find the request that obtains data from the server.
For more information on parameterization, see Parameterizing Rich Internet Application Traffic.
|Note:||LoadComplete does not change the request structure. You can change parameter values, but you cannot create or delete parameters or change their type.|
Flash or Flex objects can implement the
flash.utils.IExternalizable interface and fully control the way an object is serialized. LoadComplete supports only some of these objects, namely:
DSK(shorthand version of
As for other objects implementing the
IExternalizable interface, LoadComplete does not parse them and does not support modifying data in them. In the Parameters tab it displays these objects as objects of the
[Binary data] type.