Set up the framework environment
Before diving into the automation process, you need to correctly set up the framework environment. This involves configuring the WebSphere environment and creating the correct directory structures.
Since your application will be deployed inside a WebSphere Application Server, the first step is to configure the WebSphere environment. If you have not worked with WebSphere before, these instructions should provide you with enough information to set up your application to run against a database server. The WebSphere instance may be on your own client machine, or it may be on a separate machine. In this example, the WebSphere instance is on the client machine. If it is on a separate machine, ask your WebSphere administrator to help you complete these steps.
For your web application to connect to the transactional database, it needs to use a JDBC driver. That JDBC driver must be put on the WebSphere classpath. Set up the JDBC driver:
- In the WebSphere panel on the left, click JDBC providers.
Figure 2. Selecting JDBC providers
- Click on DB2® Universal JDBC Driver Provider.
Figure 3. Selecting the DB2 Universal JDBC Driver Provider
- This will bring up the classpath of the driver. Make sure your IBM JCC drivers and pureQuery drivers are on the classpath.
In this case, there is a WebSphere variable defined as
$DB2UNIVERSAL_JDBC_DRIVER_PATH,which points to a specific path. You can specify any path you want as long as they point to:
- pdq.jar (pureQuery Jar)
- pdqmgmt.jar (pureQuery License)
- db2jcc.jar (IBM JCC Driver to connect to database)
- db2jcc_license_ciuz.jar (IBM JCC Driver License)
- pdq_properties.jar (a properties file that will be used by your
Example: /home/users/lib/pdq.jar or C:/jars/pdq.jar. All these JAR files must exist in a directory that WebSphere can access. For more information on creating a directory for this, see the "Directory structure" section of this tutorial. If WebSphere is maintained on another machine, send the above files to the system administrator and have the administrator place those files on the classpath.
Next, you need to use this newly created JBDC Driver to create a data source.
- In the left WebSphere Panel, click
Data sources under JDBC.
Figure 4. Configuring the data source in WebSphere
- Click New to create a new data source.
- Enter the data source name you want. In this demo, it is called localhost, and the JNDI name is JDBC/localhost.
Figure 5. Configuration screen for new data source
- Choose the option Select an existing IBM JDBC Driver, then select the DB2 Universal JDBC Driver Provider that
you created earlier and click Next.
Figure 6. Specifying the JDBC driver
- Enter the database connection information and click Next.
Figure 7. Entering the database connection details
- At this point, you need to create a new security alias (a user ID and password) for this data source. Click on the
Global J2C authentication alias link.
Figure 8. Setting up the security alias
- Click the New button.
Figure 9. Setting up a new user identity
- Provide a name for this alias, and also the user ID and password for the data source that will be used to
connect to the database and click Apply.
Figure 10. Entering the authentication data properties
- Now you can select this authentication alias for your new data source.
Figure 11. Setting up the security alias
- Go to the next page and click Finish. The newly created data source should be in the list of
data source. Select it and click Test connection.
Figure 12. Testing the connection
- You should get a success message.
Figure 13. Successful connection
Any WebSphere application that utilizes client optimization can take advantage of this automation process. For the purpose of this tutorial, we have provided a sample application. The TestSPServlet.java file is the only application source and is provided to you in the Download section of the tutorial for demonstration purposes. It is packaged in the Test.war file (a web application archive) that will be deployed into WebSphere. As stated above, you are free to use your own web application archive.
The application runs for a specific period of time determined by the parameters set below.
Listing 1. TestSPServlet.java code
int totalIterations= 10; long timeForEachIteration= 60000;
totalIterations variable determines how
many times the application will run. The
timeforEachIteration is in
milliseconds, so the above setup runs the application for one hour.
The following steps deploy the Test.war file that includes the TestSPServlet.java file. If you are familiar with this process or have another application you want to deploy, you can skip this section.
- In the WebSphere navigation panel, expand the drop-down menu: Applications
> Application Types > WebSphere Enterprise
Figure 14. Enterprise applications in WebSphere
- Click Install on the following screen and browse to the folder where the Test.war application is located.
Figure 15. Path to the new application
- Click Next and choose Fast Path.
Figure 16. Method for installing the application
- Keep clicking Next until you reach the screen to map reference to resources.
Specify the JNDI name for the data source that the application will connect to. The JNDI data source name points to the
data source you created earlier: jdbc/localhost. Click
Figure 17. Map references to resources
- Enter the Context Root for the application. The example uses /Test and click Next.
Figure 18. Map context roots for Web modules
- Click Finish, then click Save.
Figure 19. Summary screen of options to install
You need to create a home directory where the all the necessary automation files and client optimization files will be stored. In this example, we use C:\repository.
Figure 20. Repository directory
The extract folder holds files extracted from the repository.
The upload folder contains pureQuery Runtime property files that will be used by the WebSphere application and also by the repository. It contains:
- pdq.properties file — This file is uploaded to the repository and will be loaded by the application during automatic pull-down.
- pdqapp.properties — This file is copied over and placed in the classpath of the WebSphere application server. It contains the pureQuery pdq.finalRepositoryProperties property that points to the repository. If WebSphere is on a remote machine, you will need to copy this file manually to the remote machine.
- pdqdynamic.properties and pdqstatic.properties — These files will override pdq.properties if you want to switch from dynamic capture to static execution.
The HTTP folder holds files returned by any HTTP requests by the application. The capture folder holds all the captured XML files produced from client optimization. The next directory holds all the WebSphere JAR files.
Figure 21. WebSphere JAR file directory
As mentioned in the WebSphere configuration section, the above-highlighted JAR files need to be included in the WebSphere classpath. Ensure that these files exist. The file pdq_properties.jar is just an archive file that contains pdqapp.properties. The properties file is in a JAR file so WebSphere can pick up the properties. If WebSphere is on your local machine, the automation system will copy over pdqapp.properties and archive it as pdq_properties.jar. If WebSphere is on a remote machine, you will manually need to issue jar -cvf pdq_properties.jar pdqapp.properties and place the machine on the remote WebSphere classpath. Ask your WebSphere administrator to do this on the machines that the administrator maintains.