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.
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.
No comments:
Post a Comment