Thursday, August 1, 2013

Protocols in Loadrunner Working with RMI-Java

This document is intended for an audience that is unfamiliar with the RMI Java protocol or Java Technology. Follow the below procedures, step-by-step sequence to ensure that the Java application can be invoked and recorded properly. If you failed at a particular point of step, please apply the appropriate solution before proceeding to the next step as the sequence below is designed to ensure that all requirements are met for the recording to succeed.

This document also complements KB 11878 which described the requirements needed for LoadRunner to record and replay Java-recorded scripts.

STEPS

[1] Launch the application outside VuGen
PURPOSE: To test if the application is functioning properly outside VuGen before the recording process.

[2] Apply the Java environment using the KB 11878, "LoadRunner Java Environmental Requirements".


[3] Create an empty RMI-Java VUser and replay it.
PURPOSE: To test if the basic Java environment is properly setup.

[4] Proceed to record the RMI-Java VUser.

[5] If application does not launch during recording
DIAGNOSIS: It could be that some classes are not loaded.

SOLUTION:
Ensure the CLASSPATH is set properly

Use javap.exe on the command line to check the missing method or class. To use javap.exe, run: javap.exe (without the ".class" suffix). When the class is not in the CLASSPATH, you will get the following error message: ‘Class not found’. Otherwise you will receive all its fields and methods.

From here onwards, look at the missing classes. If there is, obtain those classes from the developers of the application, and placed them into the CLASSPATH.

Use Java-Plugin to identify the error message. Troubleshoot the error accordingly. For the plugin, it will throw the exception into its console. You will have to turn on the Java Console (in Control Panel > Java > "Advanced" Tab > Select "Show Console" in order to capture the exception or information. If exceptions were captured in the console, look at the error message and troubleshoot from there. As the exceptions may vary, you will have to see what is been thrown out in order to resolve the problem and we won't be able to advise on it. (NOTE: The steps for the Java Console is based on JRE 1.5.0_06, therefore it may vary with other versions of Java Plugin.)

[6] If application launches but not recording (Green box illustrated below does not launch)




DIAGNOSIS: It could be that the default hooking mechanism is not loaded

SOLUTION:
Ensure the hook files are properly set
If custom hooking is involved. Verify the hooks are properly configured. Click link below to access it.
http://kb-index.mercury.com/web/queries/KBAview.asp?Conceptid=11287&Product=LR
Verify -Xrunjdkhook exist in the arguments passed to invoke the Java application. Below is a sample command line.

SET java -Xrunjdkhook -Xbootclasspath/p:\classes;\classes\srv -jar Kurnia-24AUG2006_1.jar

Ensure the file user.hooks is placed in \classes.
Verify the content of cjhook.ini
Enable in recording options > Recording Properties > Debug Options. Enable all checkboxes, and set "Hooking Options" > "Printout Redirections" to "File" instead of "Console".
After doing so, useful debugging information will be saved during recording in the file"/data/console.log", and "/data/console2.log".
Verify in Hooks profile \data\console.log after performing 6.6 and 6.7.

[7] Try running the -Xrunjdkhook outside VuGen via .bat file
PURPOSE: To verify the command statement with -Xrunjdkhook is working fine when invoking outside of VuGen.

[8] If the application is running fine with the hooking mechanism (-Xrunjdkhook) running (the green box being loaded), proceed with the next step.
DIAGNOSIS: If the green box is not loaded, it means that the hooking mechanism is not working.

SOLUTION:
Please troubleshoot from here on getting the hooking mechanism running following step 6.2.

[9] If Green recording box is invoked, however, no events were recorded or hang after a few events were recorded.
DIAGNOSIS: Some Class files may not be correctly configured in the CLASSPATH.

SOLUTION:
Apply the solutions in step 5.x
Ensure that all Class files for the placed correctly in (if any).

The recording should be working properly if all steps are applied in sequence unless otherwise. You can also try to install the same version of JDK developing the application into the recording machine, if the above steps did not work.

ADDITIONAL NOTE 

1. What is the version of the JDK? It is required that JDK be installed instead of JRE.
2. Is QTP installed on the machine?
3. Try recording from another machine and see if the problem persists.

FINAL NOTE

RMI Java is concerned about the class files if they exist in order for the recording to be successful. Therefore, the fundamental is to

(1) ensure that CLASSPATH are correctly configured and
(2) if the class files launching the application and needed by the business process being recorded, EXIST in the CLASSPATH.

Minimize your script debug time by using “On demand log functions" in Load Runner

More than often, I see people using Log settings available in Run-Time settings and completely ignore the function “lr_set_debug_messag(),” which I think Mercury has thoughtfully created, because it is genuinely useful in many occasions. Say, you’re dealing with a script with 5,000 lines and you have trouble correlating a certain dynamic string which you know for sure appears after a certain request in the 2000th line is fired to the AUT. Now, if you were to use just use the Extended Log option from the Run-Time settings of LoadRunner, then, it would take huge about of time during replay to arrive till the 2000th line of the script, because it has to parse and display all the data returned from server onto the screen – right from the beginning of the script.

Here is when “lr_set_debug_messag()” comes in handy. All you have to do is place this function above the request which generates the response from where you intend to debug your script. Make sure that you turn off Extended Log option in the Run-Time settings when you use this function. This measure ensures that your extended log option is triggered only at places where you want them and hence will save you huge amount of time while debugging.

In the below example, I have created three functions and I generally place these functions inside global.h section of my script. During debug cycles, I just call “logs_on()” function when I need extended log(with data returned from server and parameter substitution details enabled) for a certain server response and I use “logs_off()” function at the line in the script from where I don’t want anymore logs to be displayed. And I use “logclear()” function when LoadRunner doesn’t respond to logs_off() function(It is a known defect.)

logs_on()
{
lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG |LR_MSG_CLASS_RESULT_DATA| LR_MSG_CLASS_PARAMETERS , LR_SWITCH_ON );
}

logs_off()
{
lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG |LR_MSG_CLASS_RESULT_DATA| LR_MSG_CLASS_PARAMETERS , LR_SWITCH_OFF );
}

void logclear(void)
{
unsigned int log_options = lr_get_debug_message();
lr_set_debug_message(log_options, LR_SWITCH_OFF);
return;
}