It is now easy to handle asynchronous request in loadrunner. I am not going to start with differentiating synchronous and asynchronous request here, as I suppose if you are here you already know the difference.
There are 3 types of Asynchronous requests, primarily -
-
Polling - Client sends HTTP requests to the server at regular intervals. The server responds with updates and this as a result updates the application interface inside the browser.
-
Long polling - Client sends an HTTP request to the server. Whenever there is an update available on the server, it responds with an HTTP response. As soon as client receives the response, it issues another request to the server.
-
Push - Client sends an HTTP request to the server. Server responds with a response that appears to never end, so that the connection is not closed by client. Whenever there is an update on the server, it sends that to the client over this open connection and if there is no real update available on the server, it sends PING messages to the client to prevent the connection from closing or getting timeout.
We will see the implementation to handle asynchronous poll call by using the web_reg_async function available in LR11.5 and above versions.
- Enable Async Scan in Recording Options - Navaigate to Recording Options>General>Code Generation> check “Async Scan” checkbox
Optional :- You can modify the default configuration used to recognise patterns of Async conversations during the scan by clicking the “Async Options” button.
-
Record the application with Async call, as usual.
-
After recording, the code will be generated and the Async Scan performed automatically.
- The results of the scan are then displayed in the Async tab of the Design Studio dialog, which is automatically presented at the end of script generation
- VuGen inserts a web_reg_async_attributes step before the start of the asynchronous conversation and comments out the repetitive calls in the script
- web_reg_async_attributes function has follwing attributes (callback functions are added to the AsyncCallbacks.c extra file):-
ID - Id used for asynchronous communication
URL - To start the ASYNC communication (will be checked in subsequent web_custom or web_submit requests)
Pattern - Type of Asynchronous request - push, poll, or long-poll
RequestCB - called before a request is sent
ResponseCB - callback is called after every response is received in the conversation.
-
VuGen adds a web_stop_async step at the end of the asynchronous conversation, this marks the end of ASYNC conversation
-
If the asynchronous request is of type poll adding web_sync function after the polling request and before web_stop_async will work like a do-while loop with exit criteria defined in AsyncCallbacks.c under Poll_1_ResponseCB function as shown below-
From Action.c
//Register a polling pattern
web_reg_async_attributes(“ID=Poll_1”,
“Pattern=Poll”,
“URL= http://TestURL.com”,
“PollIntervalMs=15200”,
“RequestCB=Push_0_RequestCB”,
“ResponseCB=Push_0_ResponseCB”,
LAST);
//Start the polling pattern
web_custom_request(“Test request”,
“URL= http://TestURL.com”,
“Method=POST”,
“TargetFrame=”,
“Resource=0”,
“RecContentType=text/xml”,
“Referer=”,
“Snapshot=t49.inf”,
“Mode=HTML”,
“EncType=text/xml; charset=utf-8”,
“Body=Testmsdfmsdsadas;.dsad”,
LAST);
//Wait for parameter to be created (see below in AsyncCallbacks.c)
web_sync(“ParamCreated=ready”,”RetryIntervalMs=18000”,”RetryTimeoutMs=3600000”,LAST);
web_stop_async(“ID=Push_0”,
LAST);
From AsyncCallbacks.c
//The response call-back is called after each polling response is received.
int Poll_1_ResponseCB(
const char * aResponseHeadersStr,
int aResponseHeadersLen,
const char * aResponseBodyStr,
int aResponseBodyLen,
int aHttpStatusCode)
{
//enter your implementation for ResponseCB() here
//Increment long-polling response counter
counter++;
//Set parameter value to indicate that 10 long-polling responses were received.
if (counter>10 (strcmp(aResponseBodyStr,”6000”)==0)) lr_save_string(“OK”,”ready”);
return WEB_ASYNC_CB_RC_OK;
}
During the replay
The matching request will be handled according to the Pattern attribute:
For a Poll pattern, the request will be sent repeatedly. That is, after a response for a polling request is received, replay will wait for an interval matching the polling interval
specified in the web_reg_async_attributes. After this interval has passed, another request will be sent, and so on.
For a Long Poll pattern, the request will be sent repeatedly. Another request will be sent as soon as a response for a polling request is received.
For a Push pattern, the response is expected to continue indefinitely (until it is terminated by either the server or the client).
Post your queries in the comment…..