How to Record-Replay JAVA with LoadRunner ?

On increasingly rare occasions, you might be required to load test an application that has a Java-based client. While it’s nice for users to have an application that has a rich GUI, it will probably lead to a world of pain for you as a performance tester.
Don’t immediately reach for LoadRunner’s Java Record-Replay virtual user type. It might not be the right solution.

This article will guide you through your first steps when selecting the correct vuser type to test an application with a Java-based client…

There are several LoadRunner vuser types that are candidates for your test. Your first task is to pick the correct one. The possible vuser types are:

• Web (HTTP/HTML)
• Java
• Windows Sockets
• Citrix
• JAVA Record Replay

HP sells each of these vuser types are in separate license bundles, so you can’t just buy LoadRunner and figure out the vuser type later.
In order to pick the most appropriate virtual user type, you need to know what protocol the Java client uses to communicate with the server. It is best to talk to an architect (or someone else who is suitably technical), but a smart performance tester backs up this conversation by recording the application to see if the architect is correct. You may like to use the LoadRunner Protocol Advisor, but I am old-school, so I record the application with the Windows Sockets vuser, or inspect the network traffic with WireShark.
If you are really lucky, your Java application communicates using HTTP – I had a Java “Web Start” application that just sent SOAP/XML messages to the server. In this case, you can just record using a standard Web (HTTP/HTML) vuser. All your requests will be recorded as web_custom_request, and you can reformat your requests so that they are readable, and do all kinds of neat things with XPath and the lr_xml functions.
The Java vuser is part of the “template” vuser bundle. You can put any Java code you like in these scripts, but there is no ability to record an application. This makes this vuser type only useful for very simple situations where you can confidently rewrite code that will make all the server calls that the client makes – I would only use this vuser type in situations where the application does something trivial like putting a message on a queue.
While you will definitely be able to record your application with the Windows Sockets vuser (winsock), there is only a 1 in a million chance that this is the correct vuser type for you. The basic rule of thumb is: if the captured network traffic that you see is plaintext, and you can figure out the details of the protocol just by eyeballing it for a few seconds, then maybe it is okay to use the winsock vuser type; in all other cases, avoid it. Don’t try to write code in C that will deserialise Java objects.
The Citrix vuser type is like a Get Out of Jail Free card for difficult to script applications. You can bypass all the protocol-level (or method-level) mucking around and just create a script that clicks on the buttons etc in the application. Citrix isn’t the cleanest or most reliable protocol, but a week of hacking at a Citrix script beats many weeks of pain using the Java Record-Replay vuser. Note that you will need to have a Citrix server to run the Citrix vusers against.
Have I dropped enough hints that using the Java Record-Replay vuser type is difficult and not much fun? I have created scripts for a few applications using this protocol now, and it is still not one that I would feel comfortable giving a time estimate for scripting with.
This vuser type works differently from most other vuser types in that it does not record protocol-level traffic, it records Java method calls and their arguments. Obviously if you record every single method call, your script will be huge and unusable, but if you record the method calls that are close to the point where data is sent to the server (while avoiding the low-level java.net classes), you might be able to massage your script into something that actually sends the same requests as the real application.
“Hooks” files instruct the recording engine which methods to record. They will look kind of familiar to people who are used to customising HP Diagnostics. Here is an example from my user.hooks file…

1 2 3 4 5 6 7

[oracle.jdbc.driver.OracleStatement] ;---------- oracle.jdbc.driver.OracleStatement -------- class = oracle.jdbc.driver.OracleStatement method = executeQuery signature = !.* cb_class = mercury.corba.CORBASupport general_cb = true

If you look for files with a .hooks extension under your LoadRunner directory, you will see hooks files for four main protocols RMI, CORBA (BEA Weblogic, Iona OrbixWeb, Visigenic/Inprise Visibroker), JMS, Jacada; and various extensions and JNDI, EJB, JNDI, JTA, ORBacus etc.

Even if your protocol is listed, don’t get too excited. It won’t necessarily work without lots of tweaking. If you need to develop your own custom points file (user.hooks) for your application, it is even more effort work. Don’t expect to be able to do anything useful with this virtual user type unless you have a solid Java background.
The good news (I guess), is that this vuser type will be able to (eventually) record and replay any Java-based application. The bad news is that you may not be able to get it working by yourself – I have seen smart people reduced to helplessness by this vuser type.
Don’t try to do it when you are on a tight deadline. And don’t assume that just because you can record something from your application with this vuser type with the out of the box configuration, that you will be able to get your script to replay successfully (or accurately) without a lot of hard work.
If I have a choice (and the Web vuser does not work), I would always prefer to use Citrix, rather than battle with the Java Record-Replay vuser again.