|Example: flex_amf_call||Flex AMF Alphabetical Listing|
Sends a Flex AMF request.
int flex_amf_call( <StepName>, <List of Attributes>, ["IsParseResponse=<yes/no>",] MESSAGE, "Method=<method name>", "TargetObjectId=<target name>", ["EnvelopeHeaderSetId=<header set name>",] BEGIN_ARGUMENTS, <Argument List>, END_ARGUMENTS, [,MESSAGE, <message section 2>, ... MESSAGE, <message section n>,] LAST );
This function returns LR_PASS (0) on success or LR_FAIL (1) on failure. Note that LR_PASS and LR_FAIL generally indicate whether the function call completed without an exception, and not that the test step succeeded.
All input string arguments (char type) except the step name can be parameterized using standard parameterization.
|StepName||A description of the action taken. Any text can be used. The step name is used as the transaction name for automatic transactions.|
|List of Attributes||See below in this section: List of Attributes.|
The setting applies to all INVOCATION blocks in the step.
|MESSAGE||A marker that specifies the beginning of the data of a new message. At least one message must be specified.|
|Method||The method to be remotely invoked.|
|TargetObjectId||The URI that specifies the object to receive the server's response.|
|EnvelopeHeaderSetId||Optional. The name of the envelope header set defined by an flex_amf_define_envelope_header_set call that preceded this step. These headers are applied only to the MESSAGE in which they appear. To use the same envelope header set in more than one message, enter it in each message definition.|
|BEGIN_ARGUMENTS||A marker that specifies the beginning of the argument list of the wrapping message.|
|Argument List||The arguments to the remotely invoked function.|
|END_ARGUMENTS||A marker that specifies the end of the argument list of the wrapping message.|
|LAST||A marker that indicates the end of the field list.|
The flex_amf_call function submits a Flex AMF request containing at least one message.
The argument order in the flex_amf_call must be identical to the parameter order in the method prototype. If there are no parameters, the section may be omitted or BEGIN_ARGUMENTS and END_ARGUMENTS may be entered with no arguments. For more details, see AMF Arguments.
The following asynchronous behaviors are supported:
- Poll – client polls server periodically for information.
- Long poll – client polls server and waits for answer. When answer arrives another poll request is initiated.
The terms used in asychronous-related topics are:
Asynchronous ConversationAn Asynchronous Conversation is a series of related web tasks, including tasks caused by redirection. An Asynchronous Conversation starts with the request for the desired response, includes all the requests and responses that are caused by this request (authentication, redirection, and so on) and ends when the desired response is received or when the series of interactions is canceled.
Asynchronous Conversation PatternA Pattern consists of one or more web tasks, issued and responded-to according to a predefined pattern, such as push, poll, or long poll. A Repetitive Pattern consists of more than one Conversation. For example, polling.
Gateway - The destination gateway is the destination URL for the POST.
The Flash Remoting gateway is a server-side object that brokers requests between Flash and the server and translates between Flash objects and the native objects for the server on which it is running.
Snapshot - (optional) The snapshot file name. If entering the call manually, do not use this attribute.
AMFHeaderSetId - (optional). This parameter specifies the name of a Flex AMF header set defined by a previous flex_amf_define_header_set call. These headers are added to the Flex AMF packet.
ResponseParameter - (optional). The output Vugen parameter containing the response data in XML format. Use the
ResponseParameter attribute when the response data is required for correlation. You can view the data in the replay snapshot or by outputting the value of the parameter.
IsParseResponse - (optional).
"IsParseResponse=No" prevents parsing the message during the test run.
"IsParseResponse=No" is added to the step if parsing fails when script is generated. It can also be added manually to improve performance if parsing is not required. There is usually no need to add
"IsParseResponse=Yes" to a step. It can be added to force an attempt when the test is run to parse a message that could not be parsed when the step was recorded.