Tips on Load Runner Scripting for Smart Client
It is required to have Load Runner 8.1 or later version, since Load Runner version 7 does not record or send out http HEAD request This omission will cause the smart client not able to login to the server.
These are the recording steps, applicable for both smart client and JNLP recording:
- Start Load Runner 8.1 Virtual User Generator.
- Choose New User Script from pull down menu.
- Choose Web(HTTP/HTML) from “New Single Protocol Script” Window
- Choose Internet Application from “Start Recording” Window
- Choose HTML-based Scripts from “Recording Options”
- Choose “A script describing user_action(e.g. web_link, web_submit_form)” and “Record with the current script step” from “Advanced HTML” Window
- Start the recording
- An Internet Explorer browser will be brought up. Type in the url for downloading the smart client, like the normal way starting from the browser. After the smart client is downloaded, a create short cut message will be display and the smart client will be started to allow you to type in the user login name and password.
- If you get “System Internal Error” message, there is something wrong in your workspace.xml on your server. It needs to point to the deployed CRM application hostname/ip and port number. Search for the <server> tag to verify.
- You might want to pause the recording first. After you go through one iteration of all the desired operations, you then resume the recording. First iteration of the operations will download all the necessary objects to the cache which subsequent operations can use. These extra downloading is not necessary for repeated operations. A pause in the beginning can avoid the unnecessarily download.
- Go through all the recording steps as usual. Beware of the user names, objid, queue names, etc. Use the obvious names, since we need to fix the script with parameterization. Suggest that you use names, such as FN00000000, Queue0000, etc., something easiler to find later on with search command. Their object ids usually are the lowest ones in the table_contact, table_queue. It will be easier to search for and parameterize them.
After the script is recorded, you need to manually fix the script. These are the things need to be parameterized:
- Request and response payload from smart client are all in the binary, Serializable format. Proper formatting is required to guarantee the correct streaming between client and server. If there is an error in the serialized stream, you will receive IO Stream Corruption Exception on the server weblogic log. You need to monitor the weblogic server log to make sure your script does not generate unnoticed error.
- ASM ticket – after login, ASM ticket is returned in the reply and it is in the form of \\x007EXT<TksmauEz9mBb4u9tgdkpq6R9HGusc}pFT}7xPY0;appId=UIF;>, the subsequent request to the server need to pass this ASM ticket in the request header. Each session established will be assigned with a unique ASM ticket. This means, each http session needs to start with login with proper user login name and password. We need to extract this ASM ticket from the login process and retain it for future communication. After we record the script, we need to do a global replace of this ASM ticket string with a {ticket} parameter. Usually the first post request to the server in the login process will be returned with the ASM ticket. This is a snippet of the code to extract the ASM ticket:
web_reg_save_param("Ticket", "NotFound=ERROR", "LB/BIN=\\x007EXT", "RB=UIF", "ORD=1", LAST);
status = web_custom_request("crm_3",
"URL=http://{IP}:{Port}/crm",
"Method=POST",
"Resource=0",
"RecContentType=application/octet-stream",
"Referer=",
"Snapshot=t629.inf",
"Mode=HTTP",
"EncType=application/octet-stream",
…
LAST);
myStr = strlen(lr_eval_string("{Ticket}"));
if ( status == LR_FAIL || (myStr == 0)) {
lr_error_message ("Clarify Application Login failed with Status: %d\n", status);
lr_exit(LR_EXIT_VUSER ,LR_FAIL);
}
lr_message("This is the ticket: %s\n", lr_eval_string("{Ticket}"));
- Replace all the ASM ticket string in the script globally with the parameter {ticket}. The subsequent request body will have the ASM ticket. The code snippet looks like this:
web_custom_request("crm_25",
"URL=http://{IP}:{Port}/crm",
"Method=POST",
"Resource=0",
"RecContentType=application/octet-stream",
"Referer=",
"Snapshot=t382.inf",
"Mode=HTTP",
"EncType=application/octet-stream", "BodyBinary=\\xAC\\xED\\x00\\x05sr\\x00/com.amdocs.uif.common.datatype.RequestPayloadVo\\x00t\\xE0\\x8FR\\xB6\\xE0\\x92\\x0C\\x00\\x00xpw\t\\x01\\x00\\x00\\x01\\x13\\xFAx\\x89\\x1Dt\\x007EXT{Ticket}UIF;>w\\x1D\\x00\\x1Bqaperflab04_ReqThread_T3_24ur\\x000[Lcom.amdocs.uif.common.datatype.RequestGroupVo;\\xF4Z\\x03o\\xD91/"
…
LAST);
- According to the Java Serialization Spec, ASCII string needs to be prefixed with the string length. Go through the script to find the ASCII string that is passed to the server, and make sure the string length is correct prefixed. An example is: \\x08LN{SearchNumber}t\\x00 in the search caller operation. Our passing string for the search criteria is “LN000000”-eight characters long. There is \\x08 in hex number as the string length prefixed the string. An error could happen when you use the string of case id returned from the server in such as case overview and log note operations. When the case id number increases over time from 2 digits to 3 digits, for example, hard coded string length will be problematic. One way to avoid this problem is to generate the string length on the fly. For example, before the create case save step, insert the following code snippet:
sprintf(caseidlen,"%2x",strlen(lr_eval_string("{CaseTitle}")));
lr_save_string(caseidlen, "CaseIdLen");
Then use the CaseIdLen as the string length parameter in the subsequent case overview and log note operations along with the Case Id string. Such as:
x00\\x{CaseIdLen}{CaseId}t\\x00
- One quick fix for the above problem is toe fix the table_num_scheme table to force it always return a desired length. Of example, if your case id in table_num_scheme starts with 1000000, then you will have 1000001 to 9999999 to work with. It will last a while so that you don’t have to be concerned with the case id string length. Objid is always dealt in the digital format, so there is no need to prefix length for the objid.
- There is no easy way to parameterize all the names, objid in the script. When you record, you should record with some easy convention to remember and search names, such as 0000. Lower number of objids start with 268xxxxxx. Search for all 268 or 269 and examine each occurrence to see if they should be parameterized. Some of the things, like priority, severity, etc, don’t need to be changed.
- The string qaperflab04_ReqThread_T4_45 in the request payload can be ignored for now. However, in the future, they might be required to be unique for the server to work. In CIM and iSupport flow, we have found no need to change them at all. You can just leave them as they are.
- These are the code snippets to extract newly created case id and case objid id. Add them to the beginning of you create case save operation:
web_reg_save_param("CaseObjid", "NotFound=ERROR", "LB/BIN=objidt\\x00\\t", "RB=xpw", "ORD=1", LAST);
web_reg_save_param("CaseIdNumber", "NotFound=ERROR", "LB/BIN=id_numbert\\x00\\x06", "RB=t\x00", "ORD=1", LAST);
Great reading your blogg post
ReplyDelete