IBM® Rational ® Test Workbench and IBM® Pure Application Server®
Service Virtualization in the IBM Pure Application Server
Lab Exercises
10/7/2018
IBM Software
Contents
Lab 1 Setting up Patterns......
1.1Deploy IBM Shared Service for Rational Installation Manager Repository......
1.2Deploy IBM Shared Service for Rational License Key Server......
1.3Deploy IBM Shared Service for Rational Test Virtualization Server......
1.4Configure the IBM Rational Test Workbench Pattern......
1.5Communicate to Software Engineers that the pattern is ready for use......
Lab 2 Deploying the System Under Test......
2.1Construct the DayTrader Sample Virtual System Pattern......
2.2Deploy the DayTrader Sample Virtual System Instance......
Lab 3 Deploying a Rational Test Workbench Instance......
3.1Deploy the IBM Rational Test Workbench Instance......
3.2Connect to the Instance......
Lab 4 Preparing the SUT for Virtualization......
4.1Analyze the system under test......
4.2Instrument the Application Server......
Lab 5 Preparing the Shared Services for Virtualization......
5.1Open firewall ports on HTTP Proxy host......
5.2Open firewall ports on RIT Agent host......
5.3Respond to Software Engineer......
Lab 6 Virtualizing a Web Service......
6.1Record Web Service Messages......
6.2Create and Test a Web Service Stub......
6.3Deploy the Stub to Rational Test Virtualization Server......
Lab 7 Testing an Application using a Stub......
Appendix A.Deployment Topology......
Appendix B.Troubleshooting......
Appendix C.Glossary......
Appendix D.Notices......
Appendix E.Trademarks and copyrights......
Contents11/16/2013Page 1
IBM Software
Overview
Overview10/7/2018Page 1
IBM Software
The capabilities of the Rational Test Virtualization Server Shared Service and the Rational Test Workbench Pattern can best be demonstrated through a realistic example. The DayTrader sample from the Apache Geronimo project will be used in this workshop. A very simple architectural diagram is shown in Figure 1.
Figure 1: DayTrader Topology
Although both the web client and the web services components are running in the same instance of WebSphere Application Server, this is a three-tier architecture system. The DayTrader Web component is a client of the services provided by the DayTrader Web Service component. The DayTrader Web Service component is a client of services provided by the TRADEDB database.
Consider for a moment that you are a developer working on the DayTrader Web component. You need to test your work, but you find that because the DayTrader Web Service component is under development, it is constantly being taken down for maintenance and updates. This is making it very difficult for you to conduct integration testing.
Or consider you are a developer working on the DayTrader Web Services. You are finding that the test database you use is shared by many people. Constant updates and changes to the data are making it difficult for you to isolate issues you are finding in your code. You would really like to test your work with a variety of test data but have control over when it is refreshed and what goes into the database.
Test virtualization can help with both of those scenarios. In Lab 6 you will create and deploy a web service stub, enabling you to test the DayTrader web with minimal dependencies on the DayTrader Web Services.
How to perform these labs
There are several software components, patterns and host machines involved in this workshop and keeping track of all the hostnames, IP addresses, ports, etc. can be challenging. Appendix A contains a topology diagram including all the components that will be involved in these labs. The full architecture will be introduced a piece at a time as you perform the labs. It is recommended that you print out Appendix A and write the values for your specific deployment in the table in the lower left. Referring to this topology diagram often as you perform the labs will help you understand the concepts being taught.
Roles
This lab is divided up into two roles: Shared Service System Administrator and Software Engineer
Shared Service Administrator (Adam)
Typically there are only a few Shared Service Administrators supporting a team. This person is responsible for Shared Service running within the cloud. They need to have Workload resources administration with full permissions or the Cloud Administrator role. See the InfoCenter for more details.
Software Engineer (Evan)
This person may be a Test Engineer or a Developer. They wish to record and test their application that is under development that is dependent upon some WebServices and a Database. The Software Engineer needs to have permission to Deploy patterns.
Figure 2: Roles and communication between roles
Icons
The following symbols appear in this document at places where additional guidance is available.
/ Important! / This symbol calls attention to a particular step or command. For example, it might alert you to type a command carefully because it is case sensitive./ Information / This symbol indicates information that might not be necessary to complete a step, but is helpful or good to know.
/ Trouble-shooting / This symbol indicates that you can fix a specific problem by completing the associated troubleshooting information.
/ Shared Service Administrator / Section or task to be performance by the Shared Service Administrator
/ Software Engineer / Section or task to be performed by the Software Engineer
Figure 3: ICON Table
Lab 1Setting up Patterns
In this lab, the Administrator will deploy Shared Services that will support the software engineers. This only needs to be performed once. If the shared services are already deployed read through these sections for reference only.
1.1[prereq] Import Rational SDLC
To leverage this lab the IBM Software Delivery and Lifecycle Patterns need to be imported and licenses accepted. These steps are documented in the Information Center:
1.2Determine Cloud Group
Shared Services are deployed into specific Cloud Groups. A Cloud group is a mechanism used by IBM Pure Application System to partition the total cloud resources. For this Lab you will need to identify a Cloud Group to use which all Shared Services and Patterns will be deployed into.
All Shared Services and Patterns need to be deployed into the same Cloud Group
1.3Deploy IBM Shared Service for Rational Installation Manager Repository
These steps are documented in the Information Center:
1.4Deploy IBM Shared Service for Rational License Key Server
These steps are documented in the Information Center:
1.5Deploy IBM Shared Service for Rational Test Virtualization Server
These steps are documented in the Information Center:
When deploying the Shared Services the Shared Service Administrator can provide a public SSH key. This allows the Administrator to login via SSH to the machines using their private SSH key. This will be necessary later in the lab when configuring the Shared Services.
Verify now that you can login to the Shared Services via SSH.
If you can not login to the Shared Services use the following directions on the wiki ( or consult the IBM Pure Application System Information Center.
1.6Configure the IBM Rational Test Workbench Pattern
Configuring the IBM Rational Test Workbench pattern consists of setting and locking default values for several of the configuration properties used by the pattern’s script packages. In most cases, these properties reference elements that are unique to your instances of the shared services deployed in the steps, above. These values will be required to deploy the IBM Rational Test Workbench pattern but will likely not be known by the Software Engineer performing the deployment. Furthermore, the Software Engineer will likely not have the permissions necessary to discover these values. For example, during deployment, IBM Rational Test Workbench is installed on the instance using the software packages available through the NFS share available through the Shared Service for Rational Installation Manager. The location of the NFS share is provided to the script packages through a property. By configuring the default property value in the IBM Rational Test Workbench pattern, you eliminate the need for the Software Engineer to deal with this detail.
In this section, you will follow this basic procedure:
- Navigate to the instances of your shared services in the Workload Console
- Record the value of the required parameter
- Set that value as the default property value in the IBM Rational Test Workbench pattern
- Optionally lock that property value
It requires the least number of steps if you collect all the values first, and then set them all at one time in the IBM Rational Test Workbench pattern.
1.6.1Determine the location of your NFS share
Deploying the Rational Test Workbench pattern involves installing several IBM Rational software components. The installation packages for these components are made available through an instance of the IBMShared Service for Rational Installation Manager Repository. As the Shared Service Administrator, you will need to identify the path to the file server on your IPAS system in order to set the value on the IBM Rational Test Workbench pattern.
__1. Select Instances > Shared Services from the Workload Console menu.
__2. Select the instance of the IBM Shared Service for Rational Installation Manager Repository.
__3. Click the Endpoint link near the Repository middleware perspective.
__4. Record the path for ENDPOINT. It will be in the form <ip address>:/storage/shared. This value will be referenced later as NFS_SHARE.
__5. Cancel the dialog.
1.6.2Determine the results database connection parameters
All Software Engineers that deploy the IBM Rational Test Workbench pattern will create a Rational Integration Tester test project. This project utilizes a database to store results of the tests. The database is hosted on a node within the IBM Shared Service for Rational Test Virtualization Server.
__1. Select Instances > Shared Services from the Workload Console menu.
__2. Select the instance of the IBM Shared Service for Rational Test Virtualization Server.
__3. Click the Endpoint link near the DB2 middleware perspective. Two endpoints will be displayed – one for DBA connections and one for general application users.
__4. Record the path for the AppUser ENDPOINT. The path will be broken down into three components later – RESULTDB_URL, RESULTDB_USER and RESULTDB_PASSWORD. (Note: do not include the semicolon in the password.)
__5. Cancel the dialog.
1.6.3Determine the hostnames of shared service nodes
Your users will require some additional information about nodes within the IBM Shared Service for Rational Test Virtualization Server in order to use it. You should document the hostname values for the following nodes and share these values with any users of the IBM Rational Test Workbench pattern.
__1. Select Instances > Shared Services from the Workload Console menu.
__2. Click IBM Shared Service forRational Test Virtualization Server – Shared Cloud Group.
__3. Expand Virtual machine perspective if necessary. Record the Public IP hostname for the following nodes in your deployment topology. You will share this information with your Software Engineers in section 1.5.
Cloud GroupPlaceholder Node / Virtual Machine Name / Public IP/hostname
RTCP_HOST / RTCP-HVM.nnnnnn
RITPP_HOST / RITPP-HVM.nnnnnn
RITA_HOST / RTVS-HVM.nnnnnn
1.6.4Clone the prebuilt IBM Rational Test Workbench pattern
When changes to a prebuilt pattern are required, a recommended best practice is to create a clone of the original pattern rather than to edit it. In this section, you will clone the prebuilt IBM Rational Test Workbench pattern to create a new pattern that is configured specifically for your cloud group.
__1. Select PatternsVirtual Systems from the Workload Console menu.
__2. Select the IBM Rational Test Workbench Pattern v8.5.1 pattern from the list of Virtual System Patterns.
__3. Click the Clone tool on the toolbar above the pattern view.
__4. Enter a name for the new pattern. A suggestion would be to append the name of the cloud group being used. For example, if your shared services are running in the Shared Cloud Group, name your new pattern IBM Rational Test Workbench Pattern v8.5.1 - Shared Cloud Group.
__5. Click OK to create the clone.
1.6.5Set the IBM Rational Test Workbench NFS_SHARE parameter
__6. Select PatternsVirtual Systems from the Workload Console menu.
__7. Select the newIBM Rational Test Workbench Pattern v8.5.1- Shared Cloud Group pattern from the list of Virtual System Patterns.
__8. Click the Edit tool on the toolbar above the pattern view. (Note that you must be listed in the Grant Access to field of the pattern in order to edit it.)
__9. Click the Parameters tool on the Rational Configure File Server script package.
__10. Enter the value you recorded in step 1.4.1for NFS_SHARE. Use the lock icon to ensure that this value cannot be overridden during deployment of the pattern.
__11. Click OK to exit the script package parameters dialog.
1.6.6Set the IBM Rational Test Workbench RESULTDB parameters
__1. While still editing the pattern, click the Parameters tool on the Set Default ResultDB (On Deployment) script package.
__2. Enter the values you recorded in step 1.4.2 for RESULTDB_URL, RESULTDB_USER and RESULTDB_PASSWORD. Use the lock icon to ensure that these values cannot be overridden during deployment of the pattern.
__3. Click OK to exit the script package parameters dialog.
__4. Click Done editing above the pattern editing area to close the editor.
1.6.7Add the shared service hostnames to the comments
As a convenience to users of the new pattern, Adam will add comments to the pattern that contain the hostnames of the nodes users will require.
__1. Scroll to the bottom of the pattern viewing area and expand Comments.
__2. In the comments box, enter the Placeholder Node and Public IP/hostname for the nodes from section 1.4.3. Enter each node in a separate comment.
1.6.8Update permissions on the Pattern so that the team can view it
Users will only see resources that they either own, or have permissions to see. Now that the Virtual System Pattern is ready for use by the team we can add them to it. This is simply a matter of adding an individual or team (LDAP group) to the ‘Access granted to’ field. You may also use the group name ‘Everyone’.
To add an individual, group or Everyone simply type their name in the field
1.7Communicate to Software Engineers that the pattern is ready for use
At this point, the IBM Rational Test Workbench pattern has been configured for your IBM PureApplication System environment and is ready for use by the Software Engineers. Your team can decide the best method to use to communicate this information to the users – email, wiki, website, etc. An email template is provided below.
IBM Rational Test Workbench Users:
A new IBM Rational Test Workbench virtual system pattern has been deployed on <IPAS System Name>.
IBM Rational Test Workbench Pattern v8.5.1- Shared Cloud Group
<URL to the pattern>
You may create personal instances of the pattern by following the URL above, logging into the system, and selecting “Deploy”. You will be required to provide passwords as part of the deployment process. Note that these passwords must comply with our corporate policies.
To use your Rational Test Workbench instance for integration testing and test virtualization, you will likely need to leverage the IBM Shared Service for Rational Test Virtualization Server. Hostnames for nodes in the shared services are provided below:
Cloud GroupPlaceholder Node / Virtual Machine Name / Public IP/hostname
RTCP_HOST / RTCP-HVM.nnnnnn
RITPP_HOST / RITPP-HVM.nnnnnn
RITA_HOST / RTVS-HVM.nnnnnn
Summary
As the Shared Services Administrator, you have deployed the IBM Shared Service for Rational Installation Manager Repository, IBM Shared Service for Rational License Key Server and IBM Shared Service for Rational Test Virtualization Server to your IBM PureApplication System. These services are now available for any Software Engineers to leverage to do their jobs.
You also setup the IBM Rational Test Workbench virtual system pattern with values that correspond to your unique deployment of the shared services, making it easier for the Software Engineers using the pattern to deploy and use it.
Finally, you documented information that users of the IBM Rational Test Workbench pattern will require to effectively leverage the shared services for Rational Test Virtualization Server.
Lab 2Deploying the System Under Test
In this lab, you will create a sample system under development that you will test against in later labs. This sample system will be a Virtual System Pattern (VSP) that you will create on your IBM PureApplication System (IPAS) system from pre-installed virtual images and script packages that you will construct. File artifacts have been provided that will make this process easier for you.
The DayTrader system is a three-tier architecture. The web client tier is implemented in JSP and Servlet technology and deployed to a WebSphere Application Server (WAS) instance. The web services tier is implemented in Enterprise Java Beans and also deployed to WAS. The DB2 database is hosted on the DB2 server.
2.1Construct the DayTrader Sample Virtual System Pattern
The IBM PureApplication System Workload Console will be used to construct a sample VSP. This VSP will consist of two parts – a WebSphere Application Server (WAS) part and a DB2 Database Server part.
The DayTrader application will be deployed into the WAS part using a script package that you will create from the downloaded files.