Java Over HTTP Project Setup and Testing

Prerequisites

For testing Java over HTTP applications, Java Development Kit 1.6 or later is required.

Transformation is enabled for HTTP requests and responses that have the HTTP header Content-Type set to "application/octet-stream" or "application/x-java-serialized-object". If you need to transform data with a different HTTP Content-Type header, see Transformation of Custom Content-Types.

Setting Up a Java Over HTTP Project

When outlining your project, be sure to select the Java over HTTP application type (Web browser/Java over HTTP on the Outline Project dialog).

By selecting the Java over HTTP application type, several profile settings are automatically configured for you on the tab Profile > Web Protocol Level > Transformation:

The Java over HTTP transformation DLL is selected in the Type drop list.
Transform HTTP Requests is enabled
Transform HTTP Responses is enabled
Enable Java Virtual Machine usage is enabled. This setting is required because Java over HTTP requires a running JVM for accurate transformation of serialized/externalizable Java objects. This setting also causes transformed binary Java traffic to appear in readable XML representation.

Modeling a Script

Using the JVM requires the configuration of Java over HTTP application-specific custom JAR files that contain the classes that are necessary for deserialization and transformation into correct XML representation. For this reason, when modeling a Java over HTTP script, the Model Script dialog includes an Add Custom JAR File(s) button. Click this button to browse to and Add any custom JAR files that are specific to the application under test. Added JAR files are displayed within the Project tree Data Files node.

Note: If your application is based on Spring Framework HTTP Invoker, you must add spring.jar to the classpath.

These required JAR files (or individual .class files) are located on the server to be tested. These files must be prepared manually and copied from the server to the Silk Performer controller machine.

Note: It is recommended that JAR files be placed in the Project folder.

Clicking Settings on the Model Script dialog links you directly to the current user profile, Java Settings tab. Use this to change Java settings for the currently selected user profile.

Note: Do not enable Use system classpath on the Java Settings tab. JAR files set in the system classpath may overrule manually configured JAR files.

Generating a Script from a Capture File

While recording a user transaction, the Silk Performer recorder creates a so-called Silk Performer capture file, which contains the entire traffic of the recorded session. After saving, the capture file is opened in the Workbench for further analysis and processing. Before generating a script from the captured traffic, you can configure recording rules and other settings, which are applied during the script generation process.

If any errors occur, click the buttons in the Resolve Problems area to resolve them. Then, click Generate Script to generate a script from the capture file.

On 64-bit operating systems, both a 32-bit and 64-bit Java installation are required. The 32-bit installation is used for replaying scripts, the 64-bit installation is used for generating scripts. If a 64-bit installation is not available, you can force Silk Performer to use a 32-bit process for script generation by setting the following registry key to 1: HKEY_LOCAL_MACHINE\SOFTWARE\Silk\SilkPerformer\<version>\Force32BitCaptureAnalyzer.

Attention: Using the 32-bit script generator can cause issues with large capture files.

Replaying a Script

If your Java configurations are incorrect (for example, if JAR files are missing), XML responses (only visible in TrueLog Explorer) will not be generated in an easily readable format. Also warnings or errors will be written to the Virtual User Output pane. Typically, errors and warnings indicate whether or not they were caused by requests (client to server) or responses (server to client).

Customizing Java Over HTTP Scripts

Do not change the overall structure of XML objects within Java over HTTP scripts. It is okay to parse values or insert verification functions, but deleting or rearranging Java over HTTP XML elements will destroy a call. Also do not change the order of elements within arrays.