Support for AMF Protocol

Applies to LoadComplete 4.97, last modified on May 20, 2019

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.

Supported AMF Versions

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.

What Does AMF Support Mean

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.

If you record a user scenario on a web application using the AMF protocol, you will see the contents of AMF requests and responses in the scenario editor:

Contents of an AMF Request

Click the image to enlarge it.

The Content-Type attribute of AMF requests is application/x-amf:

Content-Type of an AMF Request

Parameter Attributes

For each parameter, LoadComplete displays the following information:

Column Description
Parameter The parameter name.

LoadComplete obtains the parameter name from the AMF stream. Parameters whose names LoadComplete fails to retrieve are reported as Unnamed. If there are several such parameters on the same tree level, they are reported as Unnamed (2), Unnamed (3) and so on. The index is restarted on each level.

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:

  • Target URI - the name of the method that must be used on the client side to handle an appropriate response.

  • Response URI - the name of the operation that will be used to match the response to the client invocation.

  • Header name - the remote operation or header name that will be used to handle an appropriate header.

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 Item[index_in_the_array], for example, Item[0], Item[1] and so on. Items of associative arrays are displayed with appropriate parameters, for instance, Item["MyAttrValue"].

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.

You use the path to create correlation rules for parameters. See Data Correlation.

You can also use the path to create data selectors and data replacers to extract parameters from responses and to replace the recorded parameters with the needed values.

How You Parameterize AMF Requests

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.

Specifics of AMF Support

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:

  • flex.messaging.io.ArrayCollection
  • flex.messaging.io.ObjectProxy
  • flex.messaging.io.ArrayList
  • DSK (shorthand version of flex.messaging.messages.AcknowledgeMessageExt)

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.

See Also

Load Testing With LoadComplete
Support for Flash and Flex Applications
Parameterizing RIA Traffic

Highlight search results