Scripting Issues occurred with Java Protocol in LoadRunner

      When writing a Loadrunner script that interacts with MQ, Websphere or Weblogic, as a scripter, you need to use the Java protocol.

This is a bit of a nuisance for those of us who have become familiar with C programming language
 and can use it with our eyes shut. The question is often asked, why do I need to use Java? I want
 to use C. Java can take a long time to use and logically seems to work quite differently to C.

Well, the answer is a little obvious (but only when you know the answer!) In order to develop
Automation for MQ, Weblogic or Websphere, you often need to use the same libraries that the developers
have used. The developers have often written the application in Java, and the supporting object libraries
 are the Java versions for the middleware products MQ, Weblogic and Websphere.

In many cases, the Loadrunner automation is simulating a device which runs the Java application. This
could be a desktop, laptop or a handheld terminal (HHT). The device contains a compiled version
of the code. This code is executed on one of three circumstances:

• The device is switched on and the operating system is configured to execute at start up

• An input is received from the device such as barcode being scanned

• A message is received from a middleware application such as MQ, Websphere or Weblogic

When executing an automated test script with Vugen, Loadrunner always compiles the script first.
 With a Java script, this will create a compiled version of the application similar to that which in the real
 world is located on the desktop, laptop or a handheld terminal. The main difference between the
 Loadrunner script and the real application is that the Loadrunner script would normally be written
 to process a distinct business function, i.e. it would contain only a subset of the functionality
of the real application.

In order to compile the application, the Loadrunner scripter needs to have access to the same common
 java files as the developer, the so called JAR files. The JAR files need to be accessible to Loadrunner
 when it compiles.This is done by entering the information into the runtime settings. By specifying
 the location of the classpath files in the runtime settings, you are telling Loadrunner where to find
the Classpath files so that compilation will work.

While this seems straightforward, the way Loadrunner works with the compiler means that it detects
 the names of the Classpath files, but does not necessarily determine where they are.

To get around this we can change the path statement on the environment variables for the machine
 running Vugen. This also does not always work. What should work is to physically place the JAR
 files in the Loadrunner directory of program files and set the Classpath statements accordingly.

At this point your script will compile and any other errors after this are down to real coding issues.