When working with any kind of LoadRunner Java-based vuser type, any string that appears within the script may be parameterised. This differs significantly from all of the C-based vuser types, where only functions that are labelled as “parameterizable” may be parameterised without explicitly calling lr_eval_string().
This is a simple example of parameterisation with a Java-based script:
lr.save_string("jumped", "myParam");
String message = "the quick brown fox <myParam> over the lazy dog";
lr.output_message(message);
Rather than trying to do something that is theoretically impossible such as overloading the String class to handle this extra functionality, the LoadRunner developers did the simplest thing that could possibly work. They added a pre-compilation step that does a simple find-and-replace, with every <Parameter> automatically replaced with “+lr.eval_string(“<Parameter>”)+”.
lr.save_string("jumped", "myParam");
String message = "the quick brown fox "+lr_eval_string("<myParam>")+" over the lazy dog";
lr.output_message(message);
The only unintended side-effect of this is that it now makes it possible to get a stack overflow while “compiling” (see my Introduction to LoadRunner CORBA Vusers for a work-around).
8 Comments
Comments are closed.
Now that I think about it, you could easily implement the same thing with a preprocessor macro for C-based LoadRunner scripts.
Great Detail Stuart, Very useful info:-) appreciate your putting the article.
Thanks
Great Detail Stuart, Very useful info:-) appreciate your putting the article.
Thanks
Does LR9.1 supports JDK1.4.2_08? As my Java Cleint Server application is developed in JDK1.4.2_08 environment.
I read this and it’s extremely helpful. Thank you. I also read your other articles about scripting with ‘Java Record Replay’ protocol.
Thanks for the article Stuart.
Is there a way to implement VTS or SQUID in Jave record replay scripts on LR?
web.reg_save_param(“CorrelationID”,
“LB=”,
“RB=”,
LAST);
How can we implement web_reg_save_param in here..